The ATLAS level-1 central trigger system
The central part of the ATLAS Level-1 trigger system consists of the central trigger processor (CTP), the local trigger processors (LTPs), the timing, trigger, and control (TTC) system, and the read-out driver busy (ROD/spl I.bar/BUSY) modules. The CTP combines information from calorimeter and muon trigger processors, as well as from other sources, and makes the final Level-1 accept decision (L1A) on the basis of lists of selection criteria, implemented as trigger menus. Timing and trigger signals are fanned out to about 40 LTPs, which inject them into the subdetector TTC partitions. The LTPs also support stand-alone running and can generate all necessary signals from memory. The TTC partitions fan out the timing and trigger signals to the subdetector front-end electronics. The ROD/spl I.bar/BUSY modules receive busy signals from the front-end electronics, and send them to the CTP (via an LTP) to throttle the generation of L1As. An overview of the ATLAS Level-1 central trigger system will be presented, with emphasis on the design and tests of the CTP modules.
Review of the trigger systems of the ATLAS and CMS detectors at the LHC
The characteristics and principles of multilevel trigger systems of the ATLAS and CMS detectors are considered. Calorimeter algorithms for particle identification are described. The parameters of the trigger chambers used for muon track identification are presented. Methods for designing custom processors based on custom integrated circuits and programmable arrays are described. The parameters of the trigger systems of the ATLAS and CMS detectors are compared.
Timing and Synchronization in the LHC Experiments
Data synchronization is an important aspect in the operation of the trigger and readout systems of the LHC experiments. In this paper we discuss the current understanding of the problem as developed by the LHC collaborations. Some of the main synchronization issues, namely, the assignment of bunch crossing to data, the overall alignment of the trigger system and the synchronization of the front-end readout pipelines, are covered in some detail. We discuss the tools required for distribution of timing and control signals and for the fast collection of front-end status, as well as the functions performed by the central trigger control unit. Methods to determine and monitor the timing parameters in the experiments, the sources of synchronization losses and the recovery procedures are briefly surveyed. I. I NTRODUCTION The design of the front-end readout and level 1 trigger in the LHC experiments follows a synchronous pipeline model: the detector data are stored in pipeline buffers at LHC frequency waiting the L1 decision, while data from the calorimeters and muon detectors are processed by a distributed, pipelined, tree-like processor that computes the L1 decision. The L1 latency must be constant and shall match the pipeline buffer length. The whole system behaves synchronously. Synchronization at different levels and in different contexts has to be achieved and monitored for proper operation of the system. In order to fix definitions, we list in Table 1 the various synchronization types that we refer to along this paper. The trigger system is based on the assumption that at the input of every processing stage data are synchronized and belong to the same bunch crossing. The monitoring of the bunch number of trigger data flowing in the trigger pipeline is of the greatest importance. The system operates with a single clock frequency, the LHC frequency. However, the phase of the clock signal, after distribution to tens of thousands destinations, is unpredictable at the level of a few ns. When transmitting data between sub-systems re- synchronization of the data to the clock phase at the reception is in order. Much care has to be taken to avoid missing or adding one clock cycle to the transmission latency. After the L1 accept signal, event fragments have to be collected to form complete events. Careful checking of event identifiers, recovery from event synchronization losses and management of buffer overflows are some of the issues in this context. The setting of the experiments timing implies that