The Virtual Communication Bus Toolbox. Survey of Device Driver Management in Real-Time Operating Systems

Transcription

1 The Virtual Communication Bus Toolbox & Survey of Device Driver Management in Real-Time Operating Systems Author Sebastian Penner Supervisor Peter Nygren Examiner Lennart Lindh Department of Computer Science and Electronics Computer Architecture Lab Mälardalen University Box 883, Västerås

2

3 ABSTRACT This report consists of two separate reports, as indicated by the title. The first report covers the work involved in implementing the VCB Toolbox, an API towards the Virtual Communication Bus IPC component, which is a part of the SARA project at Mälardalen University in Västerås, Sweden. Similar to the VCB component, VCB Toolbox is fully implemented in VHDL and can easily be integrated into a system on FPGA. The report starts off with an introduction, motivation, features, and a general description of the Toolbox. The next section describes the different stages of development, and the final implementation of the Toolbox. The subsequent sections provide detailed descriptions of the incorporated layers within the Toolbox. Finally the report is summarised. The second report presents a survey of device driver management in three commercial real-time operating systems, along with five academic solutions. The report begins with an introduction and a discussion about device driver and their use. Following are three major sections, each detailing the three commercial RTOS es (Spectra, OSE, and Lynx) in a general overview, their device driver interfaces, and the way in which they handle interrupts. After that, each academic solution (Timix, Spring, Mars, HIC, and HARTIK) is described with regard to their inter process communication systems, and their approach to handling interrupts and peripheral devices. There is also a short conclusion for each system. Finally, the report is ended with a conclusion and summary. The Department of Computer Science and Electronics, Mälardalen University, 2005 i

4

5 Table of contents 1 INTRODUCTION 2 2 IDEA AND MOTIVATION 3 3 FEATURES 3 4 GENERAL DESCRIPTION OF VCB TOOLBOX INTEGRATION 4 5 FROM IDEA TO FINAL PRODUCT 5 6 LAYER DESCRIPTION THE TOOLBOX THE VCB LAYER THE SLOT LAYER USING MEMORY RESOURCE SHARING ADDRESS CALCULATOR DMA THE VCB BASIC LAYER 16 7 SUMMARY 18 8 INTRODUCTION 20 9 DEVICE DRIVERS DEFINITION MOTIVATION GENERAL SYSTEM LAYOUT DEVICE DRIVER TYPES POLLED DEVICES INTERRUPTING DEVICES BENEFITS AND DRAWBACKS SIMPLE EXAMPLE OVERVIEW SPECTRA FORMS AND THE FOPS TABLE EXTERNIO XTRACE LOGIO OSE OSE BIOS 34 ii

6 10.3 LYNX DEVICE RESOURCE MANAGER (DRM) BUS LAYER DATA STRUCTURES MAJOR AND MINOR DEVICES INTERFACE SPECTRA GENERAL DEVICE FUNCTIONS BUFFER FUNCTIONS INTERRUPT FUNCTIONS AND UTILITIES GENERIC DEVICE FUNCTIONS STARTING A DEVICE OSE DEVICE DRIVER FUNCTIONS DEVICE CLIENT FUNCTIONS LYNX ENTRY POINT FUNCTIONS STATIC INSTALLATION DYNAMIC INSTALLATION INTERRUPT HANDLING SPECTRA EXAMPLE OF LOGIO INTERRUPTS OSE INTERRUPT PROCESSES TIMER-INTERRUPT PROCESSES THE WAKE UP FACILITY FAST SEMAPHORES ARCHITECTURE DEPENDENT PARTS LYNX KERNEL THREADS PRIORITY TRACKING ACADEMIC SOLUTIONS TIMIX INTER PROCESS COMMUNICATION INTERRUPTS AND DEVICES CONCLUSION SPRING INTER PROCESS COMMUNICATION INTERRUPTS AND DEVICES CONCLUSION MARS INTER PROCESS COMMUNICATION INTERRUPTS AND DEVICES CONCLUSION 59 iii

7 13.4 HIC INTER PROCESS COMMUNICATION INTERRUPTS AND DEVICES CONCLUSION HARTIK INTER PROCESS COMMUNICATION INTERRUPTS AND DEVICES CONCLUSION CONCLUSION AND SUMMARY SPECTRA INTERFACE INTERRUPT HANDLING OSE INTERFACE INTERRUPT HANDLING LYNX INTERFACE INTERRUPT HANDLING ACADEMIC SOLUTIONS INTERFACE INTERRUPT HANDLING CONCLUSION SUMMARY REFERENCES APPENDICES APPENDIX A FUNCTION DESCRIPTIONS APPENDIX B WHAT EACH LAYER DOES APPENDIX C MEASURED TIMES APPENDIX D CODE EXAMPLE: HOW TO USE THE TOOLBOX APPENDIX E SIZE SPECIFICATIONS 23 iv

8

9 The Virtual Communication Bus Toolbox Sebastian Penner ABSTRACT This document describes the work that has been made to implement the VCB Toolbox, which purpose is to provide tools for communication between hardware and software using the Virtual Communication Bus. These tools are meant to be used by hardware threads to give them the ability to exchange information with software in an efficient and easy to use fashion. The document is divided into nine parts: introduction to the VCB, general description of the Toolbox, the process of implementing the Toolbox, descriptions of the parts included in the Toolbox, a summary, a user level walkthrough of each of the tools included, a more detailed description of what the different tools do to accomplish their task, measured times for each of the functions and lastly a detailed area specification of the toolbox and the three layers it contains. The Department of Computer Science and Electronics, Mälardalen University,

