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 ?
> - 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.
Anyway, the overhead applies only to VME bus read/write operations
on the mvme61000, but not the PMC devices.
(There were some interesting discussions offlist that I feel that I own
explainations about my previous E-mail)
For applications that can manage to keep the fast data transfers
on the PCI buses, will not suffer the overhead.
One example is demonstrated in the 2nd half of my presentation
for the LCLS XAMPS detector at
http://www.aps.anl.gov/epics/meetings/2006-06/RTEMS_Primer_SIG/LCLS_XAMPS_FW.pdf.
The diagram in Page 9 shows that the fast data comes in via an FPGA PMC1
and goes out via a Fibre Channel PMC2 so that the data could be stored
in the FC storage connected to the Linux workstation via a PCI express
based FC card.
Its performance could be multiplied by the number of the MVME6100s for
faster detectors. The only backplane communication could be only the
management of the multiprocessors and even DMA whose operation will stop
on bus error. The detector is custom made so that the synchronization
can be achieved externally via the path of the FPGA.
If the data from the detector needs to be integrated within a
complicated real time application which demands the VXS crate and
PCI express, then the design might be different, of course.
Also, not all Single Board Computers for the VXS crate use the
Discovery controller.
> You do not need a VME320 backplane to run 2eSST, a normal
> VME64x backplane will do (but a VME32 backplane of course not.)
If there are three rows at the back of mvme6100 instead of
five rows, it should work on the VME32.
Lastly, just a reminder, the cost effective mvme5500 does not
require the overhead mentioned above.
It is all about applications and costs.
Kate
- Replies:
- Re: VME Bus Error handling on MVME3100 and MVME6100 boards Andrew Johnson
- Navigate by Date:
- Prev:
Ethereal => Wireshark Andrew Johnson
- Next:
Re: VME Bus Error handling on MVME3100 and MVME6100 boards Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Ethereal => Wireshark Andrew Johnson
- Next:
Re: VME Bus Error handling on MVME3100 and MVME6100 boards Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|