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.
The Central Trigger Processor Monitoring module ( CTP _ MON ) in the ATLAS Level-1 Trigger System
The Central Trigger Processor (CTP) receives a 160-bit trigger pattern from the Calorimeter and Muon Trigger sub-systems at 40 MHz update rate, corresponding to the 25 ns bunch-crossing period of the LHC. This information is evaluated against a trigger menu to form the general Level-1 Accept (L1A) signal. The CTP Monitoring module (CTP_MON) monitors the trigger inputs of the CTP on a bunch-by-bunch basis in order to monitor trigger rates per bunch and to detect any pathological bunches in the LHC machine. This information can also be used to estimate the luminosity per bunch. The monitoring system is able to build histograms of the input data at the maximum possible rate, with one 30-bit counter per input bit for each of the 3564 possible bunch positions in the LHC giving at least 26 hours of free running without overflow condition. The design and simulation of the CTP_MON will be presented. I. FUNCTIONAL DESCRIPTION The CTP Monitoring module is one of six types of modules that form the Central Trigger Processor [1]. Its task is to monitor the selected 160-bit pattern coming from the trigger subsystems at the 40 MHz bunch clock. This monitoring is performed bunch-by-bunch (for the 3564 bunches in the beam) and each trigger input is histogrammed in a 30-bit counter. An overall architecture of the CTP_MON, illustrating its functional blocks, is shown in Figure 1. Figure 1: CTP_MON overall architecture A. Input Decoding The PIT bus (Pattern In Time), containing the 160 trigger signals, already aligned in time and synchronized to a local bunch clock, is first applied to an input decoding block. These inputs, consisting of multiplicity or energy information, are decoded into the PTC bus (PIT Decoded). The input decoding is based on several Look-Up Tables (LUT) implemented in memory blocks inside an FPGA. These LUTs provide the following flexibilities over the PIT bus: • Routing: all the PIT inputs should be able to be connected with respect to any output; • Grouping: all the PIT inputs should be able to be grouped in any configuration of groups, e.g. 2, 3 or 4; • Decoding: the logic must decode the groups according to a large number of possibilities (keeping the same number of inputs at the output). Considering groups of multiplicity type, Figure 2 illustrates two possibilities of decoding. Figure 2: One example of decoding using the LUT The LUTs are implemented in ROM memory blocks and each one contains data previously stored during the FPGA configuration. In order to increase the design flexibility, when routing different groups of PIT, two layers of registers are used at the input and two at the output of the LUT. Concerning the input side, the first layer (the one that receives the PIT bus) is responsible for keeping the minimum and constant setup time (tsu) for all the inputs, no matter what very different routing takes place. The second layer in the data path is used to increase the flexibility of the physical routing inside the FPGA, thus avoiding timing restrictions due to a new configuration. On the output side, the same idea applies for the first layer in the data path. The last layer of registers is useful to keep a minimum and constant clock to output parameter (tco). This extensive use of registers is only possible because the CTP_MON unlike other modules of the CTP is not critical in latency. Due to the registers in the data path, the input decoding circuitry presents 4 clock cycles of latency from input to output. This is compensated inside the Core Processing, using an Input Decoding (Look-Up Table) PIT<159..0>
Reduction of Surface Flashover of the Beam Screen of the LHC Injection Kickers
The LHC injection kicker magnets include beam screens to shield the ferrite yokes against wake fields resulting from the high intensity beam. The screening is provided by conductors lodged in the inner wall of a ceramic support tube. Operation with increasingly higher bunch intensity, and narrow bunches, now requires improved ferrite screening. This will be implemented by additional conductors; however the good high-voltage behaviour of the kicker magnets must not be compromised by the supplementary screening. Extensive studies and optimisations have been carried out, to better satisfy the often conflicting requirements for low beam coupling impedance, fast magnetic field rise-time, high vacuum and good high voltage behaviour. A new configuration is proposed which reduces significantly the electric field associated with the screen conductors and the secondary electron yield of the surface of the ceramic tube. Results of high voltage test results are also presented.