EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: compact PCI versus VME
From: "Jeff Hill" <[email protected]>
To: "'Lawrence T. Hoff'" <[email protected]>, "'Dalesio, Leo'" <[email protected]>
Cc: Eric Bjorklund <[email protected]>, [email protected]
Date: Tue, 26 Jan 2010 09:04:38 -0700
Title: RE: compact PCI versus VME

FWIW:

 

At LANSCE we are looking at NI’s cRIO for slow controls – this eliminates the two parallel universes problem when interfacing EPICS to ladder logic based PLCs. That of course makes sense only when you need a slow controls IOC, and you don’t need the traditional safety role of a PLC (the cRIO’s FPGA might even be used for equipment protection if proper change tracking verification procedures are in place). The cRIO _is_ proprietary, but also very flexible in terms of hard synchronization and parallel processing because of the programmable FPGA on the backplane. At KEK they have the EPICS IOC embedded in the Yokagowa  PLC. It’s a similar idea, w/o the flexibility of the FPGA on the backplane, but with the wiring benefits and longevity of PLC hardware. The cRIO is also being looked at here for BPMs and Wire Scanners. It’s unfortunate, from my perspective, that there isn’t an open standard equivalent of cRIO (correct me if I am wrong on that conclusion).

 

For LANSCE LLRF they need the real-estate provided by 6u boards, and for DAQ the bandwidth between the FPGA and the analog modules isn’t appearing to be sufficient in cRIO. So for those systems we need either cPCI, VME, or uTCA. If we have a centralized CPU then the bandwidth in cPCI Express, VME/VXS, or uTCA for DAQ interconnects looks attractive. Another option which we are looking at is to just run EPICS embedded on every one of the (Ethernet directly connected) DAQ/LLRF modules thereby eliminating the system interconnect as a bottleneck/complexity between the DAQ/FPGA hardware and switched Ethernet.

 

I suspect that the need for a special ASIC to drive the higher voltages on the VME bus is one reason why VME seems to cost more compared to cPCI which uses lower backplane voltages. Another reason is of course economics of scale with PC commodity chips. That particular price advantage could vanish as PCs move off to wherever PCs move off to, but cPCI Express appears to track that at least for awhile. The VME/VXS functional equivalents does not appear to be quite as far along at this time compared to cPCI Express. I am not seeing high signal density digitizer modules that conform to the new VME switched serial standards. I am also unaware of any VME digitizers with an embedded general purpose Ethernet connected processor on which we can directly embed EPICS (that option does exist in cPCI). I am very interested in any suggestions you might have BTW.

 

Jeff


______________________________________________________
Jeffrey O. Hill           Email       
[email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

 

Message content: TSPA

 

From: Lawrence T. Hoff [mailto:[email protected]]
Sent: Tuesday, January 26, 2010 6:09 AM
To: 'Dalesio, Leo'; 'Jeff Hill'
Subject: RE: compact PCI versus VME

 

 

I see an interesting theme in this discussion - although I

am sensitized by "internal" (RHIC) discussions we had last week....

 

      My thoughts this morning (for what they are worth):

 

These days, accelerator controls seems to include two somewhat

distinct disciplines:

 

      1) "slow controls" - digital I/O, PLC-based logic, analog I/O

at the ~10Hz or slower level, vacuum, cryo, etc.

 

      2) Data acquisition (DAQ) systems - including global orbit correction

at the many KHz level, turn-by-turn (and even bunch-by-bunch) beam

diagnostics, LLRF, etc.

 

      The former benefits from low "per-channel" costs, modularity,

scalability, long lifetime, etc. This has been reasonably served by VME

historically. It is hard to imagine, e.g. that uTCA would be well suited

for such applications. DAQ systems requires high bandwidth, large memory,

powerful  processors (or FPGAs).

 

To date, we (RHIC) have "made do" with VME for *both* roles -

occasionally bumping into VME limitations for the most demanding

applications, but for the most part happy to have a one-size (mostly)

fits all solution.

 

      Recently, we debated investigating non-VME crate solutions (e.g. uTCA) -

Still trying to maintain a one-size-fits all solution. Our concern was whether

we could find a platform with the bandwidth needed for even more demanding

DAQ systems moving forward, but still retain the low per-channel costs

for "slow controls" (hence my interest in Jeff's observation about low-cost

CompactPCI modules).

 

      One thought was to investigate whether (PMC?) daughter-cards could be used

for "slow controls" (to control per-channel costs) - only using the (expensive,

switched serial) backplane for high-bandwidth applications.

 

      Another thought - what Bob seems to be suggesting - is to give up on

the one-size-fits-all solution - instead select platforms optimized for

DAQ applications and other platforms optimized for "slow control" applications.

 

      RHIC is de-facto heading in that direction - continuing to use

