The Level-1 Trigger Muon Barrel System of the ATLAS experiment at CERN

The ATLAS Level-1 Muon Barrel Trigger is one of the main elements of the first stage of event selection of the ATLAS experiment at the Large Hadron Collider. The challenge of the Level-1 system is a reduction of the event rate from a collision rate of 40 MHz by a factor 103, using simple algorithms that can be executed in highly parallel custom electronics with a latency of the order of 1 μs. The input stage of the Level-1 Muon consists of an array of processors receiving the full granularity of data from a dedicated detector (Resistive Plate Chambers in the Barrel). This first stage of the algorithm is performed directly on-detector, while the final stage is performed in boards mounted in the counting room, by the so-called off-detector electronics. The trigger algorithm is executed within a fixed latency, its real-time output is the multiplicity of muon candidates passing a set of programmable pT thresholds, and their topological information. The detector system and the trigger electronics are designed to achieve a safe bunch-crossing identification. In order to optimize design effort and cost, the trigger system integrates also the readout of the detector, with its own requirements on time resolution and overall data bandwidth. We present the detailed functional requirements of the Level-1 Muon Barrel system, its architecture, implementation and construction.


Overview of the ATLAS Trigger System
The ATLAS Trigger system is designed to perform event selection and data rate reduction, from 40 MHz to O(100 Hz) via three different trigger levels [1]. The trigger relies on the concept of trigger objects, which are identified and selected at first level. Reconstruction and selection are then progressively refined at higher levels, where all detectors data are accessible with full-granularity.
Higher-level triggers rely on the topological information produced by Level-1, called Regionsof-Interest (ROIs), associated to each trigger object, to reduce the amount of data processed and transferred from detector to storage. Selection at first-level is based on inclusive high transverse momentum (p T ) objects with low multiplicity, and energy sums sensitive to Standard Model and New Physics. The algorithms used are capable of rate reduction down to an overall acceptance rate of about 100 kHz. A constraint of the system is the maximum fixed latency allowance of 2.0 µs, including processing time and propagation delays, coming from the need to store detector data in the front-end electronics during the trigger decision.
To achieve these goals ATLAS has chosen a design based on dedicated hardware systems, including a Central Trigger Processor (CTP) which takes the final decision starting from information coming from the Calorimeter and Muon detectors. The Muon system, due to the spectrometer large volume and the different detector choices for end-cap and barrel, is further subdivided in two parts, a Barrel part and an End-Cap part.
A Muon to CTP Interface (MUCTPI) subsystem collects trigger objects from the Barrel and the Endcap subsystems and feeding it to the CTP. The ROI Builder is also part of Level-1, responsible for distributing ROI information to the next trigger level, Level-2. The Level-1 trigger decision is fed-back to the front-end electronics and other readout components via the Timing, Trigger and Control System (TTC), based on a tree of optical and copper timing signal distribution boards and links.

Overview of the ATLAS Muon Level-1 Trigger System
The use of different detectors technologies, best adapted to precision measurement or trigger has been the ATLAS driving force in the choice of the detector. Monitored Drift Tubes (MDT) are used in offline reconstruction to provide precise sagitta measurement of muons bending in the spectrometer on the full detector acceptance. Only in the region | η |≥ 2.0 of the innermost muon station Cathode Strip Chambers are used.
Resistive Plate Chambers (RPC) are used as the Barrel Trigger detector in the region | η |≤ 1.05, while in the End-Cap Thin-Gap Chambers (TGC) are used [2].

Detector description
Detectors providing signals to the Level-1 Muon Trigger electronics must provide fast information on muon tracks traversing the detector in an environment of very high background. The main detector properties required for this purpose are: good time resolution for safe bunch-crossing identification; a spatial resolution allowing discrimination on muon transverse momenta and coarse tracking for input to higher-level triggers; second-coordinate measurement in the non-bending projection with a resolution of ∼ 10 mm per point, as required for the precision chambers measurement. The trigger detectors must provide acceptance in pseudo-rapidity out to | η | 2.4 and over the full φ range. Soft background in the cavern induces random hit rates in the trigger detectors in the range 20 − 60 Hz/cm 2 at high luminosity. This requires a coincidence of two or more planes along the triggering track.
The RPC has a very good time resolution of σ ∼ 1.5ns, that allows bunch-crossing identification. The spatial resolution can be tuned to the required need, by equipping the detector with O(1cm) strips measuring bending and non-bending coordinates. Each RPC plane consists of two gas gaps, defined by resistive plates made of bakelite plates (ρ = 10 10 Ωcm 2 ), separated by 2 mm high polycarbonate spacers placed every 10 mm. The gas mixture is composed of C 2 H 2 F 4 (94.7%), ISO − C 4 H 10 (5%) and SF 6 (0.3%) and the chamber is operated in avalanche mode. The RPCs are organized in several modules and their dimensions have been chosen to match those of the corresponding MDT, to whom they are mechanically integrated.
ATLAS physics benchmarks suggest two threshold regimes for muon triggers: the high − p T regime (10 − 40 GeV /c thresholds) for heavy objects searches and a low − p T trigger (4 − 10 GeV /c) for b-physics studies. The trigger system architecture reflects this choice. In all the stations, the RPCs are composed of two units along both the azimuthal and beam direction. The so-called Middle Stations, at a radial distance of about 5 m from the interaction point contain two doublets of RPCs separated by a ∼ 0.7 m radial distance, called Confirm and Pivot doublets, while the so-called Outer Stations contain one doublet only, at 7 m radial distance [3].
Strip pitch has been optimized to minimize the number of channels and to make the measurement error due to detector segmentation negligible with respect to the overall smearing effect of 3 cm(η = 0) ÷ 7 cm(η = 1) for p T = 6 GeV /c muons, and 3 cm(η = 0) ÷ 6 cm(η = 1) for p T = 20 GeV /c muons [4]. Signals are induced on planes of orthogonal readout strips, four per doublet, two with φ − strips and two with η − strips.
To avoid dead areas between adjacent units, active zones of neighbouring RPCs are partially overlapped in η by about one strip. There is a total of 1052 chambers covering a surface of about 3650 m 2 providing 350, 000 front-end signals.

