[Brandon University crest][The famous "Halfway Tree" of the Prairies, between Winnipeg and Brandon]


KModel - Hardware Design
 


Site Map

  Kmodel Home  
  - Download
  - Installation
  - Javadoc

  Hardware Model
  - Serial  
  - Timer  
  - Disk  

  Kernel Design  
  - Modules  
  - User Process  
  - Kernel Entry  
  - Kernel Call  
  - Handles  
  - Signals

  Components  
  - Processes  
  - Console  
  - Timer  
  - Disk  

  File System  
  - Disk Layout
  - Buffer Cache
  - Inode Cache
  - Standard Files
  - Vnodes

  Study Questions  

 

   

Although KModel is implemented completely in software, it is based on a realistic hardware design that provides behaviour similar to real hardware. This behaviour includes the unpredictability usually found in dealing with hardware at the programming and debugging level, particularly when dealing with the asynchronous nature of  hardware events. That being said, the Java development environment eases the debugging burden by permitting breakpoints and single stepping through code that implements hardware functionality. 

This section provides an overview of the hardware model. Details on specific devices can be found on the sections Serial, Timer  and Disk.

Figure 1: Hardware model

The processor communicates with device controllers through a bus by issuing read and write instructions against bus addresses. In a hardware design, each device controller listens for certain addresses that are unique to that device.  The result of a bus write is to update the contents of a device register. Certain writes cause activity in the device. As a result of this activity, and after some delay due to processing in the device, the controller may raise an interrupt in the processor. Device controllers can also access memory directly, using addresses supplied in their registers.

A controller's registers are numbered starting at zero. A controller's register set is relocated on the bus using address logic. For example, if a serial controller's registers are located at bus address 6016, a read of, say, bus address 0x61 would result in data from register 1 of the serial controller to be produced as the result of the read.

In the software model, a bus write causes flow of control to be passed to a method of a controller subclass. The method may then interact with a thread implementing the operation of the device. A bus read ends up similarly in a method of a controller. Events in the device thread result in asynchronous calls into the kernel via the interrupt mechanism, described in Kernel Entry.

The class structure for the design is shown in Figure 2. The Bus contains a  number of PortAdapters. Each PortAdapter contains a Controller and the base address of the controller's register set. The purpose of a PortAdapter is to perform the relocation that would be performed by address logic in a hardware design. A call to the input() and output() methods uses a PortAdapter's inRange method to determine if the PortAdapter is valid for the address supplied to input() or output(). A subsequent call to the PortAdapter's readPort() or writePort() methods relocates the address argument using the base address and passes the address on to the Controller.

Figure 2: Class Relationships

Specific controllers such as serial (console), interval timer and disk are implemented in classes derived from Controller.

The operation of a device is typically implemented by a Thread defined within the Controller class. Thus the thread has access to the fields of the controller, namely the register file, shared Memory, the InterruptMechanism and the controller's interrupt number intno. Writing into a controller register may cause the thread to be wakened, change state, perform work and subsequently raise an interrupt.


Last update 01/24/05
Copyright © Gerald Dueck
[=]