Hi Stefen,
On 01/14/2016 11:59 PM, Stefen Paul wrote:
> As most of you must be aware that a VME bus-error is a condition when
> there is no/unresponsive peripheral board preset at the address that is
> put on the bus by CPU for a read/write cycle.
>
> While using and reading about MVME5500 (with vxworks 6.9), I have
> realized that it is not possible to precisely catch a VME bus-error in
> software while doing a write operation on a peripheral board. This ,as I
> learnt, is due to the PCI bus based architecture of the board which uses
> write-posting.
>
> However, one can catch a VME bus-error during a read cycle as reading is
> done immediately from the peripheral board.
>
> Is this scenario same for all other CPU boards also (whether PowerPC or
> Intel based ) that have PCI bus based architecture.
If write-posting is turned on then no CPU can precisely catch a VME
bus-error on a write cycle in a way that allows the cycle to be retried,
because the CPU will have moved on and executed further instructions
before the bus error is recognized. The purpose of write-posting is to
allow the CPU to fire-and-forget the VME write cycles which are very
slow compared to the PCI bus and today's fast CPUs. The Universe-2 chip
does have post-mortem registers which can tell the code what was being
addressed, but unless the driver software is written very carefully
there isn't much it can do other than report the problem.
IIRC one difference between the MVME5500 and the older MVME5100,
MVME2700 and MVME2100 boards is that the Discovery-2 chip on the
MVME5500 isn't connected to the Universe-2 chip's target-abort pin at
all, so it can't retry a VMEbus read cycle that failed with a bus error.
The other boards can abort the PCI read cycle with that target-abort,
but the MVME5500 (and the later MVME boards that use the Tempe TSI-148
chip instead of the Universe-2; the Tempe doesn't even have a
target-abort signal) can only terminate the PCI read cycle normally and
issue an interrupt to indicate to the CPU that a bus error occurred.
Since the read cycle completes normally, whatever instruction was doing
the read will finish before the interrupt gets processed, making it much
harder to go back and retry the read cycle.
If you are extremely paranoid (or have a very unreliable system) it may
be possible to do all your VMEbus I/O cycles using the vxMemProbe()
routine, but the result would be horribly slow and inefficient. Some
implementations of the vxMemProbe() helpers may prevent even that; to
flush the write cycle out to the hardware at least one version I've seen
actually does an 8-bit read of the same address after every write cycle,
which could cause obvious issues with some VME slave boards.
- Andrew
--
There are only two hard problems in distributed systems:
2. Exactly-once delivery
1. Guaranteed order of messages
2. Exactly-once delivery
-- Mathias Verraes
- Replies:
- Re: VxWorks 6.9 Stefen Paul
- References:
- VxWorks 6.9 Stefen Paul
- Re: VxWorks 6.9 Andrew Johnson
- Re: VxWorks 6.9 Stefen Paul
- Re: VxWorks 6.9 Stefen Paul
- Navigate by Date:
- Prev:
Keithley 7001 Scanner Support Jiro Fujita
- Next:
Re: Re: Dynamically refresh CSS BOY runtime OPI Zhang Yuliang
- 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: VxWorks 6.9 Stefen Paul
- Next:
Re: VxWorks 6.9 Stefen Paul
- 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
|