Sep 25 – 29, 2006
Valencia, Spain
Europe/Zurich timezone

Revised CMS Global Calorimeter Trigger Hardware Design

Sep 26, 2006, 11:20 AM
25m
Valencia, Spain

Valencia, Spain

IFIC – Instituto de Fisica Corpuscular Edificio Institutos de Investgación Apartado de Correos 22085 E-46071 València SPAIN

Speaker

Matt Stettler (CERN)

Description

An alternative design for the CMS Global Calorimeter Trigger (GCT) is being implemented. The new design adheres to all the CMS specifications regarding interfaces and functional requirements of the trigger systems. The design is modular, compact, and utilizes proven components. Functionality has been partitioned to allow commissioning in stages corresponding to the different capabilities being made operational. The functional breakdown and hardware platform is presented and discussed. A related paper discusses the firmware required to implement the GCT functionality.

Summary

The Global Calorimeter Trigger (GCT) is the last stage of the calorimeter trigger
chain. It’s main task is to receive the data from 18 Regional Calorimeter Trigger
(RCT) crates, process it, and transmit the results to the Global Trigger (GT),
where it is used to compute the first level trigger accept (L1A). Since the FIFO
memories that store the event information are quite limited in depth, the
processing and transit delay must be kept to a minimum.

The functionality of the GCT can be divided into several tasks, transporting data
from the RCT and to the GT, combining RCT data to classify and build event types,
and sorting the event objects found according to size and position. While these
tasks are not completely independent, they are physically concentrated in four
different hardware modules.

The task of transporting the input data from 18 RCT crates is handled by the source
card, a 6U VME module. Each source card accepts 2, 80 bit ECL cables and provides
outputs on four optical serial links. The parallel input data is accepted at 40MHz,
and output at 1.6GHz using industry standard serializers and 8b/10b encoding. In
addition to its data transport function, the source card also provides the
capability to capture snapshots of RCT data, and generate test patterns for link
test and synchronization.

The leaf module is responsible for the bulk of data combining and event object
building. Implemented as a double PMC module, it accepts 32 optical links and
processes the data in two large Xilinx Virtex 2Pro FPGAs. RCT jet data is processed
in six leaf modules, three for each half barrel of CMS. RCT electron data is
processed in two additional leaf modules. In the case of jet data, each half barrel
is treated as a continuous data space, so the three leaf modules which process the
data must communicate directly, sharing data in a ring topology. The processed data
is passed to the wheel card via the PMC data lines at 40MHz DDR. In addition to the
data processing task, the leaf also provides the capability to capture the raw
source card input inject test data for system test.

The wheel card is a 9U VME module, and is used for jet data sorting. It carries
three leaf modules, processing jet data for one half barrel of CMS. The wheel card
accepts data from the three double PMC sites at 40MHz DDR, and outputs sorted and
ranked jet objects to the concentrator via a 40MHz DDR LVDS parallel interface. The
processing is implemented by two large Xilinx Virtex 4 FPGAs. The wheel is a
logically simple device, required to support the leaf modules and reduce the jet
data. In addition to its processing function, the wheel also provides data capture
for system test, and an additional PMC site for functional expansion.

The concentrator is the last stage of GCT processing, and is a combination of leaf,
wheel and source functionality. It is implemented as a 9U VME board, carries the
two electron leaf modules directly, and accepts LVDS data from two wheel cards. The
concentrator needs to finish the jet object building from the center of CMS, where
the leaf modules cannot share data directly. It then combines this data with the
sorted jet objects from each wheel card, performing the final sort before sending
the processed data to the GT. The electron data is collected from the two leaf
modules, sorted, and passed on to the GT as well. The output data is serialized on
14, 1.6GHz links for transport to the GT. In addition to its data processing
functions, the concentrator provides the system VME interface and S-link readout
for the entire GCT.

The new design is discussed, although most firmware details are not covered since
they are addressed in a separate paper. The design involved various tradeoffs and
risk reduction strategies, which are presented in some detail. Upgrade capabilities
and presently unused features are also discussed.

Primary author

Presentation materials