The Barrel trigger geometry
The ATLAS muon spectrometer in the barrel region is made of an air core toroid containing three measurement stations called respectively the Inner, Middle, Outer, respectively at about 3.5m, 5m, 7m from the interaction point. It is subdivided in φ in eight so-called Small and eight so called Large Chamber Sectors, as shown in figure 1. In the η view it is divided in two parts, η < 0 and η > 0. From the trigger point of view, the barrel system is segmented in 64 sectors in the φ projection, 32 sectors per half-barrel. Each physical chamber in the Pivot plane defines two trigger regions in the η − φ plane, called PADs, belonging logically to two trigger sectors, as shown in figure 3. There are thus 12-14 modules per pair of adjacent sectors, but the mapping between PADs and chambers are not one-to-one, as can be seen in the figure. One PAD region has a granularity of ∆η × ∆φ 0.2 × 0.2. A Region of Interest (ROI) within a PAD is defined by the logical overlap between areas covered by η and φ Coincidence Matrices (CM), described later, giving a final granularity of ∆η × ∆φ 0.1 × 0.1. The area processed by a CM has been chosen as a compromise on the maximum number of input channels to a single CM and the lowest transverse momentum threshold achievable given the detector strip pitch.

Overlap handling
Concerning the trigger segmentation, a relevant issue for a trigger where candidate multiplicities are used is the overlap handling. Overlap between different parts of the apparatus cannot be avoided without loosing efficiency in uncovered regions. On the other hand overlap can cause double counting of muon candidates.
The problem of overlaps inside a PAD region is solved locally by the PAD processing units that removes double counting of tracks between the four ROIs of the region. In addition, if it is found that a trigger was generated in a zone of overlap with another Pad region, the trigger is flagged as such, and any overlap will be solved at Sector level. Consequently each sector prevents double counting of triggers in the overlap region between two Pads, and flags triggers generated in regions of overlap between Sectors either belonging to the barrel or belonging to the endcap. This kind of overlap is easily solved in the MUCTPI, where information from all sectors is collected.  . Trigger segmentation in phi, in green are shown the various detector elements, in yellow all phi strips belonging to a tower are shown, where wired-OR and logical-OR is performed. In blue a PAD region is defined along with the PAD window reaching the inner and outer confirm planes. In red RoIs are shown.

The Barrel Trigger algorithm
The design of the Level-1 Muon Barrel has been driven by a simple concept (figure 2). The trigger is done with three planes segmented in strips in the r-z and r-φ projections. Using as origin the nominal position of the p-p interaction region, the strip hit in the central plane of the Middle Station (RPC2) defines for low transverse momentum particles a coincidence window where to search for a correlated hit in the inner plane (RPC1) of the same Station (low p T algorithm). For higher momentum particles, then the strip hit in the middle plane defines also a new coincidence window where to search for a correlated hit in the outer plane (RPC3) of the Outer Station (high p T algorithm).
The trigger is done on both bending and non-bending projections. The fact that the three planes are made of two detector layers, allows definition of the order of the coincidence logic (2-out-of-4, 3-out-of-4, 4-out-of-4 majorities), which can be used to maximize the efficiency and to minimize the rate due to uncorrelated and correlated background.
The algorithm is executed in parallel on a number of coincidence windows, each window calculated with an acceptance probability for p T greater than a given threshold. Smearing effects are due to fluctuations of energy loss in the calorimeter, length of the interaction region, multiple Coulomb scattering in the calorimeter and non-uniformity in the non bending projection of the magnetic field. The detector segmentation is chosen to make the error negligible compared to these effects [4]. Such an algorithm can be implemented using an array of dedicated processors, running in parallel and placed physically close to the data source, i.e. on-detector, and arranging the data processing in projective trigger towers.

Input data
The trigger system processes data using the full detector granularity of about 350,000 strips, sampled at a rate of 8 × 40 MHz. This sampling period of 3.125 ns has been chosen as the internal system clock of the Coincidence Matrix Processors because it is comparable to the detector resolution, becoming the basic time unit in the digital delay lines used in the trigger part for the alignment of signal coincidences and in the readout part for hit time measurements. The total input aggregated bandwidth is ∼ 112 T bit/s.

Output data
The total throughput of the system on the trigger data path is 81.92 Gbit/s given by 64 trigger sector output producing a new result every 25 ns. Each trigger word contains details of up to two muon candidates, their spatial position on the η − φ plane, the highest threshold passed by the candidates, overlap flags indicating if the candidates have been found in a region of overlap between trigger sectors, some timing information used to synchronize the system. Regarding the readout datapath, the system delivers to the data acquistion system details of detector hits, trigger hits, and intermediate trigger results at every Level-1 Accept, through 32 optical links running at 1.28 Gbit/s.

System description 2.1 System requirements and constraints
The trigger algorithm defined in the previous sections needs input data from all stations from a small region in the η − φ space. The obvious choice in the system architecture has been to organize data collection in trigger towers. This architecture is highly parallel and coupled with the need to minimize the number of data links has lead to the choice of placing most of the trigger electronics -5 -

JINST 4 P04010
on-detector. Local processors called PADs contain all elements of the trigger pipeline needed to process data in a small detector region (∆η × ∆φ 0.2 × 0.2), while electronics mounted in 16 standard crates, sitting in the control room, takes care of processing data from a larger part of the apparatus (∆η × ∆φ 1.0 × 0.2, i.e. a sector). The main purpose of this electronics, called off-detector, is the counting of candidate multiplicities and the handling of overlap regions which might lead to double counting of single muon candidates.
The full trigger chain has been designed for robustness, capability to sustain high background rates and to handle regions of detector inefficiencies. The majority level of the time and spatial coincidence is programmable, and it has been foreseen to mask input channels with the granularity of a single strip. In order to further improve on robustness, it is also possible to include in the low− p T algorithm the outer detector plane. The improvements obtainable in presence of correlated background are well illustrated in [3,5].
Other requirements for the trigger system are the bunch-crossing identification capability, necessary to an efficient reconstruction, and the data bandwidth reduction of all ATLAS detectors down to a sustainable value. These goals can be achieved by segmenting the detector in such a way that time-walk due to propagation delay along detector strips is much smaller that the machine crossing period (about 25 ns) and by optimizing the electronics design.
A further requirement is the choice, for all ATLAS front-end electronics, of storing data before the level-1 decision for a maximum time of 2.0 µs. This requirement leads to a maximum processing time of about 1µ s, considering that propagation delay along optical links and electronics connecting the level-1 processors to the front-end electronics takes a similar time, also about 1 µs.
The expected radiation environment foreseen in the ATLAS cavern has been estimated with extensive simulations, giving an upper limit on the expected charged particles and neutron flux where level-1 electronics is mounted. All these values are very similar to the radiation levels expected in space, and similar care is necessary in the development of the system to mitigate the effects of irradiation.
Due to changing magnetic field along Monitored Drift Tube wires, to reach a contribution to the spatial resolution of O(10 µm) in the track measurement it becomes important to measure the second coordinate with a precision of about 1 cm. For this reason the RPC detector has been segmented in strips also in the non-bending plane.
Considering all requirements described so far, the needs in time and spatial resolutions are respectively O(2 − 3 ns) in time and O(1 cm) on the coordinate measurement.

