Experimental Physics and Industrial Control System
|
Eric Bjorklund wrote:
Umm... I may be completely missing the boat here, but didn't the
VME-MXI-1 problem mostly involve bad data returned because of "address
rot" during the READ cycles? (c.f. Eric Norum's clarification post from
14 Nov. 2003).
We've seen a similar problem with one of our boards here at LANSCE. In
our case, the "pipelined" address was not generated by the executing
code. I don't think it was from a PPC or PCI bus "pre-fetch" either, as
there was no read cycle generated for the new address. So unless there
is some real cleverness going on between the Universe and the PCI
controllers, it looks like the Universe chip is just trying to
anticipate the next address I am going to want and putting out on the
bus early (the new address was the logical successor to the addresses I
had previously requested). I am not aware of any cure for this --
except that in our case it is our own board, so we can fix the problem
at that level.
Yes, the problem is *not* related to posted writes nor back-to-back VME
cycles. We see the problem even with a single VME read cycle -- the processor
changes the address lines as soon as the processer detects that DTACK* has
been asserted. The non-compliant VME/MXI-1 modules do not latch the address
and so scramble the data they're putting on to the bus.
The workaround we're using is to program the Universe II chip to latch the
data as soon as it sees DTACK* asserted rather than waiting the short period
(T27) required by the VME specification. This violation of the VME timing
requirements is acceptable as long as all modules in the crate are
conservative in how they put data on the bus (data first, then assert DTACK*).
So far this 'fix' has worked for us.
--
Eric Norum [email protected]
Advanced Photon Source Phone: (630) 252-4793
Argonne National Laboratory
- References:
- mvme5500 (was National Instruments VME-MXI-1 modules vs. modern VME CPU modules) Kate Feng
- Re: mvme5500 (was National Instruments VME-MXI-1 modules vs. modern VME CPU modules) Andrew Johnson
- Re: mvme5500 (was National Instruments VME-MXI-1 modules vs. modernVME CPU modules) Kate Feng
- Re: mvme5500 (was National Instruments VME-MXI-1 modules vs. modernVME CPU modules) Andrew Johnson
- Re: mvme5500 (was National Instruments VME-MXI-1 modules vs. modernVMECPU modules) Kate Feng
- Re: mvme5500 (was National Instruments VME-MXI-1 modules vs. modernVMECPU modules) Andrew Johnson
- Re: mvme5500 (was National Instruments VME-MXI-1 modules vs. modernVMECPUmodules) Kate Feng
- Re: mvme5500 (was National Instruments VME-MXI-1 modules vs. modernVMECPUmodules) Kate Feng
- Re: mvme5500 (was National Instruments VME-MXI-1 modules vs. modernVMECPUmodules) Eric Bjorklund
- Navigate by Date:
- Prev:
RE: Buffer problems Mark Rivers
- Next:
Re: Buffer problems Graham Waters
- 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:
Re: mvme5500 (was National Instruments VME-MXI-1 modules vs. modernVMECPUmodules) Eric Bjorklund
- Next:
et_wish mon problem Lei Ge
- 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
|
ANJ, 10 Aug 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|