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 MVME6100 boards
From: Andrew Johnson <[email protected]>
To: Kate Feng <[email protected]>
Cc: [email protected]
Date: Mon, 28 Aug 2006 09:18:25 -0500
Kate Feng wrote:
Andrew Johnson wrote about mvme6100:

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

This can be implemented at the level of the Tsi148 driver instead of the EPICS driver, right ?

All the EPICS VME drivers that I know assume that they have memory mapped I/O to the VME card and thus do not make an OS or BSP call to perform read or write cycles on the VME bus. If they *did* call an OS or BSP routine then it would be possible for a Tsi148 driver to intercept all such I/O operations and perform the necessary checks afterwards. However since they don't (most EPICS drivers create a struct that directly maps to the board registers and use a pointer to that struct to calculate the register address) the above requirement would need major changes to every driver to properly handle the issue of getting a bus error.


This doesn't mean that the existing drivers won't work; the vast majority of the time they will be fine. They will not be robust in the presence of unexpected bus errors though.

- clearly not something conducive to good I/O
performance, and not compatible with any existing EPICS drivers.

At least, only the VME devices implemented with the 2eSST protocols are eight times faster than the regular one, which somehow compensate the overhead. The only possible performance gain over the Universe on the VME backplane lies at the MBLT via the DMAs of the tempo chip using the 2eSST protocols, which will be confirmed by Timo.

2eSST is not relevent to the programmed I/O operations I was talking about above. The issue of bus errors occurring during a DMA transfer are dealt with using a different mechanism which should be fine on the Tempe chip.


- Andrew
--
There is considerable overlap between the intelligence
of the smartest bears and the dumbest tourists.
  -- Yosemite National Park Ranger

Replies:
Re: VME Bus Error handling on MVME3100 and MVME6100 boards Kate Feng
RE: VME Bus Error handling on MVME3100 and MVME6100 boards Thompson, David H.
References:
Re: VME Bus Error handling on MVME3100 and MVME6100 boards Kate Feng

Navigate by Date:
Prev: Re: VME Bus Error handling on MVME3100 and MVME6100 boards Kate Feng
Next: writes from windows Geoff Savage
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: Re: VME Bus Error handling on MVME3100 and MVME6100 boards Kate Feng
Next: Re: VME Bus Error handling on MVME3100 and MVME6100 boards Kate Feng
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 ·