by Terry Barnaby
System Engineer
Beam Ltd.
terry@beam.ltd.uk
A particle has a hard life at CERN. A proton
starts its journey as a hydrogen atom in
a small, common-looking red bottle the
size of a soda siphon at the head of an
imposing 80-meter linear accelerator. With
its electron stripped, electric fields accelerate
it to about one third of the speed of
light. It soon enters the 200-meter-diameter
Proton Synchrotron (PS) machine,
where further acceleration and conditioning
take place, with other protons, as a
beam. After that, the particle is sent to a
bigger machine such as the Large Hadron
Collider or directly used in an experiment.
Normally its journey will end in a nearspeed-of-light
collision with some other
unsuspecting particle. At every stage along
the way, various sensors and high-speed
data-processing engines are spying on the
proton, not least in the PS machine.
A versatile juggler of particles, the
Proton Synchrotron (Figure 1) is a key
component in the accelerator complex at
CERN, the European Organization for
Nuclear Physics in Geneva, Switzerland.
The PS machine accelerates and manipulates
protons or heavy ions for various
experiments. Apart from system downtimes,
the PS runs continuously, operating
on a different particle beam, for the various
ongoing experiments, every 1.2 seconds
or so. During operation it all looks
quiet around the PS ring’s complex. All
that an observer can notice of the particle
motorway traffic within the evacuated
tubes is a loud and heavy surging buzz
from the multiple large power transformers
outside every 1.2 seconds as megawatts
of power surge to supply the system.
One of the many important instruments
required for this machine is the Trajectory
Measurement System. The purpose of the
TMS is to measure the track of the particles
as they race around the ring at nearly the
speed of light. There are 40 sets of metal
plate detectors spaced around the PS ring,
providing 120 analog signal channels. Each
of these signals, three per detector pickup,
needs to be digitized at 125 megasamples
per second. That is an overall data rate of 15
billion samples, or 30 Gbytes of data, per
second. Due to this high data rate, there is
a need to process the data in real time, to
reduce the amount of data and pick out the
information of interest before storing it.
CERN’s scientists and engineers had
devised the basic processing algorithms
suitable for FPGA implementation. For
engineers at Alpha Data and at Beam Ltd.,
our job was to develop the idea and pro-
duce a complete working system in a reasonable
time frame and at reasonable cost
to do the job.
Designing the TMS
From the early stages of design, we envisaged
a very modular system that would
provide fault tolerance and ensure easy live
maintenance. It also had to be flexible and
expandable. We took the concept of modularity
down even into the FPGA fabric,
where each FPGA implements three separate
pickup-detector channel blocks.
Alpha Data and Beam have worked
jointly on a number of real-time, FPGAbased
instrumentation systems. These
XCELLENCE IN AUTOMOTIVE & ISM
generally employ a generic Linux-based
computer as the main control and dataaccess
module, with a number of FPGAbased
modules at the front end to do the
fast data capture and real-time processing
work. The TMS is based on that system
model. It comprises a Linux-based system
controller that provides control, data
postprocessing and external data access,
and four, eight-slot, CompactPCI rack
modules, each with a Concurrent
Technologies Intel dual-core processing
Figure 1 – CERN scientists accelerate and condition particles
in the ring-shaped Proton Synchrotron.
card running Linux. Within the rack
modules are specially designed, FPGAbased,
Pickup Processing Engine, or
PUPE, cards (Figure 2).
When developing such real-time systems,
especially with FPGAs, it is important
to decide what work the various
system modules will handle. FPGA hardware
is excellent for doing simple, realtime,
repetitive things in parallel and at
relatively high speed. Software running on
a conventional processor is good for control
and data access as well as flexible data
postprocessing. Getting the partitioning of
this work right, together with the protocols
used among the system’s various hardware
Fourth Quarter 2009 Xcell Journal 23