Understanding the VXI/VME Interrupt and Signal Acknowledge CycleThe VME bus specification defines the Priority Interrupt Bus so that a VME device can asynchronously request service from a controller. This gives a VME/VXI device a way of getting the controller’s attention at any time. A VXI/VME bus system has seven interrupt lines physically connected to all slots in the chassis. This document addresses interrupts on both VME and VXI systems. Interrupt line 7 has the highest priority, and interrupt line 1 has the lowest priority. In addition to the actual interrupt lines, the Priority Interrupt Bus also consists of a daisy-chained interrupt acknowledge signal and parts of the Data Transfer Bus (the data lines, the data acknowledge line, and the lower three address lines). The table below summarizes each signal used in the Priority Interrupt Bus and summarizes the function of each signal. A device that requests service by asserting one of the interrupt lines is known as an interrupter. A functional device known as an interrupt handler services the interrupt. There can be more than one interrupt handler in a VXI/VMEbus system. National Instruments embedded controllers and external MXI bus controllers allow you to configure multiple interrupt handlers (from one to seven).
Table I. Priority Interrupt Bus Signals
A more detailed explanation of what happens in the interrupt cycle is outlined below. A device that requests service by asserting one of the interrupt lines is known as an interrupter. A functional device known as an interrupt handler services the interrupt. There can be more than one interrupt handler in a VXI/VME bus system. However, there can only be one interrupt handler per interrupt level in the system. National Instruments embedded controllers and external MXI bus controllers allow you to configure multiple interrupt handlers (from one to seven). Therefore, two types of interrupt handler systems are possible:
In a single handler system, one interrupt handler device services all interrupt lines. In a distributed system, there are two or more handlers, each servicing an exclusive subset of the seven interrupt lines. Most systems are single handler systems, where the system controller handles all interrupt lines in the chassis. It is possible for VXI devices to act as programmable interrupt handlers, but this is not very common. The Resource manager detects programmable VXI interrupt handlers and uses information stored in the device’s configuration registers to assign the interrupt levels that will be handled by the VXI device. Note that VME devices do not define a standard set of configuration registers - you must use Test and Measurement Explorer or VXI Edit/vxitedit to enter any configuration information associated with the VME device. There are two types of interrupters:
Most VXI and VME instruments fall under the ROAK category and the sequence of events described below is only applicable to ROAK devices.
The Sequence of Events During an Interrupt (IACK*) Cycle The interrupt handler reads the status/ID. Because the interrupt lines are open collector lines, more than one device can assert the same interrupt line at the same time. Therefore, the module asserting the interrupt does not propagate the IACK* signal. This action prevents other devices that are interrupting on the same line from getting the IACK* signal and attempting to respond at the same time. After the interrupt handler services the interrupter, the interrupter releases the line. If other devices are interrupting on the same line, the handler then begins another interrupt acknowledge cycle to service the next interrupter on that line. The following figure illustrates the interrupt acknowledge daisy-chain.
Note: RORA devices require you to read/write a device specific register in order to complete the interrupt acknowledge cycle. In this figure, the device in slot 4 has asserted an interrupt. The figure shows that if more than one device asserts the same interrupt line, the device closest to slot 0 (slot 1 in VME) has the highest priority for interrupt service because it receives the IACK* signal first. The next closest device has the next highest priority, and so on. It is important to remember that the IACK daisy chain must be connected across unoccupied backplane slots, or else interrupts coming from devices to the right of the empty slot will not be acknowledged. Most chassis have jumperless backplanes where this daisy-chain connection happens automatically. However, on older backplanes that are jumpered, jumpers must be used to connect the IACK daisy chain across unoccupied slots. On jumpered backplanes, you should also pull the jumpers from the occupied slots so that the IACK daisy-chain is not mistakenly connected through the slot containing the interrupter.
Status/ID Value Therefore, when the processor handles the interrupt and receives the status/ID, it jumps directly to the beginning of the interrupt service routine and executes the interrupt service routine code. The system integrator installs the interrupt service routine at the memory location that the jump table specifies. In VXI systems (and all National Instruments VXI/VME Controllers), the status/ID is no longer a vector. It is de-coupled from the processor operation. After the interrupt handler receives the status/ID, controller software invokes the appropriate service subroutine and passes the status/ID value to the subroutine. The general format of the status/ID for a Register-Based VXI device is shown in the following table.
Table II. General Status/ID Format for VXI Bus Devices
For Message-Based VXI devices, there is a further definition of the status/ID format. The status/ID can take on either a Response format or an Event format. Under the Event Format, bit 15 of the status/ID must be set. The values of status/ID bits 8 through 14 define the Event condition. The VXI bus specification currently defines these bits for three specific events. It also defines a syntax for defining your own events. The events defined in the VXI bus specification and their corresponding values for status/ID bits 8 through 15 are listed below. No Cause Given (0xFF) - This event is sent by a Register-Based device that has only one reason to signal its Commander. Usually, this event is issued when an operation completes. Request True (0xFD) — This event is sent by a device when the device requires service. Request False (0xFC) — This event is sent by the device when the device no longer requires service. The VXI bus specification also defines a syntax for sending user-defined events. This format specifies that bit 15 must be 1 and bit 14 must be 0. Bits 8 – 13 can then be used to specify a user-defined event, as shown in the following table.
Table III. Message-Based Device Status/ID—User-Defined Event Format
Except for defining the lower 8 bits of the status/ID value to be the logical address of the interrupter, the VXI bus specification defines only a few specific values of the status/ID. Usually, when you are working with a device capable of producing interrupts, you need to refer to the documentation accompanying the device to see what meaning, if any, the other bits of the status/ID have. Often, you control the conditions under which the interrupt is generated, and the actual status/ID is not important because you will know in advance why the device is sending interrupts.
Signals
The signaling device uses the Data Transfer Bus to write a 16-bit value to the signal register, which is located at offset 8 in the configuration registers for the device being signaled. The 16-bit value has exactly the same format as the 16-bit status/ID. The procedure for handling a signal through software is the same as for an interrupt. The processes discussed above for signals and the interrupt cycle happen completely on the hardware level. These processes are transparent to a user’s application. When a controller senses an interrupt or sees that its signal register has been written to, the controller generates a local processor interrupt that lets the software driver know the event has occurred. |