The trigger efficiency and expected rates
Efficiency curves as a function of p T have been produced using a detailed detector simulation of a large sample of single muon events (10 6 ) with a wide p T range (3 − 50 GeV /c) [6]. The efficiency curves have been determined both for the low − p T and the high − p T parts and are shown in figures 4 and 5. The curves reach a plateau at about 0.82 and 0.78 respectively. This inefficiency is mainly due to reduced geometrical acceptance of some sectors of the barrel spectrometer. Two small sectors in the feet region in particular have a 0.05 loss of acceptance due to the presence of the structures supporting the magnet.
Also the level-1 trigger rates have been calculated for different machine luminosity scenarios, for single muons, from the convolution between the inclusive cross-sections for the main decay   modes and the calculated trigger efficiency curves. The inclusive muon cross-sections at the LHC for decays of b anc c hadrons, top quark and W/Z boson decays have been calculated using the Montecarlo program Pythia 6.13 [7], while the inflight decays of π and K mesons have been calculated using the DPMJET Montecarlo program [8]. The cross-sections integrated in the kinematic region (η < 2.7 p T > 3 GeV /c), as a function of p T are shown in figure 6.
At lower p T the π/K decays are the dominant source of muons while for p T > 8 GeV /c the cross-section is dominated by semileptonic decays of b and c hadrons. Table 1 shows the estimated rates for the standard thresholds of 5-40 GeV /c, for luminosities of L = 10 31 cm −2 s −1 to L = 10 34 cm −2 s −1 .

The readout scheme
The readout scheme foresees the combination of detector and trigger information in a single data fragment. This choice allows the development of a single device for all readout and trigger requirements thus reducing manpower needed for developments. The readout fragments contain raw RPC hit information with a time measurement bin of 1/8 of the bunch crossing period, comparable to the detector resolution of about 2 ns, allowing a way of calibrating the trigger system in time, and to give a time-of-flight information to precision chambers with a better resolution than the bunch-crossing time. The same fragments contain also trigger hit information, for example the associated p T threshold firing the tower, if present. The data fragment contains also partial results from the trigger algorithm, as collected along the processing pipeline. A decision has also been taken regarding event building stages, so that event building occurs at every collection point along the chain, based on event tags as defined by the data acquisition community. The first collection point is the High − p T on-detector processing elements (PADs), performing event building on a ratio of 8/1, while second and third event building stages happen at the trigger sector level (Sector Logic, SL) and readout driver level (ROD), with ratios respectively of up to 8/1 and 2/1.
Regarding the link choice, copper serial or parallel connections have been chosen for short connections, while for connections between cavern and the counting room, optical fibres have been chosen. Table 1. Single muon trigger rates as obtained at L1 , for different low and high p T thresholds, at L = 10 31 cm −2 s −1 , L = 10 33 cm −2 s −1 and L = 10 34 cm −2 s −1 . L1 muon trigger rates L = 10 31 "Cosmic" 5 GeV/c cm −2 s −1 Barrel (Hz) Endcaps (Hz) Barrel

Overview of the electronics system
Signals from the RPC detector are amplified, shaped and discriminated inside the detector Faraday cage. The amplifier-shaper-discriminator boards, each containing eight front-end channels, are attached to the chamber and directly to RPC strips, embedded in the mechanical structure. On-detector electronics includes also Splitters and PAD processors. They are attached on top of the detector inside metal boxes.
Regarding signal levels, front-end electronics delivers time-over-threshold signals on ECL levels. Since the rest of the system uses differential LVDS for all connections up to 10m lengths, proper conversion is done where appropriate, namely at the input of Splitter and PAD elements.
Signals belonging to pairs of φ strips of the same chamber and with the same coordinate, are wired-or on chamber before conversion and then sent to the Splitter and PAD boxes to reduce the channel count.

JINST 4 P04010
Digital time shaping of the front-end signals is done in the so-called Coincidence Matrix ASIC (CM), which performs almost all of the functions needed in the trigger and the readout system.
Each CM aligns in time the front-end signals, performs the time and spatial coincidence, and makes the p T cut on three different thresholds. The full-programmability of the geometrical coincidence has been done to avoid inefficiencies that may arise from non-ideal spectrometer geometry, and to minimize the effort on the electronics boards development. This device also contains the level-1 pipeline memory and derandomizing buffer. A detailed description of this chip is given later.
Signals from non-pivot detector doublets RPC1 and RPC3 are sent to so-called Splitter boards, whose main functionality is to collect front-end signals from one chamber and fan-out them to neighboring PAD processors which need these data (maximum of two).
RPC signals from the first two detector doublets RPC1 and RPC2 are sent to a low − p T PAD processor containing η and φ Coincidence Matrix boards (CM board). These dedicated CMs produce an output pattern containing the low − p T trigger results in the η and φ projections independently. This pattern is sent to a high −p T PAD box via a bundle of LVDS links.
RPC signals from the RPC3 doublet, and the corresponding pattern result of the low − p T CMs, are also processed by CM boards. These boards, mounted inside the high −p T PAD box, contain the same Coincidence Matrix chip as used in the low − p T part, but they are programmed for the high − p T algorithm.
The cumulative data of four low and four high CM boards are finally processed in the so-called high − p T PAD logic FPGA. This FPGA generates for each bunch crossing a trigger result with the associated ROI information.
This information is transferred, synchronously at 40 MHz, to the corresponding Sector Logic module, that collects the overall result from all towers of a given sector [9][10][11].
Readout data follows the same route. All CM serial data outputs are sent along copper links from middle to outer stations, and inside the high − p T board to the PAD logic FPGA. This device processes readout data and outputs results.
Shipping of readout and trigger data is based on a time multiplexing mechanism where trigger data has higher priority. These multiplexed data are sent via an optical link to Sector Logic boards (SL). The link choice is based on a custom-made assembly based on Glink chipset.
Trigger and readout data are split only at the output of the SL board: • readout data from two SL are collected by one Readout Driver Board (ROD), then shipped to DAQ; • trigger data is sent via copper links from the SL to one input of the Muon to the Central Trigger Processor Interface (MUCTPI) via custom built interface boards (called Barrel MUCTPI Interface Board).
A simplified scheme of the trigger slice is described in figure 7.
The off-detector electronics, housed in VME64x crates, uses a custom backplane bus to transmit readout and trigger data, along with all necessary flow control and timing signals. This backplane, called RODbus (Readout Driver bus), has a modularity of five slots, with slots dedicated respectively to ROD (central slot), Sector Logic (SL) (left-hand and right-hand slots) and MUCTPI interface (left-most and right-most slots). Details of this arrangement will follow later.  Figure 7. The barrel slice, showing the splitting of the system in front-end, on-detector and off-detector electronics. MUCTPI and ROB are respectively standard interfaces to the Central Trigger and the Data Acquisition System.

