Architectural Design Document (ADD)

Preparing to load PDF file. please wait...

0 of 0
100%
Architectural Design Document (ADD)

Transcript Of Architectural Design Document (ADD)

Architectural Design Document (ADD) Computer emulator for digital preservation

Version Author Date Project

: 1.0 : B. Lohman (Tessella Support Services plc.) : 03-03-2006 : Emulation project

Koninklijke Bibliotheek (National Library of the Netherlands) Nationaal Archief of the Netherlands

Architectural Design Document (ADD)

I. Revision history
Revision number Revision date Author

Summary of changes

II. Related documents
Document name
User Requirements Document (URD) Emulation – a viable preservation strategy Reference document for emulation

Date
21-02-2006 20-06-2005 in progress

Author
B. Lohman J.R. van der Hoeven J.R. van der Hoeven

Author: Date: Version:

B. Lohman 03-03-2006 1.0

Project: emulation project Page: 2

Architectural Design Document (ADD)

III. Table of contents

I. Revision history ................................................................................................ 2
II. Related documents ........................................................................................... 2
III. Table of contents .............................................................................................. 3
1 Introduction ...................................................................................................... 5 1.1 Purpose of this Document .......................................................................... 5 1.2 Scope of this Document.............................................................................. 5 1.3 Context of this Issue ................................................................................... 5 1.4 Definition of Terms .................................................................................... 5
2 Document Overview and Design Techniques ................................................ 6
3 System Overview .............................................................................................. 7 3.1 Overview and Context................................................................................ 7 3.2 Architecture summary ................................................................................ 8 3.3 Implementation strategy ............................................................................. 9
4 System components ........................................................................................ 10 4.1 Central Processing Unit (CPU) ................................................................ 10 4.1.1 Attributes ....................................................................................................... 10 4.1.2 Operations..................................................................................................... 10 4.1.3 Exceptions ..................................................................................................... 10 4.2 Memory Management Unit (MMU)......................................................... 10 4.2.1 Attributes ....................................................................................................... 10 4.2.2 Operations..................................................................................................... 11 4.2.3 Exceptions ..................................................................................................... 11 4.3 Memory .................................................................................................... 11 4.3.1 Attributes ....................................................................................................... 11 4.3.2 Operations..................................................................................................... 11 4.4 I/O Ports (programmable I/O memory) .................................................... 11 4.4.1 Attributes ....................................................................................................... 11 4.4.2 Operations..................................................................................................... 11 4.5 Advanced Programmable Interrupt Controller (APIC) ............................ 11 4.5.1 Attributes ....................................................................................................... 12 4.5.2 Operations..................................................................................................... 12 4.6 Real-time clock......................................................................................... 12 4.6.1 Attributes ....................................................................................................... 12 4.6.2 Operations..................................................................................................... 12 4.7 Direct Memory Access (DMA) Controller............................................... 12 4.7.1 Attributes ....................................................................................................... 12 4.7.2 Operations..................................................................................................... 12 4.8 PCI Bus..................................................................................................... 12 4.8.1 Attributes ....................................................................................................... 13 4.8.2 Operations..................................................................................................... 13 4.9 Graphics card............................................................................................ 13 4.9.1 Attributes ....................................................................................................... 13 4.9.2 Operations..................................................................................................... 13 4.10 Keyboard device....................................................................................... 13 4.10.1 Attributes ....................................................................................................... 13 4.10.2 Operations..................................................................................................... 13 4.11 Mouse device............................................................................................ 13 4.11.1 Attributes ....................................................................................................... 14

Author: Date: Version:

B. Lohman 03-03-2006 1.0

Project: emulation project Page: 3

Architectural Design Document (ADD)
4.11.2 Operations..................................................................................................... 14 4.12 ATA Controller ........................................................................................ 14
4.12.1 Attributes ....................................................................................................... 14 4.12.2 Operations..................................................................................................... 14 4.13 Hard disk device ....................................................................................... 14 4.13.1 Attributes ....................................................................................................... 14 4.13.2 Operations..................................................................................................... 14 4.14 CD-ROM devices ..................................................................................... 15 4.14.1 Attributes ....................................................................................................... 15 4.14.2 Operations..................................................................................................... 15 4.15 Sound device ............................................................................................ 15 4.15.1 Attributes ....................................................................................................... 15 4.15.2 Operations..................................................................................................... 15 4.16 Emulation Environment............................................................................ 15 4.16.1 Attributes ....................................................................................................... 15 4.16.2 Operations..................................................................................................... 15
5 Prototypes ....................................................................................................... 17
6 Design Scenarios............................................................................................. 20
7 System-wide considerations........................................................................... 23 7.1 Automated Debugging, Testing and Diagnostics ..................................... 23 7.2 Speed ........................................................................................................ 23 7.3 Third-Party Software ................................................................................ 23 7.4 Development Environment....................................................................... 23

