Re: VME Bus Error handling on MVME3100 and 6100 boards

[Kate Feng <feng1@bnl.gov>]

Very interesting information.  Thanks a lot.  I was told
that on the mvme6100, "MBLT performance is similar to
what the universe's".  However, I do not really have any
experience on the mvme6100 yet.  Thus, the above statement
could be wrong.  I would appreciate if any experienced
expert on the mvme6100 can verify this statement.

Thanks,
Kate

Andrew Johnson wrote:

> A major warning for anyone who is considering buying these recent 
> Motorola VME boards; I just discovered the following information in 
> the User Manual for the "Tempe" Tsi148 PCI/X-to-VME Bus Bridge chip 
> that they both use:
>
> > 2.3.5 VMEbus Exception Handling
> >
> > When a VMEbus transfer initiated by the VME Master does not complete 
> > successfully, the status is saved in the VMEbus exception registers. 
> > The exception registers are updated when a transaction is terminated 
> > with a bus error, or a 2eVME or 2eSST transfer is terminated with a 
> > slave termination.
>
>
> ...
>
> > When the VME Master encounters one of these conditions, any write 
> > data in the buffers is removed (flushed). If the transaction was a 
> > VMEbus read, the VME Master completes the Linkage Module command by 
> > filling the buffer with a data pattern of all ones.
>
>
> ...
>
> > Tip: The interrupt controller can be programmed to generate an 
> > interrupt when the exception registers are updated.
>
>
> Elsewhere, it also says
>
> > The Tsi148 PCI Target never terminates a transaction with a
> > Target-abort
>
>
> and
>
> > SIGTA (Signalled Target Abort): The Tsi148 does not generate a target
> > abort, therefore this bit is hard-wired to a logic 0.
>
>
> For those of you who do not know much about the PCI bus, a Target 
> Abort is the PCI equivalent of a VME Bus Error - it terminates the 
> current read or write operation with an error condition and can be 
> made to cause the processor to take a Machine Check Exception.  
> VxWorks responds to this exception by suspending the currently 
> executing task.
>
> The Universe-2 PCI-to-VME Bridge chip that is used on the MVME2100, 
> 2700, 5100 and 5500 boards is able to generate a Target Abort when a 
> VMEbus read cycle terminates with a Bus Error.  Although the BSPs 
> shipped by Wind River for these boards does not actually make use of 
> this capability, it is possible to modify them to get the Universe-2 
> to generate a Target Abort and hence a Machine Check Exception 
> whenever a bus error occurs, thus trapping any VME bus errors at the 
> moment they occur (for read cycles at least) and suspending the 
> relevent task at the point where the bus error occurred.  I have 
> published BSP patches to do this for all of the boards we use here at 
> the APS, and I believe that many sites are using these modifications.
>
> This behaviour is not possible with the Tempe chip - VME read cycles 
> that terminate with a Bus Error just return 0xFFFF values (all one 
> bits), and by default there is no indication that anything unusual 
> happened.  It is possible to enable the VME Exception interrupt, which 
> will eventually be serviced by the processor and most of the time 
> would allow the BSP to suspend the correct task (assuming that the Bus 
> Error wasn't caused by an Interrupt Service Routine), but that 
> interrupt could be delayed for quite a long time by other pending 
> interrupts.
>
> The only sure-fire way around this problem is to check the Tempe 
> chip's VMEbus Exception Attributes Register after every write 
> operation and every read that returns an all-1s bit pattern - clearly 
> not something conducive to good I/O performance, and not compatible 
> with any existing EPICS drivers.
>
> As a result of the above, I would recommend that EPICS users avoid any 
> VME CPU board that uses the Tundra Tsi148 (Tempe) chip, and explain to 
> your Motorola sales representative why you are doing so.
>
> - Andrew