Re: VxWorks 6.9

[Stefen Paul <stefen4114@gmail.com>]

Hi,

Thanks Andrew for a comprehensive reply.

I have one more query regarding VxWorks 6.9 on MVME5500.

How can one access CR/CSR portion of a peripheral board from either the vxWorks prompt or a simple C program ?

Regards,

Stefen.

On Sat, Jan 16, 2016 at 12:25 AM, Andrew Johnson <anj@aps.anl.gov> wrote:

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