Re: VME Bus Error handling on MVME3100 and 6100 boards

[Andrew Johnson <anj@aps.anl.gov>]

Kate Feng wrote:
> Discovery deos not have the necessary capability or connections to the 
> MCP. I was told that
> on the boards which use a Discovery system controller, the MCP signal is 
> connected to a
> pull-up and therefore not used as it is on other boards.  That's the 
> design on the
> MVME5500 and MVME6100 boards.   I do not see it as a big problem for the
> MVME5500 board because ......
>
> Till  Straumann wrote :
>
> > (currently, a PCI error such as target abort is routed to the one
> > and only EE interrupt of the powerpc).
>
> The MCP, if available, is routed to the EE interrupt as well.

I personally would see it as a problem, because the EE interrupt is 
maskable.  It's not trivial to write an exception handler that can nest 
properly such that if an interrupt service routine receives a Target- 
Abort from a PCI device it will immediately halt and abort the ISR 
rather than continuing on to completion and only then running the 
Target-Abort interrupt handler.  If all you have is an interrupt, your 
ISRs probably ought to check with the Tempe chip that they're not 
getting VME bus errors before relying on the data they've just read (at 
least if the value they read back was all-1s).

> For the MVME6100, I am more concerned with the
> "making use of the dud all-1's read data in the process"
> that Andrew mentioned earlier.  I do'nt seem to get the answer from the
> http://www.aps.anl.gov/epics/tech-talk/2006/msg00892.php, which was 
> posted by Till.
> Is it in the "vmeTsi148ClearVMEBusErrors(&erraddr);" ?  How is it 
> programmed?

I'm not sure I understand your question.  The "all-1s read data" I was 
talking about is the data that is returned if you do a programmed read 
cycle to the VMEbus that ends in a Bus Error.  If the Bus Error occurs 
during a DMA operation using one of the DMA controllers in the Tempe 
chip then the DMA will be stopped immediately instead, since the 
controller is inside the Tempe and can see the Bus Error status.

> We have one application that could be optimied by the PCI  bandwidth
> that MVME61000 offers ( 800 MHZ).
> Also, I am still not sure about the  "MBLT" transfer of
> the VME backplane, whih was posted at
> http://www.aps.anl.gov/epics/tech-talk/2006/msg00888.php.
> I assumed it was limited by the capability of the DMA controller
> instead of the bus speed because I assume a simple test could be done
> easily by using two MVME6100s on a VME320 crate.  Perhaps
> Till can verify this ??

The Tempe's DMA controllers are most likely to be limited by the speed 
of the VMEbus when doing MBLT cycles; the maximum data transfer rate you 
can get using MBLT is 80MB/s according to the VITA FAQ at 
http://www.vita.com/vmefaq.html#anchor419155 whereas the PCI/X bus on 
the MVME6100 can run faster than that.  If you have a VME320 backplane 
and both boards are capable of 2eSST then your bottleneck might not be 
the VMEbus, but I don't know the answer to that question.

> Andrew Johnson wrote:
>  > Anyone interested in MicroTCA to replace the now aging VMEbus?
>
> Why do you think VMEbus is aging ?  I was researching the VXS bus for
> a short while and comapred it with  the MVME6100 solution for our
> application.  VMEbus does not seem to be aging for me.

The VMEbus was first announced in 1981 - that's 25 years ago, which is 
what makes it aging as far as basic technology goes.  I'm not saying its 
not still capable of doing the job, but the basic assumptions that the 
bus was designed around are starting to be seriously invalidated and for 
new facilities such as the ILC I would carefully examine alternative 
busses such as MicroTCA.

- Andrew
--
There is considerable overlap between the intelligence
of the smartest bears and the dumbest tourists.
  -- Yosemite National Park Ranger