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 2025 | 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 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: mvme5500 (was National Instruments VME-MXI-1 modules vs. modernVMECPUmodules) |
From: | Eric Norum <[email protected]> |
To: | Eric Bjorklund <[email protected]> |
Cc: | EPICS tech-talk <[email protected]> |
Date: | Fri, 26 Mar 2004 15:01:42 -0600 |
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).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.
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.
-- Eric Norum [email protected] Advanced Photon Source Phone: (630) 252-4793 Argonne National Laboratory