10

11 1 Introduction In general, all operating systems that support some kind of multi tasking contain within them a mechanism for exchanging data between active tasks. This kind of communication facility is called Inter Process Communication (IPC) and is the preferred way of exchanging data between tasks in a system compared to for example using shared memory which introduces the problem of inconsistency (which is not a problem when using IPC since the transactions should be atomic). There are many different implementations of IPC; Windows uses mail slots, where a process can create mail slots in which other processes can write data that can only be read by the owner of the slot. Linux uses pipes and message queues among others to handle IPC. The Virtual Communication Bus (VCB), described below, is an IPC system completely implemented in hardware, apart from a software interface. By implementing operating system functionality in hardware is it possible to achieve a higher level of determinism (since the CPU does not have to be used at all as in the case of the VCB), which plays a central role in real time systems. The purpose of my work has been to provide hardware threads with the ability to communicate in the same way as software OS threads using the VCB. 2

12 2 Idea and Motivation The idea was to collect all the necessary functions in a package that would be easily integrated into the system. The hardware thread should then, by using this package, be able to utilize the VCB for communication purposes. SW send(); receive(); SW send(); receive(); HW send(); receive(); Toolbox Virtual Communication Bus (VCB) Figure 1 The toolbox provides "connectivity" to the VCB for hardware threads This kind of function package could then for example be used to design device drivers in hardware, which are able to communicate easily with software. By using stand alone, hardware implemented device drivers the CPU can be left alone to execute more user code, and decrease the amount of system overhead caused by the operating system and its software components. This is the motivation for the development of the VCB Toolbox. 3 Features The VCB concept is built around the virtual bus that software and (from now on) hardware threads can connect to and use, to transfer messages between themselves as show by figure 1 on the previous page. The bus is not exactly a real bus, but only an abstraction to show the main idea of how the VCB works, hence the word virtual. The VCB is as said earlier an IPC system implemented in hardware, which allows the using threads to send and receive messages between other threads in the system. The VCB Toolbox is an extension of the VCB concept, which allows hardware to connect to the VCB system through the use of the toolbox (please refer to Figure 1 on the previous page). One can say that it acts as the interface to the VCB system, and does so by providing a level of abstraction that is close to what you would normally expect from a high level programming language library. The VCB Toolbox contains a set of tools to be used by hardware to allow it to communicate with software using the VCB. The tools included are: connect, disconnect, send, receive, broadcast and sendwait (an Init function is also included but it is only run automatically after system reset). These functions are semantically the same as their software equivalents. Descriptions of all of the functions supported by the Toolbox are given by Appendix A. 4 General Description of VCB Toolbox The Toolbox has been implemented in three layers: the VCB layer, Slot layer and the VCB Basic layer. The Toolbox itself defines the user interface to the VCB system (described in section 4.1), and connects the three layers it uses. 3

13 VCB Toolbox HW Thread VCB SLOT VCB BASIC Figure 2 Shows the inner connections of the three layers in the VCB Toolbox The VCB layer is the one closest to the user (the Toolbox). It provides the functionality that is supported by the VCB system. This layer has however been removed in all cases except for two (broadcast and sendwait) because of size constraints that could not otherwise be met. Besides increasing the total size of the Toolbox beyond acceptable limits it would also only add extra overhead and thus decrease the Toolbox s performance (measured in clock cycles). In the current (summer 2002) implementation of the Toolbox the VCB layer is only used by broadcast and sendwait. In all other cases the Toolbox uses the Slot layer directly. This violates the hierarchical design but the gain for doing this strongly motivates it. The Slot layer supports functionality for modifying or using a slot and the VCB Basic layer supplies the Slot layer with functionality supported by VCB Core. 4.1 Integration The VCB Toolbox has been implemented as an IP block, which is integrated into the system between the hardware thread and the VCB Core (which also is an IP block). Creating a hardware tread that makes use of the toolbox and putting all the pieces together is fairly simple. The toolbox has three connection points (as shown in Figure 3): one to the hardware thread, one to a DMA unit that handles memory accesses, and one to the VCB Core block. It is recommended that a top component be created that encapsulates the hardware thread and the toolbox. This will give you a component (say top_thread1) with two connection points to be connected to the DMA and the VCB Core, hiding the thread itself and the toolbox (Figure 3). Each instance of a top component like this will have to have its own DMA unit, unless you can guarantee that the top components will not transfer messages simultaneously. However, if this can be guaranteed, it is possible for them to share the same DMA, thus saving space. System bus DMA T1 Toolbox VCB core Figure 3 Integration of the toolbox into the system 4