VME32 (as well as NI Compact RIO and inexpensive PLCs) for "slow controls",

and relying on a newly developed crate-less solution for DAQ applications -

based on a XILINX FPGA with PPC hard core, and 6 XMC daughter card sites

for modularity.

 

      It isn't obvious to me that CompactPCI is significantly better

(or worse) than VME for "slow controls" - but I am still interested

to hear other's experience. I suspect that Compact PCI bandwidth is

*not* so significantly better than VME that it would satisfy our

demanding DAQ needs moving forward (but I am willing to be corrected).

I strongly suspect that our DAQ needs can only be met by a switch-serial

backplane standard *or* a crate-less solution such as our FPGA-based

system - but again, I'm all ears and ready and willing to be corrected.

 

-- Larry

 

 

 

From: Dalesio, Leo [mailto:[email protected]]
Sent: Tuesday, January 26, 2010 6:57 AM
To: Hoff, Lawrence; Jeff Hill
Subject: RE: compact PCI versus VME

 

Sent to Eric regarding cPCI for timing:
We have very limited use of CompactPCI. We resist as the life time of this bus seems limited. We are using VME for out timing modules. Bumpless reboot would be nice, but not necessary. I do not see us rebooting timing IOCs during operation. Still, it is a nice feature.

When we want a small IOC, the Moxa unit has an arm processor and is configured to integrate serial and Ethernet instruments.

=======================================
Further comment:
cPCI seems a computer bus. As such, I think that VME will be around long after cPCI is no longer available - like. uTCA was considered as a platform. The fabric seems mostly geared toward replacing routers. You receive lots of fast serial interfaces. Perhaps this will grow into the next instrumentation bus. However, the uTCA seems best suited to send data from 1 place to many places for processing - or mostly - redistribution. Since our situation is getting fast data from one place to someplace else for processing, we are developing FPGA based solutions to replace the analog front ends which convert to digital and then communicate to the IOC. This way, we program in the capabilities that we want for manipulating high speed data. We are standardizing on the Digital front end to provide 8 high speed serial lines. It is used as the fast orbit feedback  processor and data collector, the power supply controller, and the bpm. For each of these configurations, 1 GBit port is used to communicate to EPICS. This is a departure from a create based system. Instead of replacing a VME card - we replace a pizza box that uses the same interfaces. The boxes come in at 2K each. Also of interest, we can decode the event stream on each pizza box.

Bob

-----Original Message-----
From: Hoff, Lawrence
Sent: Mon 1/25/2010 6:58 PM
To: 'Jeff Hill'; Dalesio, Leo
Subject: RE: compact PCI versus VME
 

        I have absolutely NO experience with CompactPCI.
RHIC has such a large inventory of VME modules (both
custom and COTS), that we could only consider non-VME
options for specific cases. I.e. a wholesale switch is
out of the question.

        Having said that, we do recognize that VME has
been around a looong time, and we want to know what
our non-VME options are. Therefore, far from providing
any negative opinions, I want to be "all ears". I.e.
I am interested to hear that "many modules and crates
cost about half as much". That could spur us to
invest in some CompactPCI - at least to "kick around
the lab". Can you elaborate on what those modules are?

        I am also interested in switched-serial-only
standards such as uTCA. We occasionally bump up against
the VMEbus backplane throughput limits. While PCI
is faster than VMEbus, both pale in comparison to
switched serial backplanes. Any experience there?

-- Larry

 

> -----Original Message-----
> From: Jeff Hill [mailto:[email protected]]
> Sent: Monday, January 25, 2010 6:46 PM
> To: [email protected]; [email protected]
> Subject: compact PCI versus VME
>
> Hey Bob, Larry,
>
> We are looking at tradeoffs of Compact PCI versus VME. It seems that
> everything is going to switched serial fabrics, and that both the new
> compact PCI express and the VME/VXS have that. However, I notice that
> many
> modules and crates cost about half as much in compact PCI, and that the
> switched serial stuff is more prevalent in compact PCI at this time.
>
> I think I understand that BNL is still using VME for new crates? Did
> you
> guys look at compact PCI at all, have any negative opinions to offer on
> compact PCI?
>
> Jeff
> ______________________________________________________
> Jeffrey O. Hill           Email        [email protected]
> LANL MS H820              Voice        505 665 1831
> Los Alamos NM 87545 USA   FAX          505 665 5107
>
> Message content: TSPA
>
>

 


Replies:
RE: compact PCI versus VME Dalesio, Leo

Navigate by Date:
Prev: RE: caSnooper output Caizhen Liu
Next: RE: compact PCI versus VME Dalesio, Leo
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: caSnooper output Caizhen Liu
Next: RE: compact PCI versus VME Dalesio, Leo
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·