Segmentation
Chamber types of varying sizes have been built to maximize hermeticity of the Muon Spectrometer. In this respect sizes vary from 1110mm × 4850mm for largest chambers to 320mm × 530mm for chambers closing gaps of magnet elements.
Being based on such different chamber sizes, optimization of the electronics modularity has been a trade-off between number of strips per chamber, their pitch and length. The adopted solution has a reasonable number of readout channels, giving a reasonable Bunch Crossing identification capability, spatial and time resolutions and fanout. Strip pitches have beeen chosen to be 3 − 4cm and roughly projective when moving from middle to outer chambers. Strip lengths vary within the ranges of 530 − 2425mm for the eta strips, while the phi range is 480 − 1200mm. Concerning the front-end modularity, the basic segmentation is 8 channels, with normally two sets of 32 strips received per RPC doublet.
This modularity has been kept in the design of the electronics, by using 32-signal inputs per connector per processing element in the pivot plane of the η view. Concerning the φ view, 32channel inputs are required by the pivot plane, while 40 inputs are required per processing element in the confirm plane, so 32 and 40-input connectors have been used accordingly. It is important to note here that chamber sizes are not projective, and a trigger tower processes a variable number of front-end signals from the confirm plane. The decision has been to keep 32-channel inputs for the φ pivot plane and keep confirm η signals arranged in groups of four per cable (on RJ45 connectors). This last choice gives us a significant flexibility in arranging the inputs to CMs.
Choice done has been to reduce the total number of channels in φ , so that all strips belonging to a chamber being part of a tower are wired-OR if belonging to the same chamber, while up to a three-fold logical-OR is done on signals coming from adjacent chambers.
Since cable lengths are different for different towers, a detailed Montecarlo program has been used to define all cabling, to build a database then used for the actual cabling of the detector.

The Splitter Board
The Splitter box main requirement is to receive ECL-like signal from all front-end channels coming from confirm planes, translate into differential LVDS and fanout to processing unit. The receiving circuit carries also the front-end bias voltage.  Care has been taken to guarantee that maximum skew between channels is well below 1 ns, so that propagation delay on the boards does not deteriorate the detector time resolution. Simulation has been used to make sure that no need for a fan-out greater than two is required throughout the detector, in this case all Splitters are built using the same circuit layout. They are built out of a mainboard containing all voltage regulators and sensors, while for the φ and η views different piggy-back boards are mounted. The modularity of the piggy-back boards has been chosen to match front-end, 32 inputs for η strips and 40 for φ inputs (see figure 8). Input connectors are able to accept ribbon twisted cables and output connectors have been chosen to satisfy the necessity to implement tower projectivity by properly connecting Splitter outputs to PAD inputs. The granularity of 4 output channels per cable was chosen on η outputs, after Monte Carlo studies of all detector towers, while the granularity in φ is 40, same as the inputs. Temperatures and voltages are monitored by a neighbouring PAD via an I2C bus. A photograph of a Splitter can be seen in figure 9. Figure 10 shows the block diagram of the coincidence-matrix chip [12,23,25]  internal clock that synchronizes all the pipeline operations inside the chip and a 160MHz clock used for all readout operations. The first block at the input of the chip is an edge detector and dead-time circuit. This block detects the rising edge of the arriving signals and, for each detected signal, sets a programmable dead time, of the order of one hundred nanoseconds, to avoid the arrival of extra pulses in the same RPC channel.

The coincidence matrix ASIC
The second block allows for the possibility of masking to 0 RPC noisy channels. The third input block is a programmable-depth pipeline that is very important for setting up the timing of the system. Since the cables that bring the signals to the chip have different lengths, corresponding to different paths, this block allows for timing adjustment of the different groups of signals, in such a way that their coincidence is in time. The pipeline can be programmed in groups of eight RPC signals, with a minimum step corresponding to the period of the 320MHz internal clock (3.125ns). The RPC front-end takes care of aligning in time a group of eight signals, with a maximum spread of 1 ns.
At the output of the programmable depth pipeline, the signals follow two different paths: one goes to the read-out part and one to the trigger part.

The ASIC trigger path
In the trigger part, the first block is the programmable mask to 1 and pulse width setting circuit. This block allows for masking to "1" unused inputs to the matrix and for the digital shaping of the signal before making the trigger coincidence.
Digital shaping is necessary since the signals must be made as short as possible before the coincidence, to minimize the rate of fake triggers due to low-energy background particles in the ATLAS cavern (uncorrelated noise). This block allows for a programmable digital shaping of the signals, adjusting the duration in steps of 3.125 ns, corresponding to the internal clock period.
The next block is the pre-processing block. Here the declustering of the signals and the 1/2 and 2/2 majority logic are performed. The RPC detector has an intrinsic cluster size of about 1.5 strips and a declustering algorithm is needed to define the cluster center.
The dimension of the matrix is 32x64. In the low − p T trigger, the signals coming from the RPC2 doublet are connected to the 32 I0 and 32 I1 inputs, and the signals coming from the RPC1 doublet are connected to the 64 J1 and 64 J2 inputs. In the case of the high-pT trigger the I0 inputs are used to connect the low − p T trigger result (the I1 inputs are not used), while the J0 and J1 inputs are both used to connect the high − p T RPC doublet.
The coincidence matrix has three times 32x64 coincidence cells, since the trigger must be performed on three different p T thresholds simultaneously. The cells have the possibility to be programmed at will, through a dedicated serial line, to perform 2/4, 3/4, or 4/4-majority logic, and to be set according to the required cut on the pT threshold.
The output of the coincidence matrix is sent to the readout part and to the trigger output part of the chip. Before producing the trigger output, the trigger pattern is synchronised back to the 40MHz clock. Typical latencies, when input pipelines are shortest, are about 75 ns to produce a trigger output. The 32-bit pattern contains the RPC2 doublet pattern that has generated the trigger and the associated coincidence timing. The trigger result (total of 7 bits) is produced synchronously with the 40MHz clock. Two bits are used for coding the highest p T threshold that was validated by the trigger (in case of no trigger both bits are zero), and two bits are used as a flag to indicate if the trigger occurred in a possible overlap zone (left or right) within the Pad region. The remaining three bits contain the low order bits of the Bunch Crossing Identification (BCID) number.

