Search

The ATLAS detector at CERN's Large Hadron Collider (LHC) will be exposed to proton-proton collisions from beams crossing at 40 MHz. At the design luminosity of 10^34 cm^-2 s^-1 there are on average 23 collisions per bunch crossing. A three-level trigger system will select potentially interesting events in order to reduce the read-out rate to about 200 Hz. The first trigger level is implemented in custom-built electronics and makes an initial fast selection based on detector data of coarse granularity. It has to reduce the rate by a factor of 10^4 to less than 100 kHz. The other two consecutive trigger levels are in software and run on PC farms. We present an overview of the first-level trigger system and report on the current installation status. Moreover, we show analysis results of cosmic-ray data recorded in situ at the ATLAS experimental site with final or close-to-final hardware., Contribution to the 11th Vienna Conference on Instrumentation (2007), 12 pages, 6 figures, accepted for publication in the proceedings in NIM A

ATLAS is a detector at CERN's Large Hadron Collider where bunches of protons in counter-rotating beams will cross every 25 ns producing, on average, about 25 collisions for a total interaction rate of 1 GHz. A three-level trigger system selects bunch crossings potentially containing interesting processes. The Level-1 trigger, implemented in electronics and firmware, makes an initial selection in under 2.5 mus with an output rate of less than 100 kHz. A key element of this is the core module of the Central Trigger Processor which combines trigger information from the calorimeter and muon trigger processors to make the final Level-1 accept decision in under 75 ns. The event-selection algorithm used by the core module is based on lists of selection criteria, i.e., trigger menus, and is implemented in fully programmable look-up tables and content-addressable memories. In addition to the event selection, the core module generates dead-time in order to limit the frequency of Level-1 accepts to a rate that the sub-detector front-end electronics can support. The core module further provides trigger-summary information to the Level-2 trigger and to the data acquisition system. The design of the core module is presented, and results from recent laboratory tests and from tests with the calorimeter and muon trigger processors connected to detectors in a particle beam are shown

The detector at CERN's large hadron collider (LHC) was exposed to proton-proton collisions from beams crossing at 40 MHz. A three-level trigger system will select potentially interesting events in order to reduce this rate to 100- 200 Hz. A trigger decision is made by the Level-1 central trigger processor (CTP) reducing the incoming rate to less than 100 kHz. The Level-1 decision is based on calorimeter information and hits in dedicated muon trigger detectors. The final Level-1 trigger system is currently being installed in the experiment with completion expected in autumn 2007. Cosmic ray data are regularly recorded as an increasing fraction of the trigger system comes online. We present an overview of the Level-1 trigger system architecture and report on the installation and commissioning process at the ATLAS experimental site. Emphasis is put on the integration of the CTP with the calorimeter and muon trigger systems. We show results from analyses of cosmic ray data recorded in situ and verify, where possible, that the Level-1 trigger meets the requirements and will be ready for data taking.

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.

The local trigger processor (LTP) receives timing and trigger signals from the central trigger processor (CTP), and injects them into the timing, trigger, and control (TTC) system of a subdetector front-end TTC partition. The LTP allows stand-alone running by using local timing and trigger signals or by generating them from memory. In addition, several LTPs of the same subdetector can be daisy- chained. The LTP can thus be regarded as a switching element for timing and trigger signals with input from the CTP or the daisy chain, from local input, or from the internal data generator, and with output to the daisy chain, to the TTC partition, or to local output. Finally, in combined mode, several LTPs can be connected together using their local outputs and local inputs to allow stand-alone running of combinations of different subdetectors.

The authors describe an optical fiber link that is used in conjunction with the CERN host interface family to connect high-performance VAXes to VMEbus or FASTBUS over distances up to 1000 m. The modular construction allows other permutations, including VAX/VAX, FASTBUS/FASTBUS, VMEbus/VMEbus, or FASTBUS/VMEbus connections, over similar distances. The link comprises two identical optical data interconnects (ODI) connected by two unidirectional multimode fibers. The ODI at each end of the link can be connected to any device conforming to the DRB32 user interface specification. The authors discuss the operation of an ODI, the testing of the optical link, and present and future ODI implementations. >