14 5 From idea to final product What was requested from the start was a VHDL package containing functions that could easily be used to perform the different services supplied by the package (e.g. connect, send, receive, etc.). This request would show impossible to implement since this package would have to be shared between two VHDL components (the HW thread have to use the package, which in turn would have to use the VCB Core), which is just not possible. Instead a component based design had to be chosen. All of the functions included in the Toolbox were implemented as stand-alone top components each containing the three layers (VCB, Slot and VCB Basic). These top components were then used inside the Toolbox as shown by the picture below. The first idea was to allow full parallelism from the HW thread designer s point of view. That is, the hardware thread could use more than only one function at the same time. There would however only be a kind of pseudo parallelism because the VCB Core only supports one system call at a time. This would lead to serialization inside the Toolbox. Serialization the user would not have to be aware of. VCB TOOLBOX v.1 to/from DMA clk reset_n init w r TOP component VCB s e r i a l i z e r send broadcast sendwait receive connect SLOT VCB Basic (init, connect, send, receive...) disconnect to/from VCB Core Figure 4 The first version of the VCB Toolbox To accomplish this parallel behaviour each of these top components would have to have their own set of control signals, as shown in Figure 4, to allow them to be started individually. It was later decided that this design should be abandoned due to its extensive interface. One attempt to simplify the interface, but still allow some parallelism, was to use two separate channels to the Toolbox. The functions inside the toolbox would then be split up onto these two channels. The channels could be used in parallel but the execution order of functions in the same channel would have to be serial. This would give the user the ability to, for example, issue a send and a receive at the same time. The interface was however still not simple enough so the parallel design was abandoned. 5

15 Now that parallelism was not a goal to aim for, the interface was changed into only one set of control signals. This set of signals was then split up to reach every one of the separate top components (see Figure 5). VCB TOOLBOX v.2 to DMA clk reset_n connect w r send broadcast sendwait receive disconnect init to VCB Core Figure 5 The second version of the VCB Toolbox Up until now ten weeks had passed, with seven weeks of implementation and the rest for writing documentation. Now the interface was simple enough, but there was still one big problem. The size of the toolbox was unacceptably large. My first attempt to minimize the size was to eliminate the VCB layer in the top components. In all cases except for sendwait and broadcast, the VCB layer only passed on the control signals to and from the Slot layer. Because of this it only added extra overhead and size to the design. Since the interface to the VCB layer was identical to that of the Slot layer, the VCB layer was removed in all top components but the two mentioned above. This did make the design smaller but not anywhere near an acceptable size. To decrease size any further, another design had to be chosen. By splitting the three layers into seven pieces, one for each function, the tools used for synthesis had a poor chance to optimise the design in regard to size, since it cannot optimise over component boundaries. If you could, for example, put all the Slot layer pieces together in one component, which would allow them to share some of the logic they use. So by gathering all the pieces of the three layers in three big components (one of each layer) there could be a significant decrease in size. Because the layers had been split into several pieces they would have to be interconnected in the top components, and the top components themselves would have to be interconnected inside the toolbox as well. These connections consist largely of bit vectors, and their numbers could be decreased significantly if the pieces were put together as described above. By gathering all of the small pieces of each layer in dedicated layer components both of the above mentioned aspects of the old design would be addressed. The VCB Basic layer functions were very well suited to be put together, because all of them worked in much the same way. They were all built around the same framework and putting them together was quite simple. The Slot layer on the other hand could not be put together in one single process inside one component like the VCB Basic layer. Each function had to be 6

16 implemented in a separate process, and these processes were connected inside the layer component (see section 6.3 for details). The same was done for the two remaining VCB layer functions (see section 6.2). By changing the design into one that uses only three big layers instead of seven small pieces of each layer the size of the toolbox dropped by 7%. As this clearly shows different design decisions can have a big impact on the size of a construction. The last modification to the final design of the toolbox was the address calculator used by slot functions getmessage and putmessage to get the address to any given message in the message buffer. The motivation for using a separate address calculation component was resource sharing. To calculate the address both multiplication and addition must be used and these two operators, especially the multiplicator, use a lot of space. The component is designed to use only one multiplicator and one adder. However, it takes four clock cycles for the component to deliver the correct absolute address. Please refer to section for details about this component. 7

17 6 Layer Description This chapter will try to give a detailed description of each of the three layers contained within the Toolbox, and show how these layers are connected within the toolbox. After that follows a description of the VCB layer, which has the highest abstraction level, and how it communicates with the toolbox and underlying layer. Then comes a description of and how to use the Slot layer, which lies in the middle of the hierarchy. Lastly comes a description of and how to use the VCB Basic layer which is the layer closest to the VCB Core. 6.1 The Toolbox This section describes how the different layers (described in subsequent sections) are connected with each other inside the toolbox, plus the connections that make up the VCB Toolbox s interface to the rest of the system. VCB interface: cs_in IN fcn_in IN args_in IN msg_out OUT retval_out OUT Toolbox interface: vcb_args IN vcb_call IN vcb_sendmsg IN vcb_recmsg OUT vcb_sender OUT vcb_return OUT Toolbox toolbox core To HW thread VCB function id vcb_args function specific arguments function id: vcb_fconnect vcb_fdisconnect vcb_fsend vcb_freceive vcb_fsendwait vcb_fbrodcast Slot interface: cs_in IN fcn_in IN args_in IN retval_out OUT msg_out OUT sender_out OUT VCB Basic interface: cs_in IN args_in IN retval_out OUT error_out OUT To VCB Core SLOT VCB_BASIC To DMA DMA interface: size_dma OUT r_w_n_dma OUT DMA_ack_dma IN src_dma_read OUT dest_dma_read IN src_dma_write OUT dest_dma_write OUT VCB Core interface: hw_call data_hw rdv_hw_mux svcerror_hw_mux svcret_hw_mux msgavail_hw_mux OUT OUT IN IN IN IN Figure 6 The final design showing the three layers that makes up the VCB Toolbox 8

