Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 24 Aug 2006 11:11:37 -0500

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System