% %===================== VXI RM basic software ====================== % \documentstyle[11pt,a4wide]{article} \def\EG{EUROGAM} \def\EB{{\sf EUROBALL}} \def\VR{{VXI-RM}} \def\DB{{\sf Data Base}} \def\Vc{{\sf VXIconfig}} \def\Vs{{\sf VXIslot}} \def\Vd{{\sf VXIdevice}} \def\Va{{\sf VXIaddressMap}} \def\Md{{\sf ModuleDescription}} \def\Ch{{\sf DAQchannel}} \title{VXI Resource-Manager Basic Software} \author{Christoph Ender} \date{3-Sep-1990 Draft 0.4} \begin{document} \maketitle \begin{quotation} \small This version of document is a draft one. Changes will be made with the progress of discussion. It is for \EG\ internal use only ! Do not distribute this draft document to any other organisation outside the \EG\ collaboration. {\bf Note:} together with this version of the software the phase model of the VXI/DAQ tasks, processes is introduced. Together with that and other more refined definitions of the \Md\ data base structure it allows a very detailed and fine tuned control over each step of operation in the live (that means from power up to controlled power down, and during error recovery) of the software. \end{quotation} \section{Introduction} This document specifies the basic software of the \VR\ in terms of their function, structure, and data. It defines further the detailed interface between the RM and the user/application software including a network based RPC access. The aim of this software is to write an operation system independent software which is executed in an early stage of the initialization of the \VR\ processor. This has to be done on a crate basis. In a later stage the connection to the other parts of the system (central data base, data acquisition control, Event formatter, ... ) will be done. \section{Overview} The overall structure of the software is shown in Fig.\ \ref{VXIRMS.over}. This picture gives an overview to the parts related to this document. In addition the relationship between the data base structures and the software is shown. The required data base tables in a brief overview are displayed within a double lined box, the main programs are within the dashed box. \begin{figure}[htp] \setlength{\unitlength}{1mm} \begin{picture}(140,120)(0,0) \small \put(0,0){\framebox(140,10){Hardware}} \put(0,10){\framebox(30,20){\shortstack{\VR\ access\\ routines\\A16/D16}}} \put(25,25){\makebox(5,5){$\ddag$}} \put(30,10){\framebox(30,20){\shortstack{\VR\\VMEinterface\\access DC,SC}}} \put(55,25){\makebox(5,5){$\ddag$}} \put(60,10){\framebox(30,20){\shortstack{Interrupt and \\other support\\Routines}}} \put(85,25){\makebox(5,5){$\ddag$}} \put(100,10){\framebox(40,30){\small\shortstack{VXI Message passing\\ shared memory protocol$~*$\\IEEE 488.2$~*$}}} \put(135,35){\makebox(5,5){$\ddag$}} \put(-2,38){\dashbox(94,59){2}{}} \put(10,40){\framebox(80,15){\shortstack{Initial and Autoconfig\\ \small Phase A}}} \put(85,50){\makebox(5,5){$\ddag$}} \put(0,60){\framebox(60,10){\shortstack{Initial Phase B}}} \put(55,65){\makebox(5,5){($\ddag$)}} \put(0,75){\framebox(30,20){\shortstack{Data Acquisition\\ Control}}} \put(30,75){\framebox(30,20){\shortstack{Diagnostics\\Tests}}} \put(60,75){\framebox(30,20){\shortstack{local data-\\ base handler}}} \put(85,90){\makebox(5,5){($\ddag$)}} \put(98,48){\thicklines\framebox(44,49){}} \put(100,50){\framebox(40,15){\shortstack{VXI Config Table\\ Address Map Table}}} \put(135,60){\makebox(5,5){$\ddag$}} \put(100,65){\framebox(40,15){\shortstack{Module description table\\ basic initial\\basic Tests}}} \put(135,65){\makebox(5,5){$\ddag$}} \put(100,80){\framebox(40,15){\shortstack{\EG\ configuration\\ DAQ channel table\\ statistics, spectras}}} \put(0,100){\framebox(80,20){Network Interface (RPC)}} \put(75,115){\makebox(5,5){$\ddag$}} \put(90,100){\framebox(50,20){Console Interface}} \put(135,115){\makebox(5,5){$\ddag$}} %<>... \end{picture} \caption[Software overview]{Software Overview. Parts marked with a $~*$ will be not implemented during the first phase. Boxes marked with a {$\ddag$} are part of the \VR\ software. Sometimes only a part of them is really related to the basic resource manager functions, another usage (not in \EG ) will need only a subset. The parts in the dashed box are the programs which are executed, all others are part of the support routines. The part with the double box contains the data base tables. }\label{VXIRMS.over} \end{figure} \begin{table}[htp] \small \caption{Phases of operation}\label{VXIRMS.phases} \begin{center} \begin{tabular}{|r@{.}l|r|l|p{9cm}|} \hline \multicolumn{2}{|c|}{{\large\strut}No.}& \multicolumn{2}{|c|}{Phase Model}& Description \\[2mm] \hline \multicolumn{5}{|c|}{Phase A}\\ \hline 1 & & &ini & RM Software startup{\large\strut} \\ & 0 & 0 & & primary bootstrap of CPU \\ & a & 1& ini\_a & call of VXI-Initial Software \\ & b & 2&ini\_b & initial of internal data structures and variables \\ & c & 3&ini\_c & reset RM Registers by software \\ & d & 4&ini\_d & initial own VXI Registers \\ & e & 5&ini\_e & bring own registers in operation \\ & f & 6&ini\_f & check for possible salves and reset them \\ & g & 7&ini\_g & set end of primary initialisation \\[2mm] \hline \multicolumn{5}{|c|}{Test Phase A}\\ \hline 2 & & &stst & Self test \\ & a & 8 &stst\_a & self test of VXI-Registers (read/write functionality)\\ & b & 9 &stst\_b & test available slaves (FADC, P3) \\[2mm] \hline \multicolumn{5}{|c|}{Phase A}\\ \hline 3 & & 10 & aconf & Auto configure system \\ \hline 4 & & &start & start up of the operating system \\ & & & & operating system is up, network is running \\[2mm] \hline \multicolumn{5}{|c|}{Phase B} \\ \hline 5 & & 11 & saconf & Secondary Autoconfig and Initial \\ & & 12 & satst & Secondary tests and diagnostics \\ \hline 6 & & 15 & netw & Start of Network part and connection to common data base \\ & & 16 & netwsynch & synchronize all crates \\ \hline \multicolumn{5}{|c|}{Phase C}\\ \hline 7 & & 20 & oper & Normal operation \\ %<> & <> & <> & <> \\ \hline \end{tabular} \end{center} \end{table} To meet the VXI-specifications it is required to split the execution into several phases as shown in table \ref{VXIRMS.phases}. More details how this will work are explained in section \ref{VXI.PHM} Access to the software from an external (other CPU, another crate) will be available via two ways: \begin{enumerate} \item Network Interface using RPC calls, they are ontop of the TCP/IP network system. That will be the normal way of operation for all network interaction, only a few requests will response to multicast operations. \item Console Interface\\ This part is required for a test interface, to display urgent error messages onto the console terminal, and to interactive use of a VXIcrate for local tests and interactive diagnostics. Unfortunately the implementation will be in part dependent on the operation system (VxWorks, OS9, ... ). The planned software has to allow some primitive access to the VXI registers, and to the local/global data base. \end{enumerate} \section{RM-basic software} This will be some kind of interface routines to access the \VR{} via its logical and geographic address space using A16/D16 access cycles. It is necessary to prepare the basic initialisation to set up the configuration tables which will be filled out in detail in a later step. The basic software routines covers the following parts: \begin{itemize} \item basic access routines (read/write short word) with logical addressing using A16/D16 access \item geographical addressing using the MODID register \item logical addressing using A16/D16 address \item creation and access to the \Vs , \Vd , and the \Vc tables \item creation and manipulation of Module Table \item creation and manipulation of the channel Table \item creation and manipulation of the address mapping table \item logical addressing using A16/D16 address \item access routines via A24 or A32 \end{itemize} Beside this routines some additions for the error handling is necessary. The most important is the control of the access within the VXI crate during VXIbus/VMEbus transfers. They can be controlled for the right bus protocol using the CPU hardware. This hardware has to report the error to the access routines. {\em Implementation via the Bus Trap Error Routines.} \subsection{RM initial Software} This part is described in detail within the VXI spec's section C.4.1 . The first step has to be the primary initial the RM itself and the initial of it's own logical address to 0 if the RM is itself a DC VXIbus device. With this initial a first test to check the address bus and the databus via the P1/P2 adapter card should be foreseen. \subsection{Slave Interface} Beside the test and initial of the VXI-RM parts the first test of the slave part and the required initialization has to be done. The basic software will contain some routine to access the slave part. They include the access to registers and allow block transfer in 16bit or 8 bit mode. At the moment three different slaves has to be initialized: \begin{enumerate} \item {\bf P2 A+C row adapter card} More Information will be found in a document by R.\ \"Ohlschl\"ager. \item {\bf P3 card} This card contains the basic registers, which deal with the trigger lines. Currently four registers are defined for that purpose. The initial has to make sure that the drivers are all in an inactive state. {\em A full specification will be available in late September. After that the software requirements can be specified.} \item {\bf FALA card} a combination of a flash ADC system and a small set of logic analyzer system. This card will have 32 registers. With the initial bit set in the control and status register of this device it will be inactive. The next step will be the setup to the default values to allow simple operation via the console interface. Details over that card will be found within the FALA specification. \end{enumerate} \section{Phase Model of the VXI Software} During definition of the software one reaches the point where several phases of initial and tests has to be controlled. The easiest way is to allow for each phase several actions like {\sl initial, test, diagnostics} which are executed in that order. At the end of each phase the phase control software checks that all tasks which may be stared during the execution of the different action have finished and passes then the control to the next phase of operation. With this general organisation one can organize the required actions of the \VR\ startup into this phase model. Also the phases which will occur later can be described very easily in this picture. {\bf The only thing which is necessary is a clear definition about the phases during the live of a processor / process / task, which has to be used by all software components involved in the \EG\ all successor experiments}. The table \ref{Soft.phase} might be a first definition of such a system. \begin{table}[thp] \small \caption{Phase model of the Data Acquisition Software live. This includes all phases which has to be synchronized. }\label{Soft.phase} \begin{center} \normalsize\begin{tabular}{|c|p{8cm}|} \hline \multicolumn{2}{|c|}{Local startup phase}\\ \hline 0 & primary boot \\ \hline \multicolumn{2}{|c|}{Global Synch phase}\\ \hline 20 & wait for all crates available \\ 40 & Start Data Acquisition \\ \hline \multicolumn{2}{|c|}{Global Asynchronous Operation Phase}\\ \hline 100 & General Consistency Check \\ \hline \multicolumn{2}{|c|}{Local Test and diagnostic}\\ \hline 200 & Test all Modules \\ \hline \end{tabular} \end{center} \end{table} In this model phases 0 ... 20 are local, per CPU defined phases which can be executed from the system point of view asynchronously. After that all phases with number between 20 ... 99 requires synchronisation between the different parts of the data acquisition system. \section{Initial Phase (Auto Configure)} The initial phase takes place after the \VR\ initial. It is called also Phase A and occupies in the Phase model step 0 ... 10. \begin{enumerate} \item Identify all VXIbus devices in the crate (system) and write there current data values into the VXI configuration database. \item Configure all resources required for the proper \VR\ operation (allocate memory, setup location monitor for message based operation) \item start system self test and diagnostic sequence \item construct A24 and A32 address maps. Therefore read address space requirements and configure table in a way that there is no overlapping area. For both parts a separate map is required. {\em The AM (access modifiers) ensures that there is no overlap even if the address may be the same ! Nevertheless the overlap of addresses should be avoided.} Load after construction of the addresses the address registers. \item {Configure commander/servant hierarchy}\\ At this time the primary selftest of the VXIdevice modules has to be ready for all devices. Then the software has to prepare the RM in such a way that a primitive message based protocol can be used. All associated message based devices has to be someone's servant, at least the RM has to be a servant. For the first phase of the \EG\ project the VXI devices this will be implemented in the simplest possible way, a register based device. therefore only a very simple way of initialisation of the \VR\ message protocol registers is required, There will be in the near future (beginning 1991) no need to build message based modules. To allow then the incorporation of other modules in a second phase of development of the RM software a full set of message handling routines will be provided together with an implementation of a 488.2 interface. \item {Initial normal operation}\\ Bring all message based devices in operation. \end{enumerate} After that the VXI crate is in a normal operation mode. For initial of the VXIbus devices for use by \EG\ further device dependent initialization is necessary. This will done after the operating system of the \VR\ is up and running. \section{Secondary Auto Configure} After the OS and the network is up and running we have access to the central database. During this phase extended device tests and initial will take place. The information for this tests and initial will be found in part in the module description, which is necessary even in the primary initial phase to identify the modules itself. The other part of the information will be stored in the central database. Therefore the VXIcrate has to interact with the data base. The connect between the two systems can be done via a broadcast request ({\bf Broadcast-all-RPC}) to the data base. The broadcast is necessary due the fact that the RM do not know the network address of the data base server, on the other hand the data base server also might not know the network address of the VXI crate. After the acknowledge of the initial broadcast the normal interaction between the system will be done with RPC messages. If there is no acknowledge within a certain time the request is repeated for up to 100 times (5Min). If there is still no acknowledge after that time the VXIcrate will go into a local mode only. To bring the VXIcrate up, even in the case that the data base server was not available within 5Min after network initial, it is allowed to access the VXIcrate by some kind of data acquisition software with a {\em claim crate} procedure. After that the secondary Autoconfigure phase may be requested via a RPC call from the data base server or by the data acquisition control. After the connect between the VXI crate and the central data base they has to exchange the VXIcrate internal database. The information which have to be transported to the central database are: \begin{enumerate} \item how many modules, VXI RM internal configuration, network address \item VXIdevice information, Module identifiers, logical and geographic address, device capabilities, address mapping (A24/A32 address and size), \item status information over failed modules \end{enumerate} With this information the \VR\ can retrieve module dependent test information from the database and start the VXI device diagnostic tests (see a separate paper, which describes the module database and test specification software). After the tests are executed the results are written back to the data base. If the device has passed this tests it has to be initialized with some values which brings the data acquisition modules in principle operation (default values). After the last VXIdevice has passed this test and initial sequence the \VR\ will forward a message to the central data base and/or data acquisition control that it has finished the local configure, test and initial phase. The VXIcrate can be used after that in by the acquisition control to start in the VXIcrate another task which will do the load of the experiment specific values. Other tasks will be available for online diagnostics and tests. All these tasks has to go through common routines which provide the VXIcrate local locking of modules (or part of modules). The necessary locking information will be located inside the VXIcrate configuration database. \section{Primitive Database} The \VR\ has to setup for his own use a VXI system (as far as the RM can access VXI crates) data base. For diagnostic this database should contain a copy of the configuration registers. But not only that one which can be read, also the hidden registers (note that some registers carries several information read/write functions are different). Beside that information further areas for locking of a module. To allow a more general use of that database it has to be VXIdevice independent. The device dependent information will be found in the Module Data base. This describes the modules itself and there requirements which will be not found in the VXI configuration registers. Information found in the Module data base and the VXIconfiguration database allows the \VR\ to construct a data acquisition data base which can be used by the data acquisition. This data base table will contain all device dependent status information, spectras,... . \subsection{VXI Configuration Data Base} This part contains the a copy of all VXI configuration registers. Dependent of the device type (Memory, message, register, extended) all registers are stored here. The access routines to the VXI configuration space have to store here the information, which then can be used for diagnostic and status informations. The access to this data base should be done by a mapping table to get the right position within this table to store or to read out the information. Due to the fact that a read of the original VXI configuration registers does not give the right information back, bit manipulation operations need this copy of the data content of the hidden data register. The VXI Configuration data base has to index paths, one via the Slot number and the second via the VXI logical device number (0 ... 254), the address 255 is reserved for dynamic configurable devices. \subsection{Module description data base} To identify and to describe a module some informations over that are required. This information will be found in this table. It will be include also some basic tests as well as the identification where to find further diagnostics and test programs. The detailed form will be found in the data base specification. \section{Network Interface} The Network Interface is required to allow the Data Acquisition system to send commands, setup parameter, and control information to the VXI system. It acts then as in term of an data acquisition crate, and performs the so called crate functions. There the crate has to do functions like diagnostics, tests, and tuning of the data acquisition parameters itself like gains, offset, CFD parameters, ... . In principle all the data can be divided into several classes. \begin{enumerate} \item access to the VXI modules via the VMEbus address space or the VXIspecific geographic/logical addressing specs. \item access to the \VR\ specific slaves like the FADC, P3 sub card, and some of the special slave functions \item access to the different data base tables, to load or retrieve values \item access to the message based functions \item access to the primitive functions and the control over the RM \end{enumerate} Up to now only the external access to the crate is explained. The \VR\ base software should have also the direct active access to the system. One point therefore is the communication with the Data base server to store there error-- and other useful logging informations. The other point is to request the specific functions in the case of initialisation, power error, or other important conditions which requires an immediate action. As the basic organisation structure an RPC interface is foreseen. There all functions of the basic software can be connected to the RPC interface quite easily. {\em At the moment it is not clear for me, which type of RPC model the proposed RPC interface has to follow. Problems will be rising if we have several concurrent tasks, each with it's own connection to a RPC channel, which can produce under certain conditions an deadlock. Also it is not clear what will happen when several tasks (user application, data base server for periodic requests, data acquisition control) on different CPU's requests the same RPC channel on the same target CPU. Implements the SUN RPC an asynchronous or a synchronous operation model ???} \section{Console Interface} This interface allows to access in a primitive way the VXI crate. It will be constructed around an interpreter. Beside the very primitive operations like read and write operations, also access to the \VR\ databases are necessary. \marginpar{\em to be completed} \section{Module Dependent Basic Configuration} This part also called Autoconfiguration part two will be implemented in a type of data base scan, where the \VR\ software will retrieve information from the database to execute then the program/code/actions found there. This way of operation allows to define an abstract interface without knowing what type of interfaces will be used in future. It is foreseen that an unlimited number of configuration actions can be specified in the Module description data base (a text file). \appendix \section{Call Interface} Here the calls to the basic routines are specified. The C specification syntax is used. \subsection{VXI access functions} VXi access functions are these functions which write, read, or manipulate the VXI configuration registers, including the message handling. \begin{itemize} \item basic access routines (read/write short word) with logical addressing using A16/D16 access \begin{itemize} %\item {\tt } \item {\tt status = VXIreadLogA16D16(LogicalAddress,Offset,\&Data)} \item {\tt status = VXIwriteLogA16D16(LogicalAddress,Offset,Data)} \item[] {\tt LogicalAddress} The VXI logical device number \item[] {\tt Offset} Offset within VXI device configuration area \item[] {\tt Data} 16bit data word to read or to write \item[] {\tt Status} The routines gives back a status words to signal that the data are transferred successful by the hardware (no Bus Error), that the LogicalAddress is within a valid range\footnote{After the initial only access to autoconfigured VXIdevices is allowed.}. In addition the offset is also tested for a valid range $(0...63)_{10}$. \end{itemize} \item geographical addressing using the MODID register \begin{itemize} \item {\tt status = VXIreadGeoA16D16(SlotNr,LogicalAddress,Offset,\&Data)} \item {\tt status = VXIwriteGeoA16D16(SlotNr,LogicalAddress,Offset,Data)} \item[] Same as above \item[] {\tt SlotNr} VXIcrate slot number to access Modules using the MODID line \end{itemize} \end{itemize} \subsection{VME access functions} \begin{itemize} \item logical addressing using A16/D16 address \begin{itemize} \item {\tt status = VXIreadA16D16(LogicalAddress,\&Data)} \item {\tt status = VXIwriteA16D16(LogicalAddress,Data)} \item {\tt status = VXIreadBlockA16D16(LogicalAddress,Number,\&Data)} \item {\tt status = VXIwriteBlockA16D16(LogicalAddress,Number,\&Data)} \end{itemize} \item access routines via A24 or A32 \begin{itemize} \item {\tt status = VXIreadA24D16(Address,\&Data)} \item {\tt status = VXIwriteA24D16(Address,Data)} \item {\tt status = VXIreadBlockA24D16(Address,SizeOfBlock,\&Data)} \item {\tt status = VXIwriteBlockA24D16(Address,SizeOfBlock,\&Data)} \item {\tt status = VXIreadA32D16(Address,\&Data)} \item {\tt status = VXIwriteA32D16(Address,Data)} \item {\tt status = VXIreadBlockA32D16(Address,SizeOfBlock,\&Data)} \item {\tt status = VXIwriteBlockA32D16(Address,SizeOfBlock,\&Data)} \item {\tt status = VXIreadA24D32(Address,\&Data)} \item {\tt status = VXIwriteA24D32(Address,Data)} \item {\tt status = VXIreadBlockA24D32(Address,SizeOfBlock,\&Data)} \item {\tt status = VXIwriteBlockA24D32(Address,SizeOfBlock,\&Data)} \item {\tt status = VXIreadA32D32(Address,\&Data)} \item {\tt status = VXIwriteA32D32(Address,Data)} \item {\tt status = VXIreadBlockA32D32(Address,SizeOfBlock,\&Data)} \item {\tt status = VXIwriteBlockA32D32(Address,SizeOfBlock,\&Data)} \end{itemize} \end{itemize} \subsection{Slave Functions} To access the \VR slave interfaces six functions can provide a full functional programming interface. \begin{itemize} \item {\tt err = slave\_read(slave\_addr,\&data)} \item {\tt err = slave\_write(slave\_addr,data)} \item {\tt err = slave\_read\_block(slave\_addr,N\_datawords,\&data)}\\ 16 Bit transfer \item {\tt err = slave\_read\_block8(slave\_addr,N\_datawords,\&data)} 8 bit data transfer \item {\tt err = slave\_write\_block(slave\_addr,N\_datawords,\&data)} \item {\tt err = slave\_write\_block8(slave\_addr,N\_datawords,\&data)} \end{itemize} \subsection{Data Base functions} \begin{itemize} \item creation of VXIdevice configuration table The access to the configuration Table can be done in two ways: first to use the geographical access to select a module, or by use the logical addressing by specification of the VXIbus device (0...254). The configuration table is constructed in a way that both allows the access to all data. \begin{itemize} \item {\tt status = VXIDBcreateConfigTable(TableAddress , SizeOfEntry)} \item {\tt status = VXIDBinsertConfigTable(SlotNumber , Offset , Data)} \item {\tt status = VXIDBgetConfigTableEntry(SlotNumber , \&DBrecord)} \item {\tt status = VXIDBputConfigTableEntry(SlotNumber , \&DBrecord)} \item {\tt status = VXIDBinsertDeviceTableEntry(LogicalAddress , Offset , \&DBrecord)} \item {\tt status = VXIDBgetDeviceTableEntry(LogicalAddress , \&DBrecord)} \item {\tt status = VXIDBputDeviceTableEntry(LogicalAddress , \&DBrecord)} \end{itemize} \item creation and manipulation of Module Table \begin{itemize} \item {\tt status = VXIDBcreateModuleTable(TableAddress , SizeOfEntry , NumberOfEntries)} \item {\tt status = VXIDBinsertModuleTable(ModuleID , TypeOfEntry , \&MDBentry)} \item {\tt status = VXIDBfindInModuleTable(ModuleID , TypeOfEntry , \&MDBrecord)} \item {\tt status = VXIDBgetModuleTable(ModuleID , TypeOfEntry , \&MDBrecord)} \item {\tt status = VXIDBputModuleTable(ModuleID , TypeOfEntry , \&MDBrecord)} \end{itemize} \item creation and manipulation of the channel Table \begin{itemize} \item {\tt status = VXIDBcreateChannelTable(TableAddress , SizeOfEntry , NumberOfEntries)} \item {\tt status = VXIDBinsertChannelTable()} \item {\tt status = VXIDBfindChannelTable()} \item {\tt status = VXIDBgetChannelTable()} \item {\tt status = VXIDBputChannelTable()} \end{itemize} \end{itemize} \subsection{Autoconfigure Functions} \begin{itemize} \item creation and manipulation of the address mapping table \begin{itemize} \item {\tt status = VXIDBcreateAddressMapTable(TableAddress)} \item {\tt status = VXIDBinsertAddressMapEntry(Type , VXIDeviceNumber , Size)} \item {\tt status = VXIDBconstructAddressMap(Type)} \item {\tt status = VXIDBgetAddressMapEntry(Type , VXIdeviceNumber , AddressOfset)} \end{itemize} \item related to overall autoconfiguration \begin{itemize} \item {\tt status = VXI\_AutoConfig\_initial()} \item {\tt status = VXI\_AutoConfig\_PhaseA()} \item {\tt status = VXI\_AutoConfig\_PhaseB()} \end{itemize} \item other support routines like Bus Trap Error, error display \end{itemize} \subsection{Access of VXIsystem Functions} There will be two different ways of access: local and global. In this section the local access (also stand alone access) is addressed. \begin{itemize} \item Console Interface \item Reset functions %\item \end{itemize} \subsection{Network specific part} \begin{itemize} \item access to other crates \item access to data base server \item access from other crates \item access from data base server \item access from application programs \item Reset system \item error logging \end{itemize} %\section{Hardware Software Interface} \section{Software Modules (Overview)} \subsection{Definition Files} The definition files can be divided into several classes: \begin{enumerate} \item CPU and Operating System type specific: to hide system dependencies. This is not really necessary for \EG\ because of the use of the MVM147 CPU under VxWorks. For the development other Systems will be used. There and even in a later phase of the project there might be changes, so we need some universal definition files to hide all dependencies. The files are: \begin{itemize} \item {\verb+CPU_E5.H+} \item {\verb+CPU_MVM147.H+} \item {\verb+CPU_VAX.H+} \item {\verb+OS_OS9.H+} \item {\verb+OS_VMS.H+} \item {\verb+OS_VXWORKS.H+} \end{itemize} \item Universal VXI definitions will be also available \begin{itemize} \item {\verb+VXI_CONF_REG.H+} \end{itemize} \item The Resource Manager Data Registers, the flash ADC part, and P2/P3 card \begin{itemize} \item {\verb+VXI_EGRM.H+} \item {\verb+VXI_FALA.H+} \item {\verb+VXI_P3.H+} \end{itemize} \item Data Base part \begin{itemize} \item {\verb+VXI_DB_CONF.H+} \item {\verb+VXI_DB_DAQ_CHANNEL.H+} \item {\verb+VXI_DB_MODULE.H+} \end{itemize} \item Network part not written yet \end{enumerate} \subsection{Code Modules} \subsection{Program/Task Modules} \subsection{Data Base Programs} \subsection{Support Programs} \subsection{Programs for Test of Software} \end{document}