Author: Date: Version:

B. Lohman 03-03-2006 1.0

Project: emulation project Page: 4

Architectural Design Document (ADD)

1 Introduction

1.1 Purpose of this Document
This document describes the proposed prototyping approach for designing the modular emulator. It is based on the user requirements specified in the User Requirements Document [URD] and the use cases specified below.
It will form the basis of the planning of the development phase and will be updated using the results from the various development iterations to come to complete architectural design. At the end of the development the document will be used to write a guide for maintaining the system (System Maintenance Guide, SMG).
It is intended for review by members of the project, notably the system architects of the development team.

1.2 Scope of this Document
This design will follow the Rapid Application Development (RAD) / rapid prototyping lifecycle, and covers the development of the modular emulator via a sequence of fourteen prototypes as described in section “Prototypes” of this document.
Detailed design for many of the components of the prototypes has been delayed until actual development for two reasons: there are many unknowns in design that need to be addressed before deciding a course of action; not all details could be researched in the length of time given for design. These gaps will be filled in using results and outcomes of preceding prototypes, and when research provides answers to details. The complete architectural design will therefore not be complete until the end of the project.
Motives for design decisions made in the project’s development phase will be noted here to ensure proper documentation is available for future references.

1.3 Context of this Issue
This document is a work in progress, and detail will be added at later dates when this becomes available. It will continually be updated in a separate document, called the reference document [REF], including all specific know-how about hardware components and their interaction.

1.4
ADD URD

Definition of Terms
The Architectural Design Document (this document), the high level design document for the entire system. The User Requirements Document, records the users’ requirements for the system.

Author: Date: Version:

B. Lohman 03-03-2006 1.0

Project: emulation project Page: 5

Architectural Design Document (ADD)
2 Document Overview and Design Techniques
The overall structure of the document is as follows:
Section 3 contains an overview of the architecture. Section 4 describes the major system components. Section 5 lists the prototypes that will be produced in the development phase. Section 6 lists some use cases for the design stage. Section 7 finalises with system-wide considerations.
The design methodology used in this project is a combination of RAD / rapid prototyping. The final system will be the result of several iterations of prototypes, expanding and adding complexity with each subsequent iteration. As the project is also a feasibility study, prototypes may implement a solution to a particular issue that seems viable at the time, but at a later stage may hinder further development. It is not unlikely that development will backtrack to resolve these issues and result in different prototypes and / or a different design strategy.
Any such major design decisions will be documented here for further reference. Use cases have been created to both aid design work and help with test scenarios. At this stage the ADD consists of simple diagrams that have been created to assist in visualising the interaction between the major system components, and so help define their functionality. More detail will be added at a later time, when available and the design requires this.

Author: Date: Version:

B. Lohman 03-03-2006 1.0

Project: emulation project Page: 6

Architectural Design Document (ADD)

3 System Overview

3.1 Overview and Context
The diagram of the system is provided below. This shows the proposed system architecture, although not all components stated in this diagram will be developed (including UVM and Module library).

Original

PDF document

Database

PDF viewer

DBMS

Interactive app.

Original system software (OS)

Modular emulator

CPU HD

Memory

CD

Emulator specification document

Platform & time independent

Universal Virtual Machine (UVM) Interface

Start UVM and load

Controller

Library
CPU Memory
HD CD Graphics Sound load

Platform & time

Future system software (OS)

dependent

Future hardware

Figure 3.1 Initial design of a modular emulator for digital preservation

A simplified context model diagram, showing the flow of data between the system and its environment across the system boundaries is as follows:

Emulator Specification
Document

Translated hardware instructions

Host system hardware

Target system software

Target software instructions
Target software values

System

Host hardware values

Host software values

Translated software instructions
Host system software

System boundary

System boundary

Figure 3.2: simplified context model diagram with major system functionality

Author: Date: Version:

B. Lohman 03-03-2006 1.0

Project: emulation project Page: 7

Architectural Design Document (ADD)
The high-level functionality offered by the system is the capability to reproduce the Reference Workstation (RWS) environment as defined in the User Requirements Document (URD). This includes all sub-components, such as graphics, I/O, memory, etc.
3.2 Architecture summary
An overview of the architectural breakdown of the system is given in the following diagram:

RT clock
PIT / PIC ƒ Register