18 Using the Toolbox is very simple in terms of its interface, which simplicity has been the main focus, and the way to interact with it (shown in Figure 6). The interface (as shown by the picture above) is clean and easy to use. Here is a description of how to use the Toolbox. To activate a specific function inside the Toolbox you have to first activate the Toolbox by setting vcb_call (a chip select) to 1 plus assigning vcb_args (argument bit vector) a value describing which function to activate and that parameters it shall use (Figure 6 shows the layout of vcb_args). If a send, sendwait or a broadcast is selected then vcb_sendmsg must be assigned the data that is supposed to be sent. The next step is to wait for the Toolbox to finish. This is indicated through bit #0 in the vcb_return bit vector, which also holds the error/success code. When the bit is set the Toolbox has completed its handling of the requested function and is waiting for the user to clear the vcb_call signal. Before clearing the call signal the user should take care of whatever information the Toolbox returned (vcb_return, vcb_recmsg and vcb_sender). Figure 7 shows the interaction between a hardware thread and the Toolbox. fcn_id: vcb_connect vcb_disconnect vcb_send vcb_receive vcb_sendwait vcb_broadcast Hardware thread Toolbox fcn_id arguments call=1 return value 1 call= time time Figure 7 The interaction between a hardware thread and the toolbox 9

19 6.2 The VCB layer This section describes how the VCB layer component has been implemented (see Figure 8). It also will describe how the VCB layer is used and how it interacts with the underlying layer, the Slot layer. cs_in fcn_in args_in clk reset_n Toolbox interface : in std_logic msg_out : in std_logic_vector retval_out : in std_logic_vector VCB broadcast : out std_logic_vector : out std_logic_vector sendwait cs_out fcn_out args_out : out std_logic : out std_logic_vector : out std_logic_vector retval_in msg_in sender_in : in std_logic_vector : in std_logic_vector : in std_logic_vector SLOT interface Figure 8 The anatomy of the VCB layer This layer s be or not to be has been a question for a long time during the development of the Toolbox. When you look at the software equivalent to the Toolbox you will se that this layer would not add anything to the design other than overhead and take up space. What the VCB layer would do in all cases except for broadcast and sendwait, is to pass on the arguments from the Toolbox to the Slot layer and then send the Slot layers return values back to the Toolbox. This is however not the case for broadcast and sendwait. What they are supposed to do takes more than what the Slot layer alone can do. Please refer to Appendix A for information about the functions included in the Toolbox. Inside the VCB layer component, broadcast and sendwait has been implemented as two separate, parallel components. However, they have to be executed in a serial order, or they will not function correctly. When one of them has been activated, it must be allowed to finish before the other one can be started safely. The way in which the VCB layer interacts with the Toolbox and the Slot layer is described below and must be followed strictly. But since the hardware designer should use the Toolbox this will not be a matter of concern. 10

20 The VCB layer is activated by a chip select (cs_in) signal. When this signal is set either one of sendwait or broadcast can be activated. To determine which one of these two processes that is meant to run, a bit vector called fcn_in (a function id vector) is used. Its content is compared with each process unique id. The one with the matching id will start to run. This vector is checked at the same time as cs_in at each components initial waiting state. To use functionality supplied by the Slot layer the active process within the VCB layer have to do tree things. To activate a function within the Slot layer it has to set cs_out to 1 and set the fcn_out bit vector to the desired functions unique id. The arguments needed by the selected function should be placed in the args_out vector. By examining bit #0 of retval_in the running VCB process will be able to tell when the Slot layer is finished. When this bit is set to 1, the Slot layer is finished and retval_in, msg_in and sender_in contain valid information. The information should be copied to retval_out and msg_out before resetting the Slot layer, which will cause them to be reset as well. By clearing cs_out, fcn_out and args_out the Slot layer will be reset and ready for another request. When the contents of retval_in were copied to retval_out bit zero in retval_out was also set to 1, which is the indication to the user (the Toolbox) that the VCB layer is finished. It then has to wait for the cs_in (chip select) signal to be cleared before going back to its initial waiting state. 11

21 6.3 The Slot layer This section describes how the Slot layer is built up, and the connection points that are used to integrate it in the system (see Figure 9). It also describes how the layer should be used and how it uses the underlying layer. The message buffer layout is also explained, together with the address calculation component used to calculate the effective address to a specific message on a given slot in the message buffer. It also gives a brief look at the memory interface, a DMA, which is the recommended tool for transferring messages to and from memory. VCB layer/toolbox interface cs_in fcn_in args_in : in std_logic : in std_logic_vector : in std_logic_vector retval_out msg_out sender_out : out std_logic_vector : out std_logic_vector : out std_logic_vector SLOT clk reset_n init (retval_out) connect disconnect isconnected addr_cs : std_logic addr_ack : std_logic addr_slot_nr : std_logic_vector addr_msg_nr : std_logic_vector addr_msg_addr : std_logic_vector getmessage putmessage addr_calc cs_out : out std_logic args_out : out std_logic_vector retval_in : in std_logic_vector error_in : in std_logic VCB BASIC layer interface DMA interface src_read_out : out std_logic_vector dest_read_in : in std_logic_vector size_read_out : out std_logic r_w_n_read_out : out std_logic DMA_ack_read_in : in std_logic src_write_out : out std_logic_vector dest_write_out : out std_logic_vector size_write_out : out std_logic r_w_n_write_out : out std_logic DMA_ack_write_in : in std_logic Figure 9 The anatomy of the Slot layer The Slot layer contains the functions to be used to access and perform actions on a logical slot. This layer is the most complex one. Init and isconnected are the only functions that only use one of the basic layer functions. All the others use two of them to complete their task. The common thing for all these functions in the Slot layer is the way they interact with the VCB layer/toolbox and the VCB Basic layer. Below is a description of how they do this. 12

