2 OVERVIEW

This manual covers the device-specific part for the VMIVME-5576 Reflective Memory Board. For a general overview about drivers and devices, refer to the Driver Development Guide [7].

2.1 The Hardware

The VMIVME-5576 Reflective Memory Board provides dual-port memory (DPRAM) which is replicated and automatically updated in each board connected to the reflective memory network. The board's memory can be accessed through standard VME R/W cycles from the local backplane. The board allows also to generate remotely interrupts to one or more nodes (network interrupts). These interrupt signal is used to synchronize two nodes. It may act as a trigger to start a task on a remote node, or it may implement a protocol for data transfer between two nodes. In this last case the interrupt can be sent to inform the remote node that some data have been updated in the reflective memory and are ready to be used.

The board's Dual-Port RAM can be accessed either in the VMEbus A24 standard or in the A32 extended address-space, depending on the setting of one on-board jumper, and supports D8, D16 and D32 data transfer. Depending on the size of the user memory installed on the board, it spans 256 KB, 512 KB or 1 MB of the VME address space (the first 64 bytes are reserved for the register memory).

2.2 The Driver

This driver implements the functionality of the VMIVME-5576 Reflective Memory Board, that is it gives the same functionality as the board and does not combine elementary functions to more complex functions. This is left by purpose to the software using the driver in order to achieve the maximum flexibility.

2.3 The Devices

The whole board is regarded as one device. As recommended in [7], the device-names are derived from the module-name "rmn", i.e. the devices must be named "/rmn0", "/rmn1", etc.

The driver can control several devices simultaneously, where each device consists of the same type of hardware, using the same code but with different sets of data for each device. The set of data defining the device and containing the status of the device is called device descriptor table.

2.4 Device Access

The driver conforms to the LCU software specification [2], particularly in the following respects:

· The driver conforms to the VxWorks driver concept, that is it supports the functions open, close, and ioctl. It also provides the recommended installation functions (see section 4 of this manual).

· The driver controls the access of the device, provided by the open/close calls giving the possibilities:

· There is a possibility to force the release of a channel opened in EXCLUSIVE mode (Free Device command).

· The driver calls are mutually exclusive, that is the device accessed by a task is protected from access from any other authorized task until the executing driver call has terminated. They will be blocked and put on a queue. There is one queue for each device and the processes on the queue will be scheduled according to their priority. The implementation of the driver uses the VxWorks mutex semaphore for this functionality and to provide priority inheritance, see reference [4].

· A task blocked for access of a device has a timeout. An error will be returned upon exceeding the timeout.

Ioctl commands directly accessing a register do not have any protection from simultaneous access as the command is executed by an immediate action, that is in one non-interruptable instruction. In this case there is no need for any protection as no other process can interfere during the action.

2.5 Interrupts

The VMIVME-5576 Reflective Memory Board occupies 4 interrupt-vectors (INT0-3) and can be assigned to one out of seven interrupt-levels. The interrupt-vectors should be chosen in such a way that they will not conflict with the configuration of the other VLT standard VME boards [8].

The local interrupt INT0 is dedicated to generate an interrupt in the event that the board's data transfer capacity is going to be overloaded or a transmission error occurs. If this interrupt is enabled, every time the reflective memory is written from the local VME backplane and the transmit FIFO is over half-full or a corrupt transfer occurs, the INT0 will be generated. The information related to the situation of half-full transmit FIFO is also available by monitoring the bit 5 of the Control and Status Register (CSR). When the transmit FIFO becomes full, a BERR will be generated if a new write is attempted. The application shall avoid that this situation will never occur.

The three network interrupts INT1-3 are available for remote signalling between CPUs. These interrupt signals may be used to synchronize processes distributed on two or more CPUs, or to inform about the availability of some computed data which have to be shared. A network interrupt can be either sent to a specific node or broadcast to all the nodes in the reflective memory network.

All 4 interrupts can be served by a user-provided ISR, if configured and enabled. Each interrupt source can be configured to run the ISR at interrupt level, by passing the pointer of the user-provided routine, or in the normal task context, by "taking" a synchronization semaphore, that is automatically "given" by the driver when the interrupt occurs.

When the local interrupt INT0 is detected, even though there is not user-provided ISR configured, the driver sets (on) the Fail LED on the board front panel and logs the error into the VxWorks logging system.

2.6 Special Features

The VMIVME-5576 Reflective Memory Board can be operated in a redundant transfer mode (jumper Fast Field J5) in which each transfer is transmitted twice. In this mode the data transfer rate is reduced from 6.2 MBytes/s to 3.2 MBytes/s, so that the probability of both transfers containing an error is negligible. When the board is used in redundant mode the transmission error detection should be masked off (jumper Mask Field J3), so that the INT0 can be generated only by an over-half-full transmit FIFO and the possible ISR does not need to monitor the bit 5 of the CSR.

2.7 Include files

Applications using the rmn must include rmn.h. The rmn.h include file includes everything required to use the procedures described in the previous section.

· "rmnCommands.h" which defines literals of the rmn Driver commands and the data structures for multiple argument commands as used with the ioctl function.