Archived: Understanding the VXI/VME Interrupt and Signal Acknowledge Cycle

NI does not actively maintain this document.

This content provides support for older products and technology, so you may notice outdated links or obsolete information about operating systems or other relevant products.


This document addresses interrupts on both VME and VXI systems.



The 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. 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). Table 1 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 1. Priority Interrupt Bus Signals

Signal Function
IRQ1*-IRQ7* An interrupter uses this signal to indicate that it is requesting service.
IACK* An interrupt handler uses this signal to indicate that it has received
an interrupt and is ready to receive a status/ID that will tell the handler
how to proceed with servicing the interrupt.
A module receives the IACK* on IACKIN*. It places a status/ID on the bus
if the interrupt level being serviced matches the module’s interrupt level
and if the device is interrupting. Otherwise, the module passes the signal
on using IACKOUT*.
[A01-A03] The interrupt handler asserts these lines with the value corresponding to
the interrupt level being serviced.
[D00-D31] The interrupter being serviced places the status/ID on these lines once
IACK* has been received.
DTACK* The interrupter uses this signal to indicate that its status/ID is asserted
on the data lines.

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:

  • A single handler system
  • A distributed system

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:

  • Release On ACKnowledge (ROAK)
  • Release On Register Access (RORA)

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

After a device asserts an interrupt, it waits for a response from the interrupt handler. In Figure 1, each interrupter asserts an interrupt on the bus. Since Interrupter 3 asserts IRQ 7, it will have the highest priority on the bus as seen before.

Figure 1.Interrupters assert different IRQ's

When the interrupt handler detects that an interrupt line has been asserted, the interrupt handler asserts the IACK* (interrupt acknowledge) signal. It also sets the lower three address lines A01-A03, with the IRQ Number in binary (111 for 7), to indicate which interrupt line it is trying to acknowledge with the IACK* signal.
The IACK* line that the handler drives is connected to the IACKIN* pin of slot 0 in the chassis (Slot 1 in VME bus systems). If the module in the first slot is not asserting the interrupt line being acknowledged, the module must propagate the IACK* signal to its IACKOUT* pin, which is connected to the next slot’s IACKIN* pin. The propagation of the IACK* signal from slot to slot continues until the IACK* signal reaches the first module that is interrupting on the line being acknowledged. In Figure 2, Interrupter 3 does not propagate the IACK Signal, since it inserted the interrupt with the highest priority.

Figure 2. Propagation of IACK* signal and assertion of [A01-A03] lines

When the interrupter sees IACK*, it places its status/ID on the data/bus. In Figure 3, Interrupter 3 places the status/ID in the D00-D31 lines and asserts the DTACK* line to indicate that the status/ID has been written to the D00-D31 lines.

Figure 3. Interrupter asserts DTACK* and status/ID in the [D00-D31] lines

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.

Note: RORA devices require you to read/write a device specific register in order to complete the interrupt acknowledge cycle.

Status/ID Value

The status/ID in most VME systems is an 8-bit value. In VXI systems, the status/ID is either a 16-bit or 32-bit status/ID value. Message-Based devices that have interrupter capability must return at least a 16-bit status/ID with an optional 32-bit value. Currently, 32-bit status/IDs are uncommon. In VME systems, the status/ID is usually a vector. The processor uses this vector to calculate an address to a position in an interrupt jump table. The entry in that table is the address of the start of the interrupt service routine.

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 Table 2.

Table 2. General Status/ID Format for VXI Bus Devices

Bits 31-16 15-8 7-0
Contents Device-Dependent Cause/Status(Device-Dependent) Logical Address of Interrupter

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 through 13 can then be used to specify a user-defined event, as shown in Table 3.

Table 3. Message-Based Device Status/ID-User-Defined Event Format

Bits 31-16 15 14 13-8 7-0
Contents Device-Dependent 1 0 User-Defined Event Logical Address of Interrupter

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

Introduction to Programming with VISA Events

An event being a software notification of some condition, a device asserting an interrupt line is treated as an event. You can use VISA Programming in LabVIEW or LabWiwindows/CVI to program the event handling.
There is a common code flow for setting up a VISA program to handle events. This general procedure does not depend on the event to be handled. This procedure is outlined in the following discussion.The general structure resembles the following:

  1. Open session to instrument that will cause the event
  2. Enable the event
  3. Wait on the event (Receive the event)
  4. Disable the event
  5. Close the session to the event
  6. Close session to instrument

A simple example showing the necessary event handling operations, in synchronous mode, is presented below in Figures 4 and 5, both in LabVIEW and LabWindwows/CVI

Figure 4. Example of a LabVIEW Event Handler (Using the Queue Mechanism)

In this diagram, a session is opened to a VXI instrument at logical address 1. VXI/VXME interrupt events are enabled, and then the program waits for up to 30 seconds to see if an event is received. If an event is received, a pop-up dialogue is displayed and the event session is closed. Events are then disabled and the session to the instrument is closed.

Figure 5. Example of a LabWindows/CVI Event Handling Program

In this program, a session is opened to a VXI instrument at logical address 1. VXI/VXME interrupt events are enabled with the synchronous queue mechanism, and then the program waits up to 30 seconds to see if an event is received. Because the event handle parameter is set to VI_NULL for VISA Wait on Event, the event handle is closed automatically if an event is received. The program checks the status return on the VISA Wait on Event operation to see if it timed out. If a timeout occurred, no event was received.Events are then disabled and the sessions to the instrument and resource manager are closed to end the program.

Related Links:
How to Assert Interrupts on the VXI/VME Backplane using VISA 2.5 or Greater and LabWindows/CVI
VISA Interactive Control (VISAIC)
Using LabVIEW to assert interrupts on a VXI/VME system using VISA 2.5 or greater

Was this information helpful?