22 The Slot layer is activated by a chip select (cs_in) signal. When this signal is set one of the components (init, connect, send, etc) can start to execute. To determine which one of the components contained by the slot layer that is meant to run, a bit vector called fcn_in (a function id vector) is used. Its content is compared with each functions unique id. Any one of the slot components can start to execute if there is a match. fcn_in should be checked in the same way as in the case of the VCB layer. To access the VCB Basic layer an argument bit vector (args_out) has to be filled out with information taken from the args_in bit vector (arguments meant for the slot layer) according to the bit field specification of the VCB Core, which also applies to the VCB Basic layer, plus a chip select signal (cs_out) has to be set to activate it. After activation of the VCB Basic layer the active slot component (function) has to wait until VCB Basic has completed its requested task. It does this by waiting until bit #0 in retval_in (a bit vector holding the return value from VCB Basic plus a done flag - bit #0) has been set. When this happens it must clear cs_out, to deactivate VCB Basic, and set all bits in args_out to zero. If VCB Basic reported an error (error_in is set to 1 ) the active slot component should abort by copying the contents (error code) of retval_in to retval_out and go to the finish up state described below. If no error was reported (error_in = 0 ) the component may have to do some additional handling or call another VCB Basic function before it has completed its designated function. When the active slot function has done what it is supposed do to it sets bit #0 in retval_out to 1 to indicate that it is done and starts waiting for an acknowledgement (cs_in = 0 ) from the user (the VCB layer or the Toolbox). When cs_in is cleared it resets all of the signals it has been using to communicate with other components to zero, and returns to the initial waiting state. 13

23 6.3.1 Using memory The Slot layer must also have the ability to perform memory accesses, which is required by getmessage and putmessage to transfer 32 bits of data to and from memory. These 32 bits are the actual message that can be exchanged between software OS threads and hardware threads using the Toolbox. Messages are stored in a message buffer located in system memory. As shown by Figure 10 below, messages can (as of now, summer 2002) hold 12 bytes of data instead of only 4 bytes (32 bits) as mentioned above. However, the size of 12 bytes only applies when software is communicating with software. The four bytes used by hardware are the first four bytes in the message (msg[n][m][0 3]). Message Buffer message header slot # 0: msg queue hdr msg 0,0 msg 0,1 msg 0,m 1: msg queue hdr msg 1,0 msg 1,m n: msg queue hdr msg n,0 msg n,m 12 bytes 12 bytes 4 bytes 12 + n * (4 + 12) Figure 10 Layout of the message buffer that holds all the messages To pin point where to store or retrieve a message from, the effective address must be calculated. That is what the addr_calc component is used for (see Figure 10 for a description of the buffer layout). It calculates the effective address for a message based on the slot number and on an index into the message queue for that specific slot Resource sharing address calculator The reason to use a separate component for the address calculation is resource sharing, which on one hand decreases efficiency but on the other hand uses a minimum of resources; it is designed to use only one adder and one multiplier. Below is a description of its interface. Set addr_slot_nr and addr_msg_nr to their desired values together with addr_cs that is the chip select signal. Wait until addr_ack has been set. Now addr_msg_addr contains the address of the specified message on the given slot. Clear addr_cs, which will restore addr_calc to its waiting state. 14

24 The mathematical formula used to calculate the address is as follows: (BufferBase + vcbqueuehdr) + slotnr * vcbqueuesize + msgnr * (vcbmsghdrsize+vcbmsgsize) BufferBase: The base address of the entire message buffer. vcbqueuehdr: The size of the message queue header. slotnr: The slot id number (0...n). vcbqueuesize: The total size of a message queue. msgnr: Holds a message id number (0 m) in a message queue. vcbmsghdrsize: Size of the message header. It contains the size of the message and the slot id of the sender. vcbmsgsize: Maximum size of a message. The addr_calc component is, as mentioned above, designed to be resource efficient - it uses only one adder and one multiplier. These two operators are placed in parallel with a FSM (finite state machine) that supplies the operands they need. The adder uses three bit vectors, add_op1 and add_op2 and puts the result in add_result. The multiplier also uses three bit vectors, mult_op1 and mult_op2 with its result put in mult_result. This is how it works: Wait until addr_cs (chip select) has been set. Then multiply addr_slot_nr with vcbqueuesize by assigning addr_slot_nr to mult_op1 and vcbqueuesize to mult_op2. Secondly add (vcbmsgbuff + vcbqueuehdr) with the result of the previous multiplication, and multiply addr_msg_nr with (vcbmsghdrsize+vcbmsgsize). Lastly add the result of the previous addition and multiplication to form the final offset into the message buffer. The offset will be put together with the message buffers base address to form the absolute address and the result will be put in addr_msg_addr. At the same time addr_ack will be set DMA To actually access the system memory the Slot layer uses a DMA unit. This unit is located outside of the Toolbox, because it is the only part of the VCB, from the Toolbox s perspective, that is dependant on the technology used in the system. If the Toolbox is to be used in another system then only the DMA unit will have to be modified to meet the requirements of the new system. The DMA only serves as an interface between the Toolbox (slot layer) and the system bus. 15

