Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 10 Aug 2006 12:24:06 -0500

A major warning for anyone who is considering buying these recent
Motorola VME boards; I just discovered the following information in the
User Manual for the "Tempe" Tsi148 PCI/X-to-VME Bus Bridge chip that
they both use:
2.3.5 VMEbus Exception Handling
When a VMEbus transfer initiated by the VME Master does not complete
successfully, the status is saved in the VMEbus exception registers.
The exception registers are updated when a transaction is terminated
with a bus error, or a 2eVME or 2eSST transfer is terminated with a
slave termination.

...
When the VME Master encounters one of these conditions, any write
data in the buffers is removed (flushed). If the transaction was a
VMEbus read, the VME Master completes the Linkage Module command by
filling the buffer with a data pattern of all ones.

...
Tip: The interrupt controller can be programmed to generate an
interrupt when the exception registers are updated.

Elsewhere, it also says
The Tsi148 PCI Target never terminates a transaction with a
Target-abort

and
SIGTA (Signalled Target Abort): The Tsi148 does not generate a target
abort, therefore this bit is hard-wired to a logic 0.

For those of you who do not know much about the PCI bus, a Target Abort
is the PCI equivalent of a VME Bus Error - it terminates the current
read or write operation with an error condition and can be made to cause
the processor to take a Machine Check Exception. VxWorks responds to
this exception by suspending the currently executing task.
The Universe-2 PCI-to-VME Bridge chip that is used on the MVME2100,
2700, 5100 and 5500 boards is able to generate a Target Abort when a
VMEbus read cycle terminates with a Bus Error. Although the BSPs
shipped by Wind River for these boards does not actually make use of
this capability, it is possible to modify them to get the Universe-2 to
generate a Target Abort and hence a Machine Check Exception whenever a
bus error occurs, thus trapping any VME bus errors at the moment they
occur (for read cycles at least) and suspending the relevent task at the
point where the bus error occurred. I have published BSP patches to do
this for all of the boards we use here at the APS, and I believe that
many sites are using these modifications.
This behaviour is not possible with the Tempe chip - VME read cycles
that terminate with a Bus Error just return 0xFFFF values (all one
bits), and by default there is no indication that anything unusual
happened. It is possible to enable the VME Exception interrupt, which
will eventually be serviced by the processor and most of the time would
allow the BSP to suspend the correct task (assuming that the Bus Error
wasn't caused by an Interrupt Service Routine), but that interrupt could
be delayed for quite a long time by other pending interrupts.
The only sure-fire way around this problem is to check the Tempe chip's
VMEbus Exception Attributes Register after every write operation and
every read that returns an all-1s bit pattern - clearly not something
conducive to good I/O performance, and not compatible with any existing
EPICS drivers.
As a result of the above, I would recommend that EPICS users avoid any
VME CPU board that uses the Tundra Tsi148 (Tempe) chip, and explain to
your Motorola sales representative why you are doing so.
- Andrew
--
Not everything that can be counted counts,
and not everything that counts can be counted.
  -- Albert Einstein

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System