The ASIC read-out path
The main element in the read-out part of the chip is the level-1 pipeline memory. This memory stores the information for a time corresponding to the ATLAS level-1 trigger latency, which is 2.5µs, including some contingency (700 ns). The pipeline is implemented with a BCID-tagged and time-tagged set of FIFOs. The level-1 latency memory is subdivided in seven blocks: six blocks contain the information from the RPC doublets; one block contains the trigger array output result; each block contains also the 12-bit BCID counter and a 3-bit time interpolator value for a total of 47 bit words. This counter measures the phase of arrival of a frontend signal with respect to the external 40 MHz clock with an LSB of one eighth of the bunch crossing period and tells also to the read-out at which moment, within the bunch, the trigger occurred. This information is needed for the timing calibration of the system. For events selected by the LVL1 trigger, data from the level-1 latency memory are transferred to the derandomizing memory from where they are read out serially.
The ASIC has been implemented in a 6-metal 0.18µm UMC process, with about 530kgates (about two million transistors) on an area of about 23 mm 2 and since then it has been tested in various testbeams. The ASIC layout is shown in figure 11. Regarding testability, 32 internal logic scan chains have been implemented and used in production for acceptance tests (97% coverage), and a full JTAG Boundary scan is available for tests after mounting.
The output bitstream can flow at a programmable speed of 10−80Mbit/s in the DSlink format. The ASIC's (190) registers are fully programmable via the I2C interface. Most relevant registers, which may cause heavy loss of data in case of a Single Event Upset, are designed with redundancy in mind. They are triplicated and the output value is the one present in at least two of the register copies. Automatic recovery of the error is done on the triple redundancy registers and an SEU flagging bit is present to complete the system. All other registers only contain a parity bit and in case of a SEU a flag is raised. In this case the reprogramming of the ASIC internal register will restore the original value.

The Processor Box (PAD)
The PAD processor is made of a number of elements that are explained as follows: • Motherboard. This board carries all processing units and their interconnections and in case of the outer chambers also performs signal processing. It performs a logical-OR of signal inputs coming from one layer of φ strips of signals belonging to adjacent chambers.  Figure 12. PAD control buses. I2C buses control most of the system, while JTAG is used mainly for the local FPGA. An SPI protocol is also implemented to access the external flash memory.
It contains an FPGA (Xilinx XCV200), called PAD logic, which is programmed as the second readout and trigger processing stage, right after the CM ASICs. Delay chips are able also to fine tune internal phases of clock and other timing signals. Other services are present on the processor, like the possibility to store trigger configurations on local flash memories. In this case, upon a configure command delivered via CANbus, the local microcontroller is able to configure and check that the configuration has been executed with success. Another service, that has been used only before chamber installation, gives the possibility of delivering test pulses on response to specific TTC broadcast commands. It contains voltage regulators to differentiate voltage domains belonging to all piggy-back board circuits. Temperature sensors are also present to monitor local temperatures close to hottest components.
• Coincidence Matrix Board. Four are present, each board carries one CM ASIC and all input circuitry. The input part complexity resides in the way front-end signals connect to it. As already said a detailed Montecarlo has been used to produce the trigger connection at the input of this board and many thousands of cables have been produced of different lengths in order to be able to keep the system in synchronism. Four variants have been built to be able to receive η or φ inputs, and either LVDS or ECL translators (ECL from the front-end or LVDS receivers if inputs are coming from confirm planes or from the low − P T outputs).
• ORJ1-board. This board receives front-end signals and performs a logical OR of signals belonging to the second (confirm) layer of adjacent chambers, as required by the pointing geometry and tower definition.
• ELMB. This element is a CANbus controller, based on an ATMEL device (ATMEGA128), able to access all programmable elements of the PAD [13]. Three I2C buses access IO registers, voltage and temperature regulators and ASICs, while a fourth I2C bus is used to access one neighbouring splitter box. A JTAG bus is available to program the motherboard FPGA remotely (see figure 12).   Figure 13. PAD low layout. The four CM's collect front-end signal (from RPC) and output the readout and trigger data (to high − p T ) over external LVDSs buses. TTC and CAN are used for initializing and timing of the processor • TTCRq. This is a standard Trigger and Timing receiver board used throughout the experiment. Its clock output and timing signals are reference to the whole processor.
• Optical link TX. The Optical link board is a custom board called GLINK, containing one HDMP1032 serializer and optical transceiver. The board is able to deliver a 17-bit word at 40 MHz.

The Low − p T and the High − p T PADS
The two processor types share the same board layout but differ in the direction of some data paths and programmability of the system. In particular, as can be found in figures 13 and 14, the low − P t board does not contain a TX mezzanine, all readout and trigger signals from low to high stations travel on LVDS differential connections. Data processing of each trigger tower, containing the low and the high − p T parts, is done on the high p T PAD. The pipeline and readout stage past the CM ASICs is performed on the high − p T processor.  Figure 14. PAD high layout. The PAD logic implemented in an FPGA processes readout and trigger data and sends the results to an output link.

The PAD logic
The PAD logic firmware can be divided into two main parts: • Readout part. This part takes care of receiving each of the eight CM serial inputs and deserialize into 16-bit words. Upon event request via a L1A, all internal FIFOs (up to 8) are scanned for data. If data belonging to the expected event number are present the CM fragment is shipped to an output FIFO and then to the optical TX. This output FIFO sends data to the corresponding Sector Logic board as soon as data are present. Since no signal is generated by the destination to stop the dataflow when needed (XON-XOFF mechanism), the system must rely on a BUSY signal that must be propagated up to the ATLAS Central Processor. At this stage of the event building each PAD fragment contains eight CM fragments, each fragment containing the L1ID and BCID values that can be checked against the ROD value.
• Trigger part. This part receives as input from each of the eight CMs values for P T threshold, ROI, 3-bit BCID number and overlap flags. The input pipeline is able to process data with a latency of four BC's and find the highest Pt candidate in the tower, assigning it to a specific RoI. If more than one candidate is present, only the one with highest Pt value is sent to the optical link.
Readout and trigger data are time-multiplexed by the optical link logic present in the FPGA, by assuring that any trigger will be sent with a fixed latency, giving less priority to data words over trigger words. Other signals like busy status of the processor, are sent as special trigger words which produce no candidates. For further details see references [14][15][16]. A photograph of an high − P T box is shown in figure 15.