25 6.4 The VCB Basic layer Here the lowest level layer is described. It gives a detailed description of how to use the layer and how it interacts with the VCB Core component. cs_in args_in SLOT interface : in std_logic retval_out : in std_logic_vector error_out : out std_logic_vector : out std_logic clk reset_n VCB BASIC sys_call_out call : out std_logic_vector : out std_logic msgavail_in sys_call_ret svc_error rdv : in std_logic : in std_logic_vector : in std_logic : in std_logic VCB Core interface Figure 11 The anatomy of the VCB Basic layer This is the layer that handles communication with the VCB Core block. The functions supported by the VCB Basic layer are: init, allocate, deallocate, open, close, info, put, put ready, get, get ready and flush. All of these functions are handled in this one component. The reason for this is that all of them work in (much) the same way. The following steps show how the VCB Basic layer works. The VCB Basic layer is a three stage rocket. Here comes a description of the three steps. Step 1: Wait until the chip select (cs_in) signal has been set. If Get is the requested function and the delay flag (one of the parameters to the get function) has been set to VCB_WAITFOREVER (see Appendix A Function Descriptions) and the msgavail_in signal is cleared (no message is available), then keep waiting for this condition to be false. If the above is false, then copy the contents of the args_in bit vector to the sys_call_out bit vector, which is received by the VCB Core block, and set the call signal to 1. This tells the VCB Core block that the Toolbox needs access to the VCB and which function it should execute. 16

