EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: VME Bus Error handling on MVME3100 and 6100 boards
From: Kate Feng <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: EPICS tech-talk <[email protected]>
Date: Thu, 10 Aug 2006 13:59:50 -0400
Very interesting information.  Thanks a lot.  I was told
that on the mvme6100, "MBLT performance is similar to
what the universe's".  However, I do not really have any
experience on the mvme6100 yet.  Thus, the above statement
could be wrong.  I would appreciate if any experienced
expert on the mvme6100 can verify this statement.

Thanks,
Kate

Andrew Johnson wrote:

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




Replies:
Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
References:
VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson

Navigate by Date:
Prev: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Next: Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Next: Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·