The optical interconnection
The Level-1 (L1) Muon Barrel Trigger transmits data serially on a custom designed optical link. The TX and RX nodes implement a unidirectional optical link on multimode fibre driven by a 850nm Vertical Cavity Surface Emitting Laser (VCSEL), with a reach of 500m. The TX nodes plug into the L1 Muon Barrel Trigger processors resident on the RPC detectors, while the RX nodes are hosted on VME carrier boards in the counting room. The RX has a dual layout, with two independent receiver units. This allows concentrating on the VME board up to 8 L1 Trigger Processors outputs. In total, the Muon Trigger needs 500 Tx nodes and 250 Rx nodes. Despite the availability on the market of new-generation serializer/deserializer chipsets, we have selected for this purpose the G-Link HDMP-1032A/4A [17] for their ability to guarantee a fixed latency. In the ATLAS environment, all the electronics (including the Tx and Rx optical nodes) receive the Large Hadron Collider (LHC) clock via an ad-hoc distribution tree. The frequency-agile architecture of the G-Link chipset is not bound to specific data rates and it allowed us to use this clock (40.078 MHz) for the transmission. The bit-rate on the fibre is 20 times higher ( 800Mbit/s), with a time slot for each bit (Unit Interval or UI) of 1.25ns. The PASS circuitry makes it possible to implement a true fully-synchronous link: the Tx strobes the input bus and the Rx drives the output bus by using the same LHC clock. The latency is constant and not influenced by environmental parameters and fabrication process variations. It does not change after a reset, a loss of lock or even a power cycle. This feature is critical for the correct operation of the L1 Muon Trigger, which works in a pipeline fashion synchronous to the LHC clock. We also benefit from the G-Link capability to distinguish between data and control words (differently codified in the serial stream). This allows us sending across the link two different logical streams, one assigned to the RPC detector read-out (data words, 16-bit payload), the other to the L1 Muon Trigger (control words, 14-bit payload). At the present time, no other commercial architecture offers comparable features. For these reasons, the G-Link has been widely used also in other ATLAS detectors, both as HDMP-1022/4 and HDMP-1032A/4A (see a photograph of a receiver board in figure 16).

The off-detector Trigger and Readout System
On-detector electronics executes the trigger algorithm and send the relevant trigger information, via optical links, to the off-detector Central Trigger Processor, that can validate or reject the event with a fixed latency of less than 2.0 µs. During the decision time of the Trigger processor, data produced by the RPC detectors are stored in FIFO memories in the on-detector electronics. If an event is accepted by the first level trigger, a L1A pulse is generated and transmitted across the TTC system together with the pertinent Event Identifier (EVID) and BCID; in this case, data stored in the FIFO buffers are transferred to the off-detector electronics across the same optical link used for the transmission of trigger information. Trigger and read-out data of each sector of the spectrometer are managed by a Read Out Driver (ROD) crate.
-20 - RX-SL boards have the task to receive and elaborate trigger and read-out data from the ondetector electronics. The RX-SL boards pre-process the trigger information and send them to the Central Trigger Processor through the Barrel Muon Central Trigger Processor Interface board (MUCTPII). The RX-SL boards arrange readout data in an event frame (RX Frame) and transmit them to the adjacent Read Out Driver across a custom backplane RODbus via a high speed serial link.

JINST 4 P04010
The main task of the ROD [36] is to perform a further framing, before transmitting data across the optical link S-Link to the next acquisition levels, i.e. to the Read Out Buffers (ROB). The ROD also manages the timing signals of the trigger and data acquisition system. For this purpose, the ROD hosts a TTCrq receiver module from which it receives timing and control signals to be forwarded to the RX/SL boards on the RODbus.
On the RODbus, data and timing signals are transmitted in LVDS standard to achieve high rate, low skew and jitter; the serial links between each RX-SL and ROD have an aggregate bandwidth of 2 Gbit/s (48bit@40MHz). Control signals run at lower rate and are transmitted using the TTL standard. The RODbus also hosts a 48-bit TTL bus that allows the RX-SL boards to transmit trigger data to the µCTPI boards (see a block diagram of the RODbus in figure 17).
Many ROD boards have been developed for the other ATLAS subdetectors, implementing different logic and functionalities in order to fulfil specific detector requirements. However, they share the same logical output format and optical fibre. In this way, the ROB design is unique for the entire apparatus, making it possible to use the same architecture for the higher level DAQ systems.

The Receiver and Sector Logic (RX-SL)
The SL board has a form factor of the VME 64X 6U standard and is equipped with two VIRTEX II Xilinx FPGAs, labelled VME FPGA and SL FPGA. The board also hosts one 32-bit 8k word deep FIFO, up to four Glink two-channel receivers (RX mezzanine), and one Serializer (TX SerDes) that sends data via the RODbus backplane to the adjacent ROD [27] (see a photograph in figure 19). The main task of the VME FPGA is to initialize and control the four RX mezzanines and to interface the whole board to the VME bus. It is possible to access its own configuration registers and the SL FPGA internal registers. The VME FPGA is also capable of driving a JTAG chain to download  working at double of the system frequency of 40 MHz. The SL FPGA performs event building on data received by all PADs belonging to a trigger sector. Normally 6 or 7 streams of 16-bit words are received by the RX mezzanines and processed by an event building state-machine which has been built with some tolerance to transmission errors, i.e. if words are received from a data source which are not compatible with the data format, they are discarded until a proper data frame arrives. This process continues until a maximum number of retries is reached. In this case the event fragment is built with error flags.
An important debugging tool to monitor the trigger system is the presence of all input and output trigger data belonging to the trigger path of the event inside the event fragment built by the SL. Clock domains belonging to the input data, the event building and the data transmission parts are decoupled inside the SL FPGA by extensive use of double-clock FIFO's. VME and SL FPGA communicate with a simple 32-bit data 4-bit control word parallel synchronous protocol, where the VME FPGA is always considered as master for the transmission. The on-board FIFO is also connected to the VME FPGA and its main purpose is monitoring processed data.
Regarding the trigger part, the optical link receiver assures a fixed latency delivery of trigger information from the on-detector electronics. A programmable delay of up to 3 BCs is built at each input to synchronize the trigger towers belonging to the same beam crossing. Within a latency of 7 BCs, data from up to 8 sources are processed and the two highest p T candidates are available, if present, on the 32-bit output word. All relevant information, i.e. details on RoI, p T value and overlap flags are sent to the MUCTPI interface. A block diagram of an SL board is shown in figure 20.