CPU
ƒ Registers ƒ Interrupt ƒ Instructions ƒ EA ƒ Clock

MMU

M emory
ƒ Contents ƒ Initialise
ROM ƒ Read ƒ Write

Programmed I/O

Address space ƒ

Memory mapped ƒ

DMA ƒ Register

Devices
ƒ Initialise / register ƒ Read ƒ Write ƒ Interrupt

Keyboard ƒ Interrupt ƒ Write data

Mouse ƒ Interrupt ƒ Write data

PCI ƒ Register
Sound ƒ
ATA ƒ

AGP ƒ
Video ƒ

Disk ƒ

CD-ROM ƒ

Figure 3.3: architectural breakdown of system
This shows the main components the system consists of, and that will likely need emulating. The complete system will be encapsulated in an emulation environment, not shown in this diagram, which will form the test harness and / or user interface of the system. Each of these components will be elaborated on in the next section, describing their properties. Once development of the component begins, more detail will be added to each

Author: Date: Version:

B. Lohman 03-03-2006 1.0

Project: emulation project Page: 8

Architectural Design Document (ADD)
section. The current version of this document merely provides placeholders with high-level detail.
3.3 Implementation strategy
There are several assumptions that impact the design strategy, which will be stated here for clarity.
Emulation will be implemented at the highest possible logical level This should improve performance, simplicity and flexibility, amongst others. This also implies that not all hardware will necessarily need to be emulated; as long as the functional behaviour remains the same. However, given the choice of modelling components similar to hardware or logically, with similar performance and development effort, it is likely to be better to model according to the hardware; the model will be easier to understand and any discrepancies due to the emulation should be easier to adapt. Emulating at a high logical level will also avoid, wherever possible, the need to understand any data or control formats, and avoid the need to modify existing operating systems, BIOS or driver code. Wherever possible, the ‘real’ software will be used for these purposes.
Component modulation is preferred to be kept general rather than RWS specific. Wherever possible, the components in the RWS will be emulated according to their specifications. However, it is assumed that no applications were designed specifically for the RWS hardware, hence the components need not be emulated exactly. Especially with proprietary components, or due to lack of API information, it will be sufficient to emulate a generic feature of that component. Emulated behaviour should be judged against the "natural range of variability" that is encountered by a preserved digital object in its normal use on a platform, which will have a range of different keyboards, mice, displays, sound chips, processor speeds and features, memory sizes, disks, etc
Not all capabilities of the RWS are relevant for preservation purposes As stated in the User Requirements Document (URD), priority will be given to those components that are used by the test objects. This defers the need for printing, floppy-disk use, connection of arbitrary devices to ports, network access, sound recording, etc. Other features of the RWS are unlikely to be used by digital objects of interest, e.g., OpenGL graphics.
Modelling of synchronisation mechanisms (such as bus arbitration) may be necessary to give a realistic order of execution of the emulation. However, it is hoped that this will not be necessary; PC hardware is quite variable and so it would be expected that a range of ordering of hardware activity could result from running a given program, while giving the user a similar experience.

Author: Date: Version:

B. Lohman 03-03-2006 1.0

Project: emulation project Page: 9

Architectural Design Document (ADD)

4 System components

4.1 Central Processing Unit (CPU)

Notes: • • • • •


Should try to avoid emulating processor pipelining, caching and detailed timing. The modelling of logical behaviour should be independent of these. Although likely not to be an issue at present due to low speed performance, may need to emulate instruction cycles, real-time speeds of instructions in future to ensure correct running speed. Depending on CPU interaction with hardware, ports, mapped memory or special instructions and circuitry may need to be modelled. An exception to this is to avoid modelling the exact behaviour of the hardware so that the instructions can result in NOOPs (e.g., not modelling the page table entry caching, INVLPG instruction can be a NOOP). It is likely the system bus doesn’t need to be emulated.

4.1.1 •


Attributes
Registers
o General purpose o Status (including Privilege level, Paging mode) o Segment o Instruction pointer Cycle clock

4.1.2 • • • •


Operations Instructions Interrupt handling Reset Address translation including:
o lookup of segment descriptors o bounds checking o segment protection EA

4.1.3

Exceptions

• Segmentation fault

4.2 Memory Management Unit (MMU)
Notes: • Need to determine if paging can be disabled / forced resident. Otherwise need to investigate strategies to minimise (Windows) paging.

4.2.1 • •

Attributes Translation Look-aside Buffer (TLB), or other cache. invalidation (probably not needed, at least initially)

Author: Date: Version:

B. Lohman 03-03-2006 1.0

Project: emulation project Page: 10
Design DocumentVersionDocumentDesignComponents