Interruptor

The driver software form a Hardware Abstraction Layer between the DM and the generated software framework. This layer allows for reuse of both the hardware and software. It is a collection of software that is used by the dependability appli- cation and the framework to gain access to the retargeting engine and the interrupt

manager. The DM itself also has some drivers to operate the LEDs, discussed in subsection 5.5.6, from the application. Normally drivers exist between an operating system and hardware. They form a HAL between the machine and the OS. They would be compliant with the operating system and specific for the device. They reg- ister the device but also allow communication between the OS and the device. In this project the dependability application runs bare-metal on the DM and no operat- ing system is used. The HAL and drivers are added to increase maintainability and reusability.

4.3.1

Operating the Retargeting Engine

The retargeting engine features four registers and a large addressable memory mod- ule. The memory contains the H-Array, Access Request Stack, the Returned Val- ues and also the read extraction request stack, the latter being unimportant to the dependability application. The registers consist of a Control register and a Status register. The other registers are used to store the length of the H-Array and their functionality can be expanded if needed.

The Control and Status registers are used to communicate with the Retargeting Engine. The Status register is read only and has specific bit-fields mapped to a certain status of the retargeting engine. If the engine is busy with communicating to the network then a field reads a ’1’, if it is done, that field reads a zero. The Control register works in the same way but is only writeable. If a ’1’ is written to a certain field it will start the retargeting process.

The memory stores information necessary for retargeting such as the H-Array and the access request stack. The whole memory is addressable as this eases implementation. Before retargeting can happen the H-Array needs to be initialized. The driver library has functions that automatically encodes an entry based on given parameters. The instrument ids are available in the header file of the PDL frame- work as preprocessor definitions and can be used to encode the H-Array which is accessible as an array pointed to the right memory address.

The driver program has methods for issuing iWrites and iReads to the retar- geting engine. They access the base of any Access Request stack and modify the pointer of that stack. They also automatically switch to the next stack to store the next Access Request.

memory. PDL level-0 has no specific way to give access to those values so a simple system is designed. The read values from the network are stored in an array with the same size as the H-Array. The id of the instrument in the H-Array determines the position of the value. The dependability application can read from the instrument by reading from its position in the read values array.

4.3.2

Operating the Interrupt Manager

The interrupt manager is also connected to the system bus and uses the same mem- ory mapped IO strategy to communicate. Driver software is made to easily configure and operate the interrupt manager.

The interrupt manager features two accessible registers along with the interrupt vector table (IVT). The registers comprise of a Active and Busy register although the Busy register will not be very interesting from a software point of view. When an interrupt is being serviced, the Busy register will feature a one on the ESIB L’s position, based on its id in the IM H-Array. If one function handles multiple interrupt sources, it may identify the instrument through this.

The active register handles which interrupt vectors are valid and primed for exe- cution. An interrupt service routine is attached to an instrument but may be deacti- vated for example when the normal program enters a critical point in the code. The driver contain a function to activate/deactivate a single IVT entry or all of them at once. An attached ISR must be activated before it can operate.

To register a function for a certain interrupt source, the driver has a function called attachInterrupt. It takes the ESIB L-id in the IM H-Array and a handle of a user defined function. The handle is stored in the Interrupt Vector Table in the Interrupt Manager based on the entry pointed to in the IM H-Array. It is the user’s responsibility to make sure that the interrupt function end with auretcommand, dis- played in Fig 3.3. This instruction notifies the hardware to return from the interrupt elevation, restore the program counter and registers and resume normal operation. The interrupt function may not feature parameters or a return type other than void

as well.

The design of the registers of the interrupt manager is lacking in scalability. For example, the hierarchy array employed in the interrupt manager is not yet config- urable in software, while it stores the connection between interrupt sources in the network and their corresponding IVT entry. The amount of interrupt sources will

probably be substantially larger than the 32-bit active/busy registers so their flag- ging strategy will not work. Resolving the IVT entry in hardware is easy due to the fact that the IM H-Array stores the pointer to the IVT.

4.3.3

Operating the Dependability Manager

The remainder of the Dependability Manager is managed by a set of supporting software. A library is made that contains a small self-test of the processor going through all the instructions of RISC-V. The supporting software also contain meth- ods to drive the states of output LEDs, discussed in subsection 5.5.6. They are not useful for dependability management but very helpful to provide output during testing. The dependability manager library also offers a method to a success state and a failure state. These can be used to stop the program when the self-test fails. They both show a distinctive pattern on the LEDs to show the programmer what hap- pened. To aid the creation of the H-Array in the retargeting engine some functions are made to encode entries. The driver for the DM is a collection of handy functions aiding the programmer.