Universe VME notes (was Re: BSP for Motorola MVME5500)
strauman at slac.stanford.edu
Thu Apr 15 18:18:52 UTC 2004
Feng, Shuchen wrote:
> Hi Bill,
> I am near the completion for writting the BSP for the MVME5500.
> It successfully auto booted large (e.g. C++ based EPICS) VME based
> applications via the 10/100M ethernet. My TODO list before the
> release of the souce codes are :
> 1. 1GHZ ethernet.
> 2. rtems-4.6.0 (right now it works on rtems-4.6.0pre3)
> 3. build the Cexp (written by Till Straumann) to give the BSP
> a VxWorks-like environment (e.g. dynamic loading)
> 4. VME device write probe (the read probe is done) to
> detect the absent VME devices.
Write probing has not been implemented (in libbspExt) for good reasons:
1) Write cycles might be asynchronous - the universe chip
supports 'posted writes'. Hence, you might get an interrupt
flagging a bus error long after your 'probe' routine has returned.
AFAIK, the universe doesn't provide a synchronization mechanism
to enforce flushing the fifos.
You would have to either disable posted writes (incurring
a significant performance penalty) altogether or set up
secondary VME windows with PWEN cleared. This would be more
elegant but doesn't fit the EPICS devLib API.
As a sidenote: posted writes also are problematic when talking
to device registers (e.g. when clearing interrupt status bits):
1) device asserts IRQ level
2) universe acknowledges interrupt and retrieves vector
3) user ISR is dispatched.
4) user ISR clears the device's interupt status bit
*** HOWEVER ***, the new value is only posted to the FIFO
5) user ISR terminates.
6) IRQ level is re-enabled by the universe driver
===> if the TXFIFO has not been flushed yet, the IRQ
level is still asserted!
2) Some hardware (such as the MPC106 hostbride on my SVGM board)
doesn't even bother to support raising machine check exceptions
on failing VME writes.
It is recommended to exclusively use 'read probes' for device detection.
More information about the users