26 Step 2: Wait until the rdv signal has been set. This indicates that the VCB core block has finished executing the desired function. If there was an error executing a function the VCB Core block sets the svc_error signal to 1. If this signal has been set then an error code has to be placed in the retval_out bit vector. However, if the info function was executed then the ten bits returned by the function should be copied to retval_out instead of an error code. If there was no error, i.e. svc_error = 0, then four cases must be handled depending on which function was executed. o Open or Close: retval_out should be set to hold both the number of messages in the specified slot (which is returned by VCB Core) along with VCB_OK (success code). o Info: Same as in the case of an error. Only copy the bits returned into retval_out. o Put or Get: These functions return an index into the message buffer for a specified slot pointing out where to store a message or where to retrieve it from. This index must be put together with VCB_OK in retval_out. o Every other function: Only put VCB_OK in retval_out. The call signal must be zeroed to deactivate VCB Core. msgavail_in is used to signal if there is a message available, but it can be set to 1 even though there is no message available. This must be handled when a Get function has been executed with the VCB_WAITFOREVER flag and it returned a queue is empty error. In this case we must start all over again, but this time the basic layer will get stuck in the first step. Otherwise the least significant bit (bit #0) in retval_out must be set to 1 (which is an indication to the slot layer that VCB Basic if finished) along with error_out which should be set to the value held by svc_error to indicate error/success. Step 3: Wait until both the chip select (cs_in) and the rdv signals have been cleared (this is to synchronize the slot layer and the VCB Core block). Then reset the retval_out bit vector and the error_out signal and start all over again. 17

27 7 Summary The Virtual Communication Bus (VCB) briefly described in this document is an IPC system implemented in hardware. The purpose of the main work described in this document has been to implement a set of tools contained in an IP block (VCB Toolbox), which will give the user (a hardware thread) the ability to communicate with software OS threads through the use of the VCB. By connecting a hardware component to the VCB Toolbox it is able to exchange information with software in blocks of 32 bits. A description of the functions implemented in the VCB Toolbox is given by Appendix A Function Descriptions. Because of size constraints the toolbox has been implemented to only handle serial requests. This means that one instance of the toolbox cannot be shared between multiple hardware threads, and the toolbox has to finish the current request (if any) before another request can be made. This behaviour matches that of the software layer, but the main reason for this design is to keep the size on an acceptable level. The VCB Toolbox is a three-layer design as shown in Figure 6. Each of the three layers have a well defined function: VCB Basic layer handles low level communication with the VCB Core block, Slot layer supplies functions to be used on slots and uses the VCB Basic layer to accomplish this, and the VCB layer uses the Slot layer to implement functions that are VCB specific. 18

28

29 Survey of Device Driver Management in Real-Time Operating Systems Sebastian Penner ABSTRACT One important property of device drivers is their, more or less accentuated, ability to provide a well behaved subsystem for application software to build on, with regard to their user interface. Ideally, device drivers should provide a uniform interface to the user, regardless of the hardware devices used. Serial and Ethernet communication channels, for example, though somewhat different, can be considered equal in terms of the user interface their device drivers provide. This, if applied to any given device, makes the user code reusable in many diverse situations. Additionally, it allows for a high degree of portability, which developers should strive for. The goal for this report has been to present a survey of the device driver systems of commercial and academic Real-Time operating systems. The commercial systems are each presented in three main categories: how device drivers are handled internally, the device driver interface, and interrupt management. Additionally, five academic real-time operating systems (Timix, Spring, Mars, HIC, and HARTIK) have been included in this survey to show the similarities and differences compared to the commercial systems. The academic section provides an overview of each system, plus details about their IPC models and the way in which they handle devices and interrupts. The conclusion and summary briefly describes each commercial system separately, alongside one single description of all the academic systems. The survey is ended with final thoughts on the different approaches that have been examined. The department of Computer Science and Electronics, Mälardalen University,

30

31 8 Introduction When building applications and systems software, which makes use of device drivers, one typically ends up with code that can only be used on the original platform. I. e., the code is hardware dependant, since the device drivers used are much likely to be handcrafted for a specific hardware device. Thus, the code cannot be used on other hardware platforms. To circumvent this problem, the dependency should be broken at a certain layer to allow portability (the application/system software can be applied on different platforms without modification). One way of accomplishing this is by using a consistent device driver interface, which applications and system software should use to gain access to device drivers. By inferring a layer between the device drivers and the rest of the software, one ensures that the software can be applied on different hardware platforms, assuming that the same operating system is used on the new platform, and that corresponding device drivers are present. This is similar to the UNIX programming environment, where the same function can be used to get data from a terminal, disk drive, or some other device, only by referencing a file descriptor. This report will focus on the central concepts of device driver management in three commercial real-time operating systems (RTOS); Spectra [1], OSE [2] and Lynx [4]. Each of these operating systems implements some kind of abstract I/O interface, which will be covered in the interface section of the report. An overview of each RTOS serves to introduce central concepts and device driver development issues. A description of interrupt handling and Interrupt Service Routines (ISR s) is also provided. In addition, five academic solutions (Timix, Spring, Mars, HIC, and HARTIK) have been examined, however, on a somewhat different premise due to their approach to handling peripheral devices. The academic section provides an overview of each system, plus details about their IPC models and the way in which they handle devices and interrupts. Note, this report is only aimed at giving the reader central understanding of device driver management in the mentioned real-time operating systems, not to be a manual for device driver development. 20

32 9 Device Drivers 9.1 Definition A device driver is a piece of code whose sole purpose is to provide a bridge between software and a designated hardware device, or category of devices, to be used when interacting with hardware. By this definition, device drivers are separate software entities that supply a set of services to the operating system and application software. Hardware can be any peripheral device (peripheral with regard to the CPU) that is accessible from where the software is currently executing. 9.2 Motivation Instead of forcing the operating system and applications to manually interface with the desired hardware device, device drivers are introduced as a simplifying layer of abstraction. In contrast to interacting with, and controlling the hardware directly, software operates on logical I/O objects provided by the device driver, which then performs all the hardware specific processing. These logical I/O objects are presented to the applications by the operating systems as a set of functions, the interface, for using the I/O device (in fact the device driver sub-system). As a consequence of using a layered design, important advantages arise. The first, out of three that strongly motivates the use of layers, is portability. In the context of software development, a software system is portable only if it can be applied on a different platform without modifications. As different platforms often use dissimilar I/O devices with varying interaction strategies, software written for one platform will not be portable, unless a uniform interface is introduced at some level. Above this interface, software is portable. Device drivers serve to provide this interface, and thus add portability. The second advantage that follows is that by separating the hardware specific code from the rest of the application, the debugging effort can be reduced. By using a structured design, were the responsibilities of the application are carefully divided among separate components, the task of debugging each component by itself is more accurate (fewer and smaller sources of error) and less time consuming, compared to debugging one large application. By using device drivers, their duties - to control and interface with hardware - are removed from the application, thus eliminating one complex source for errors. The last, and possibly, the most obvious advantage is the shortened development cycle. This becomes evident, as the application development effort can be focused on the behavior of the application, instead of on the complexity of direct device I/O. 9.3 General system layout In any general system that makes use of device drivers, the operating system provides a set of functions, through which the application can control and exchange data with the device drivers. These functions represent the device driver interface. These interface functions then pass execution to the corresponding function in the device driver body (which may or may not be an integral part of the OS kernel). Externally, the distinction between the different device drivers is typically managed though file descriptors or integer handles, which provides a unique identification towards the user. The file descriptor, or handle, is typically acquired by opening the device by way of an open interface function. Internally, the file descriptor is typically linked to a certain device driver through pointers in an OS dependant structure. All 21

33 in all, from the application s perspective, the operating system acts as a relay between the application and the device driver. Hardware devices may, in response to an event, fire an interrupt, which is a way of notifying software of an external event. Interrupts are normally managed by Interrupt Service Routines (ISR s), which are pieces of code that react and respond to interrupts. An ISR allows a device driver to lie dormant while waiting, for example, for an acknowledgement that a hardware device has performed an action. The acknowledgement is received by the ISR, which then informs or activates the device driver. Figure 12 illustrates the relationships discussed above. Note, device drivers can, as shown in the figure, either be part of the operating system image, or be dynamically added, thus reside outside of the OS kernel. The ISR has been separated from the device driver intentionally, since device drivers and ISR s do not require the others presence. Figure 12 General OS/device driver structure and layout Consider Figure 12, the application issues a call to the device driver through one of the device driver interface functions, which are supplied by the OS. The OS determines which device driver that is targeted by following the direction provided by the internal device driver mapping. The issued function may require semi directional/bi directional communication between the ISR and the device driver. 9.4 Device driver types There are several aspects that need consideration before designing a device driver. Devices use two fundamentally different approaches when it comes to transferring data to and from a device. Data can either be transferred in blocks of a fixed size, or in a continuous stream of bytes. Devices that use the block approach typically entail the concept of position on the device. Examples of such devices are disc and tape drives. These devices are managed by block device drivers. Another type of device drivers is collectively referred to as character device drivers, because they operate on devices that deliver data on a per byte basis. These devices require ordered processing of data and do not support positioning. The keyboard and serial/parallel ports are typical character devices. Character device drivers are very dynamic, and can successfully be used with block devices, or they can present a block-based interface towards the user while operating on character devices. 22

34 9.4.1 Polled devices Moreover, devices differ in the way they interact with the rest of the system, which has to be considered in the device driver. Some devices are passive, which means that software is responsible for learning about changes in the state of a certain device. This is called polling, or busy waiting, and is achieved by reading from and writing to memory addresses that correspond to a certain device, i.e. memory mapped (hardware) registers. For example, device drivers could be scheduled in such a way as to periodically check for device changes. This approach has its advantages and disadvantages, but more on that later in this section Interrupting devices As opposed to passive devices, there are those that actively inform the software system of state changes, by asserting interrupt signals, which are unconditionally received and processed by some interrupt handler software (also called Interrupt Service Routine, ISR). Devices that are capable of asserting interrupt signals are all connected, via prioritised interrupt lines, to a Programmable Interrupt Controller chip, which acts as a multiplexer, selecting the one pending interrupt with the highest priority. Each interrupt line corresponds to one Interrupt ReQuest (IRQ) number each, which is used to identify the devices on the software level. Some systems do not allow more than one connected device per interrupt line (e.g. x86), whereas other systems do (e.g. MC68000). In the latter case, the IRQ number is not enough to uniquely distinguish the interrupt sources (see section on auto-vectored interrupts). Logically connected to each IRQ number is an interrupt vector, which stores an address that points to the first, out of possibly several chained, interrupt handlers. All interrupt vectors are stored in a table called Interrupt Vector Table (IVT), or Exception Vector Table (EVT). In many cases this table starts at (base) address 0 but it can reside on different locations, in which case its base address is stored in a special purpose register. The interrupt controller can often be programmed to prevent certain interrupts from reaching the CPU, by masking the ones that should be prevented from reaching the processor. Masking is based on interrupt priority, and is used to keep interrupts below a certain priority level pending until that level of priority is allowed once again by altering the mask (see Figure 13). On the bus level, interrupts can be implemented as vectored or auto-vectored/polled (see sections and below). Figure 13 MC68000 has seven interrupt leve ls of which 6 can be masked 23

35 Auto-vectored In systems with a Programmable Interrupt Controller chip that give interrupting devices one priority each, based on which input line they are connected to, the location where the interrupt vector is stored can be derived from the IRQ number. To retrieve the vector address of a specific interrupt, multiply the IRQ number with the byte size of a pointer and add the base address of the IVT. In Auto-vectored systems, the processor performs this automatically after any possibly required handshaking with the interrupt controller. Prior to vector address retrieval, registers (typically the program counter and stack pointer) need to be stored in order to be able to return to the currently running application. Afterwards, execution continues at the address pointed to by the interrupt vector. Some platforms, e.g. MC68000, allow multiple devices to be connected to the interrupt controller on the same interrupt line, in which case the interrupt source for that IRQ number can be any of these devices. Therefore, the software pointed to by the vector must poll each device, or the device it is responsible for, to determine the interrupt source. This is why autovectored interrupts sometimes are referred to as polled interrupts. There are several different approaches to accomplish this. One approach could be to force each ISR to retain the pointer for any previously installed ISR upon registration, and pass execution to that handler using the address if the current handler could not successfully process the interrupt on its vector. Another approach, as we shall see in the Spectra interrupt handling section, is to have one default interrupt handler that, in turn, passes the interrupt and event (why the interrupt was asserted) pair to all handlers that have been registered on the current vector. Each handler must then return with yes or no, whether or not they recognised and were able to successfully process the interrupt and event pair. If negative, the default handler passes the pair to the next handler. This is repeated until a handler claims the interrupt and event pair, but only for as long as there are additional handlers Vectored As opposed to auto-vectored interrupts that are mainly used by older devices, relatively new hardware can assert vectored interrupts. When a vectored interrupt is asserted, the processor performs the required handshaking, after which the device places a (usually 8-bit wide) vector number on the data bus for the processor to use when retrieving a handler for the interrupt. It is the users responsibility to program vector numbers into all vectored devices before the first interrupt can occur. Thus, vectored interrupts make it possible for the system designer to split devices with equal importance onto different vectors, which reduces the handler overhead because each handler is uniquely responsible for interrupts on a certain vector. A device can even be programmed to use multiple vectors for each separate event (there can be several events that can cause an interrupt to fire), which further helps to reduce handler overhead and complexity Case study MC68000 The MC68000 supports both auto-vectored and vectored interrupts [15][16], which means that the processor must be able to determine which schema is used with the currently interrupting device. This is accomplished during the second half of the interrupt request cycle. However, let us start from the beginning. A device arrives in a state where it needs attention, and thus raises the IRQ-line on which it is connected to a logical 1. The priority encoder chip translates its highest numbered active IRQ input line into the corresponding three-bit priority and passes it to the processor on the IPL0-IPL2 lines. The processor then compares the 24