The Readout Driver
The ROD board (see figure 21) has the form factor of the VME 64X 6U and is equipped with two VIRTEX II XILINX FPGAs, labelled as VME FPGA and ROD FPGA. The board also hosts an ARM7 microcontroller, the TTCrq receiver, the S-Link transmitter and the two deserializers (RX SerDes) that receive data via RODbus backplane from the RX/SL boards. The main task of the VME FPGA is to interface the whole board with the VMEbus; the VME FPGA allows a user to access the ROD FPGA memory locations and configuration registers and to read the microcontroller's data. The VME FPGA's clock is obtained from an on-board 40 MHz oscillator multiplied by 2 by the internal Digital Clock Manager.
The ROD FPGA performs the event building algorithm on data transmitted by the RX-SL boards. The ROD FPGA also hosts registers for the configuration and control of the event builder state machine. In the same fashion as the VME FPGA, the ROD FPGA clock is obtained multiplying by 2 the 40 MHz board clock. The ROD FPGA receives 48-bit words and the recovered 40 MHz clock from each RX SerDes. It is also interfaced with the TTCrq module -from which it receives the TTC timing signals and the 40 MHz LHC's clock -and to the S-Link transmitter, that is fed by a 40 MHz clock derived by the 80 MHz internal clock. Figure 22 shows a simplified block diagram of the ROD board. The ROD FPGA communicates with the VME FPGA via a serial synchronous custom protocol, carried out by two point-to-point unidirectional lines with a data rate of 80 Mbit/s. The main advantages of a serial link are a simpler PCB layout, the use of a small number of FPGA pins and limitations of ground bounce effects.
The VME FPGA is the Master of the serial link, managing both the write (for data and for address) and read operations. As a consequence, the ROD FPGA can transmit data only if the VME FPGA has previously requested them. The serial protocol allows the user to set once an 8-bit target address and then to perform an arbitrary number of 32-bit read or write accesses to the selected location in the ROD FPGA.
The main task of the ARM7 microcontroller is to program the TTCrq receiver, via I2C protocol. This makes it possible to access all the TTCrq registers, both for configuration and monitoring purposes. The microcontroller also allows reading, via the internal ADC, the three power supplies on the ROD board (5V, 3.3V, 1.5V). The power supply and temperature on the RODbus are acquired from a remote ADC installed on the backplane via an I2C bus. The microcontroller's output data can be read via a RS232 port or can be redirected on the VMEbus, through a 16-bit parallel bus handled by the VME FPGA.
Besides the internal 80 MHz FPGA clocks, the 40 MHz LHC clock, the two 40 MHz SerDes clocks, the 40 MHz S-Link clock run all over the board. Even if these clock signals have the same frequency, they have an unpredictable phase relationship and should be handled as domains asynchronous to each other. All these clocks are present in the ROD FPGA, which is the most complex and critical section of the board. In order to decouple the clock domains and to guarantee their coexistence on the ROD FPGA, FIFO memories have been extensively used.

The Barrel MUCTPI Interface
The main function of the MUCTPI Interface is to interface the SL trigger output to the MUCTPI boards sitting in a crate about 10 m apart. This is accomplished by converting the CMOS SL output into a 32-bit LVDS bus. The interface also contains a set of LVDS receivers. These receivers connected to the SL via RODbus could be used in a future trigger upgrade e.g. as inputs from Tilecal hadronic calorimeter. A photograph is shown in figure 23.

System interconnections
The decision taken on the choice of the system interconnections has been to use copper where distances were less than 10 m and optical connections elsewhere, in particular between the cavern and the counting room.
After having built a database holding lengths and cabling maps for all so-called η and φ cables, connecting Splitter to PAD modules, a dedicated program has been running on laptops used by the cabling operator in the cavern. This program accessed the cabling database to produce a detailed cabling procedure. This procedure guided the operator through cabling showing graphically the cabling sequence, i.e. source and destination connectors for each of the many thousands of cable of different type and length that were coped with by using this program.
Other system connections include the so-called low-to-high cables, arranged in bundles of 6 32-twisted-pairs and connecting the low to the high p T PADs. These are custom built twisted pair shielded cables.
-25 - Another important connection type is the control network, where all PADs belonging to a station are connected in daisy chain via a CANbus connection. A total of 64 of these custom built cables make up the network, each connecting up to 14 nodes arranged in a daisy chain. They have been laid and connected to 8 dedicated control PCs, each hosting two quad KVASER CANbus controller cards.
The final system also contains a Timing and Trigger distribution network, organized in two independent partitions called side A (η < 0) and side C (η > 0). The clock and other timing signals are propagated from the TTC modules to the PADs, with optical fanouts of 1-to-16 in USA15 and 1-to-8 in the cavern, and to the RODs, with an optical fanout of 1-to-16, and finally from the RODs to SL modules using the RODbus.
The arrangement of the 16 crates in two TTC partition is shown in figure 24.

The power system
The power system design has been built with the following requirements in mind: the need for radiation tolerance and the need to operate in presence of magnetic field. The necessity of installing the system close to the detector, thus reducing cable lengths and cost, has enforced these constraints which have ruled out the choice on many off-the-shelf systems.
The final choice was the CAEN EASY system. This industrial system has been designed to survive the ATLAS cavern environment, in presence of radiation and magnetic fields of about 300 Gauss.
It consists of a set of tri-phase to 48V DC power generators and custom crates containing all types of modules needed:  Figure 24. Arrangements of all VME crates in two TTC partitions. For clarity connections are shown only on a few modules per type.
• 2-8V 9A modules • ADC modules A control chain connects all crates together to a mainframe controller sitting in the counting room. Since the trigger and detector parts are tightly integrated and under control of the RPC detector DCS system, no further details will be given here. To give an idea of the system size, around 140 modules power the on-detector electronics of the Level-1 system.
The total dissipated power of the trigger system is about 8kW, with about 20% of this value dissipated on cables.
2.14 Environmental issues 2.14.1 Radiation tolerance All on-detector components used in the system have been evaluated for the irradiation doses expected in the experiment [28][29][30]. Assuming a large safety factor of O(50), due to uncertainties in the simulation, CMOS devices process spread and lot-to-lot variations, the expected total dose in the hottest region is 210 Gray in ten years, the expected neutron fluxes is 5.6 × 10 11 , while charged particle flux, capable of producing Single-Event-Effects (SEE) is roughly a factor five smaller. This requirement has lead to a long validation study of all devices used in the system, with dedicated irradiation campaigns. Results can be found in measurements done at Louvain (Belgium), PSI (Switzerland), where components where irradiated with 60 MeV protons, in Italy where components where irradiated with a Co 60 source. All components chosen for the final system have shown resistance up to the expected doses.

