data transfer to or from the GPIB is performed via two 255 Byte
wide FIFO registers/buffers. These FIFOs are used to decouple GPIB
data traffic from the CPU bus. Using the iGPIB as an IEEE 488.2
device, the FIFOs may be used as the input or output queue what
simplifies the software design significantly. In addition,
provisions were made to support the IEEE 488.2 Trigger Control and
to support the MAV (Message Available) Reset directly in the
The last feature is unique by ines. The FIFOs may be
accessed respectively with simple "read" and
"write" operations (to the DIR or CDOR). Using this
technique combined with repetitive move instructions (i.e. REP
INSB of the 80386 CPU) allows to use the full band width without
iGPIB independently controls and monitors each bus line as well as
the transceiver control signals. This feature exceeds the IEEE
488.2 requirements (monitoring NRFD and NDAC).
iGPIB provides a timeout interrupt condition. If the condition is
unmasked, a timer counts down for a programmable interval. Any
time a data transmission takes place, the timer will be reset to
its original (programmed) value. If the handshake gets stuck, the
timer underflows and an interrupt occurs. The timeout is from 1 ms
up to 65 s in steps of 1 ms. Normally the timeout functionality
had to be provided by the interface driver software, which is not
necessary anymore now.
iGPIB offers a 16-bit wide transfer counter. This counter reduces
the programming for DMA operations in two ways. First, the counter
delivers an end-of-transfer interrupt, if a programmable amount of
data has been sent or received, respectively. The driver software
can initiate a DMA transfer and then switch to another task until
the interrupt occurs. Second, a Last Byte Handling feature allows
to automatically send the last byte with EOI true. This means, on
send transfers (talker), it indicates the end of a data block. On
receive transfers, it is possible to automatically signal NRFD
active after the last byte has been received (listener). With
previous GPIB controllers, like the NEC 7210C, all these
operations had to be programmed explicitly via software.
order to integrate the preferred IEEE 488.2 implementation of
requesting service, the iGPIB realizes the Service-Request-Enable
register on chip. This allows to update the status byte via the
status byte register independent of requesting service. Together
with two transition filters for each status bit, the iGPIB handles
the service request generation autonomously without any software
intervention. Further, the MAV bit of the IEEE 488.2 status byte
can be reset automatically, if a message (data block) has been
sent. This solves the problem of differing speeds between device
and controller, which has not been specified sufficiently in the
IEEE 488.2 standard.
IEEE 488.2 standard explicitly recommends more than one
stop-handshake condition for an IEEE 488.2 Controller. Previous
Controllers allow only to use EOI and one EOS byte. The iGPIB
instead allows to use EOI and up to three EOS bytes. The iGPIB
entirely meets the IEEE 488.2 standard recommendations in
hardware, at the same time reducing the software overhead. In
addition, the Controller allows to ignore EOI as a stop-handshake
condition. This simplifies the handling of pre-488.2 devices and
devices not entirely operating according to the standard.
iGPIB FIFOs may be accessed via the synchronous DMA interface (XDMA).
This interface enables FIFO access without using the CPU data bus.
XDMA can transfer data at a speed of up to 30 MByte/s. This
interface may be used for various purposes. High speed / high
perfomance instruments, for example, may transfer data directly to
the GPIB FIFO without any CPU intervention. Computers acting as
GPIB controllers can perform DMA cycles utilizing the full band
width of their busses, i.e. even with 64-bit architectures, up to
128 bit busses.