The Trigger Menu Handler of the ATLAS Level-1 Central Trigger Processor

Abstract

The role of the Central Trigger Processor (CTP) in the ATLAS Level-1 trigger is to combine information from the calorimeter and muon trigger processors, as well as from other sources, e.g. calibration, and to make the final Level-1 decision. The information sent to the CTP consists of multiplicity values for a variety of (electron, gamma, tau/hadron and jet) transverse-momentum thresholds, and of flags for transverseenergy sum thresholds. The algorithm used by the CTP to combine the different trigger inputs allows events to be selected on the basis of menus. Different trigger menus have to be considered for different run conditions. In order to provide sufficient flexibility and to fulfil the required low latency, the CTP will be implemented with look-up tables and programmable logic devices. The trigger menu handler is the tool which translates the human-readable trigger menu into the configuration files necessary for the hardware. It stores several prepared configurations and down-loads them into the hardware on request. An automatic compiler of the trigger menu and a prototype of the trigger menu handler have been implemented. I. CENTRAL TRIGGER PROCESSOR The CTP receives trigger inputs from the calorimeter and muon trigger processors, and other sources, e.g. calibration. This trigger input consists of encoded multiplicity values for a variety of electron, gamma, tau/hadron and jet transversemomentum thresholds, and of flags for transverse-energy sum thresholds. The CTP combines these values based on a trigger menu containing individually prescalable trigger items. The CTP [1,2,3] makes a Level-1 decision by taking the OR of all trigger items, adding deadtime in order to prevent the detector front-end electronics from reading overlapping events and buffers from overflowing. The Level-1 accept signal is sent to the detector front-end electronics using the timing, trigger and control (TTC) system. The trigger menu consists of a set of trigger items. The current design allows a maximum of 96 trigger items. Each trigger item is defined by a combination of trigger objects, a mask, a priority to select between the two complex deadtime algorithms and a prescaling factor. The combination of trigger objects can be composed of a single trigger object or a combination of trigger objects using the logic operations AND, OR and NOT, or a combination thereof. A trigger object is defined by a condition on a trigger input, requiring that the trigger input be equal to or greater than a certain value. In most cases this simply corresponds to a required multiplicity value. The current design allows a maximum of 128 bits of trigger inputs. Other conditions on the bunch crossing identifier or the LHC turn counter, and gate criteria such as a general veto and priority for the deadtime, can be included. An example of an excerpt of a trigger menu is given in figure 1. The trigger objects are written as triplets of inclusive multiplicity value, trigger type and thresholds, e.g. “1MU6” means an inclusive single muon trigger with a threshold of 6 GeV. “EM” stands for electromagnetic clusters and “XE” for missing transverse energy.. Figure 1: Example of a Trigger Menu (Excerpt) Different trigger menus for different run conditions have to be considered: menus for phsyics, cosmic ray and calibration runs; menus for high-luminosity and low-luminosity; and menus for the initial commissioning phase and for stable running. The trigger menu used for the CTP can and will often change from one run to the next.. Figure 2: Central Trigger Processor In order to provide flexibility and to fulfil the timing requirement for the Level-1 trigger, the CTP design is based on lookup tables and programmable logic devices, see figure 2. The look-up tables (LUT) are implemented with static randomaccess memories (SRAM). The programmable logic devices are implemented with both field-programmable gate arrays (FPGAs) and complex programmable logic devices (CPLDs). The FPGAs are based on SRAM technology and can be programmed easily and almost as many times as desired. The CPLDs are based on electrically erasable, programmable readonly memory (EEPROM) technology which allows them to be programmed in the system (in-system or in-situ programming, ISP) a few thousand up to a few ten thousand times,; depending 1MU6 mask = ON, prio = LO, scal = 1000 2MU6 mask = ON, prio = HI , scal = 1 1EM20 AND XE20 mask = ON, prio = LO, scal = 1