Construction
The construction of the building blocks of the level-1 Muon Barrel system has passed many steps, from the evaluation of prototype to Preliminary, Final, Production Readiness reviews. Without going into detail for the full process, the on-detector electronics has passed the following tests after production: • Industrial test: this test has been done in Bologna using an industrial JTAG system connecting each of the produced 832 PAD boards to dedicated test boards (see photograph in figure 25. The daisy chain thus built had almost full coverage of the board IOs. The test program was able to show where the fault was and its type. Voltages and temperatures were read out also during this test, together with the phase measurements of the delay chips. This test showed that about 17 % of the production needed to be reworked (bad solderings, misplaced or missing components were found).  figure 26) has been used to check the behaviour of the system. Chambers were operated with final gas mixture and Voltage, and the readout operated in final working mode [18]. These tests were also useful to find cabling errors and discover dead channels. More that 350 k channels were tested this way, finding only 0.46 % of dead channels [32,37].
• Chamber tests have been carried out in the ATLAS surface installation area to each chamber before lowering it in the pit. A testpulse was used in this case to check if the full readout and trigger chain was fine after transport.

The initialization and control system
The Level-1 Control software runs on two platforms communicating via the CANbus, the first platform is a linux-based PC running dedicated software based on the ATLAS Online and Dataflow framework while the second is microcontroller-based, running custom software using the ELMB CANOpen firmware framework [13]. Both platforms make use of a common set of CANOpen commands (Object Dictionary), which has been customized to work in two different modes.
• handle single bus transactions; • issue specific commands like Initialize or Check PLL locks.
They exchange Service Data Object (SDO) packets. The number of CANopen packets which are sent to complete a single bus transaction is shown in table 2, while specific commands require only a single CANopen packet.

Integration with DAQ
A control and initialization Module has been implemented in the ATLAS DAQ system [35], this application is able to react to commands coming from the Run Control (LOAD, CONFIG, START, UNLOAD) and issue the required actions to the on-detector electronics. Errors during configuration are reported via the Message Reporting System (MRS) to the DAQ console. After start of run, the Level-1 Control application communicates to DCS, via DAQ-DCS Communication Software (DDC), periodic measurements and status of the system. No direct connection is foreseen between Level-1 Control PCs and the ATLAS DCS system database (SCADA). Figure 27 shows the connections of the Module to the DAQ and DCS system.
The online software needs to provide to each control PC the static maps of nodes connected to it.

System configuration
Configuration of the system can be done in two ways, either using a list of bus transaction commands, or using generic commands implemented in the ELMB firmware. The first mode is used mainly for debug purposes while the second is used for fast initialization and control in the experiment. A standalone application is capable of handling all possible commands defined in the Object Dictionary, and to combine them for specific purposes. A logging procedure is able to write on file the list of atomic commands issued to the CAN node for initialization. These log files are used to build ordered sets of command lists. Each set can be optionally compiled in order to produce a binary file, following the configuration command scheme described below, which is stored locally in the PAD Processor flash memory, to be executed during initialization. The local flash memory size of 8 Mbit, is large enough to contain more than one initialization type. Thus during normal data taking, a single CAN bus transaction, initialize the Processor for different Cosmics or Beam run types, setting timing, thresholds, coincidence roads. Each configuration is stored in different locations of the local memory, and can be started with a single command of the Object Dictionary. Since the partitioning of the system permits to initialize all CAN buses in parallel, we expect a total fast initialization time of a few seconds for the full barrel system.
The structure of the configuration is shown in figure 28. A configuration header is followed by a number of variable-length fields. Each field is a command line transformed by the microcontroller into an I2C register access. The result of each individual access is stored and at the end of execution is available to the control PC.

Configuration database
Each configuration of the Level-1 trigger system is stored into a hierarchy of flat ASCII files. The Configuration database contains these files, their binary version and the list of configurations currently loaded locally on the system. If the configuration required by DAQ during CONFIG is locally stored a fast initialization will start, otherwise the Level-1 Controller will retrieve the required set of files, tagged by run type and time interval of validity, and a download will be issued to all nodes. The same procedure is required each time a change in the configuration is needed.
The current configuration status of the system must be known at any time. If the Control PC configuration files need to be changed, they have to be retrieved from the database. If new configurations need to be stored on the on-detector processors, the ASCII configuration files need to be processed, then a download will be issued to all nodes. This operation is time consuming and should be done some time before the configuration is required, not to interfere with the data acquisition.
The structure of the configuration files reflects the system architecture, organized in sectors, towers and PAD processor, and at the lowest level each PAD processor is assigned a concatenation of device-specific configuration files. This structure is also used by calibration programs, that need to know the current configuration, process calibration or normal data, to produce new configuration files.

System Monitoring
A second requirement of the Control system is the monitoring of the system during data taking. All PAD processors make the following information available during data taking: • the main power supply Voltages along with all regulated Voltage levels; • temperatures of all critical devices, inside the PAD and Splitter boxes; • trigger rates on bending and non-bending projections; • status of memory usage in the readout chain; • status of over-current alarm flags due to Single Event Effects latchup; • lock statuses of TTC receivers, ASICs, FPGAs, delay chips and transmitters.
All this information has to be made available together with the RPC chamber condition data. The tool used to propagate the information from DAQ to DCS has been developed within the ATLAS Online software Group, and it is called DDC (DAQ DCS Communication). It uses the infrastructure of the Online Information service.

Latency
A key parameter of the level-1 system is the trigger latency, i.e. the time delay imposed on the front-end electronics before sending the read-out data. This value has to be fixed and is given by processing time plus the propagation in the cabling system. Detector latency has been fixed to a maximum value of 2.5 µs, but the trigger should not take more than 2.0 µs to give a 0.5 µs contingency. In table 3 the various contributions to the latency are shown. It has to be kept in mind that the difference in length between the fibre bundles carrying trigger signal from cavern to counting room is the source of uncertainty in the table shown. During normal operations these differences are absorbed by proper settings of the MUCTPI input pipelines.