Experimental Physics and Industrial Control System
"J. Frederick Bartlett ([email protected])" wrote:
>
> When I consulted our local vxWorks expert, Dave Berg, here at
> Fermilab, he suggested that it might be the result of the
> execution-time optimization that occurs in the 604 processor chip --
> the MVME2301 has the 603 processor chip. I note that the MVME2700
> series uses the 750 processor chip and I do not know whether it also
> uses execution-time optimization.
I believe it does, but can find no documentation describing particular
situations where it does reorder accesses. When I first read about this I
became concerned about it changing the order in which the CPU reads and
writes to I/O registers, which could obviously be a Very Bad Thing {TM}.
As a result I went through the sysPhysMemDesc[] table in our PowerPC BSPs
and set the GUARD bits in all of the I/O page entries, although I have
never seen any obvious change in behaviour as a result (it may be that the
cache-inhibit was also protecting these pages). A page with the GUARD bit
set is protected from reordering, and it is also possible to set a bit in
one of the CPUs status registers to disable reordering, although I'm not
sure what other effects this may have.
PowerPC BSPs usually have EIEIO (yes, that's a real PowerPC instruction
mnemonic!) and/or EIEIO_SYNC instructions scattered about the code which
are there to ensure that all side-effects of previous instructions have
been completed before the following code is run. However even these are
not sufficient to ensure that writes to the VMEbus will have been
completed because there are FIFO buffers in the Universe chip (used when
you have Write Posting enabled) and I think even the PCI host bridge has
the ability to do some reordering.
The technique Fritz mentioned of reading back from a register after
writing to it is I believe the only one that is guaranteed to flush all
writes before it completes (but to ensure that the compiler doesn't
optimize away the read operation your registers do need to be marked as
volatile). Note that this is also needed on mv167 boards if you enable
Write Posting on the relevent VME Master window of the VMEchip2.
About the only time this ever matters though is in an ISR for VME hardware
that implements the RoRA (Release on Register Access) interrupt behaviour,
and even then if the access is just a read or is followed by a read of
some other register the IRQ line probably should still be cleared in time.
However I'm not convinced that this is the problem that is causing all the
"Bad VME interrupt 0" messages - I experimented with adding some code to
the end of the BSP interrupt dispatch routine that flushed everything and
waited for the Universe write buffers to empty before returning, but the
problem still did not go away. I therefore suspect that there is a VME
timing problem with the VIPC616 board that only affects Universe devices,
but I've not had time to plug our VMEbus analyzer in to check it.
- Andrew
--
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away.
- Antoine de Saint-Exupery
- Navigate by Date:
- Prev:
How to get EPICS ? Gina (Seed)
- Next:
mbbiRecord undefined state Bernd Schoeneburg
- 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:
How to get EPICS ? Gina (Seed)
- Next:
mbbiRecord undefined state Bernd Schoeneburg
- 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