The ALICE trigger system (TRG) consists of a Central Trigger Processor (CTP) and up to 24 Local Trigger Units (LTU) for each sub-detector. The CTP receives and processes trigger signals from trigger detectors and the outputs from the CTP are 3 levels of hardware triggers: L0, L1 and L2. The 24 sub-detectors are dynamically partitioned in up to 6 independent clusters. The trigger information is propagated through the LTUs to the Front-end electronics (FEE) of each sub-detector via LVDS cables and optical fibres. The trigger information sent from LTU to FEE can be monitored online for possible errors using the newly developed TTCit board. After testing and commissioning of the trigger system itself on the surface, the ALICE trigger electronics has been installed and tested in the experimental cavern with appropriate ALICE experimental software. Testing the Alice trigger system with detectors on the surface and in the experimental cavern in parallel is progressing very well. Currently one setup is used for testing on the surface; another is installed in experimental cavern. This paper describes the current status of ALICE trigger electronics, online error trigger monitoring and appropriate software for this electronics

Bhasin, A

Evans, D

Jones, G T

Jovanovic, P

Jusko, A

Krivda, M

Králik, I

Lazzeroni, C

Lietava, R

Scott, H

Sándor, L

Tapia Takaki, D

Urbán, J

Villalobos Baillie, O

CERN Document Server

The ALICE trigger electronics M.Krivda a, A. Bhasina, D. Evansa, G.T. Jonesa, P. Jovanovića, A. Juskoa, I. Králikb,  C. Lazzeronia, R. Lietavaa, H. Scotta, L. Šándorb, D. Tapia Takakia, J. Urbánc, O. Villalobos Bailliea  for the ALICE Collaboration   a School of Physics and Astronomy, The University of Birmingham, Birmingham, UK b Institute of Experimental Physics, Košice, Slovakia  c P.J. Šafárik University, Faculty of Science, Košice, Slovakia   Marian.Krivda@cern.ch  Abstract The ALICE trigger system (TRG) consists of a Central Trigger Processor (CTP) and up to 24 Local Trigger Units (LTU) for each sub-detector. The CTP receives and processes trigger signals from trigger detectors and the outputs from the CTP are 3 levels of hardware triggers: L0, L1 and L2. The 24 sub-detectors are dynamically partitioned in up to 6 independent clusters. The trigger information is propagated through the LTUs to the Front-end electronics (FEE) of each sub-detector via LVDS cables and optical fibres. The trigger information sent from LTU to FEE can be monitored online for possible errors using the newly developed TTCit board. After testing and commissioning of the trigger system itself on the surface, the ALICE trigger electronics has been installed and tested in the experimental cavern with appropriate ALICE experimental software. Testing the Alice trigger system with detectors on the surface and in the experimental cavern in parallel is progressing very well. Currently one setup is used for testing on the surface; another is installed in experimental cavern. This paper describes the current status of ALICE trigger electronics, online error trigger monitoring and appropriate software for this electronics. I. INTRODUCTION The ALICE trigger system operates with nucleus-nucleus, proton-nucleus and proton-proton interactions, having rates between about 8 kHz and 300 kHz [1]. The main block of the ALICE trigger electronics is the Central Trigger Processor (CTP), which is shown in Figure 1. The CTP [2] is implemented using 7 different types of 6U VME board, together making up eleven active boards for the CTP. This system will receive and align up to 60 trigger inputs in parallel from the trigger detectors. There are three different trigger levels (L0, L1 and L2) with latencies from 1.2 μs to 88 μs. The system allows dynamic partitioning in order to make optimum use of detector readout. The system provides a flexible past-future protection. The L0 trigger is sent as an LVDS signal, or optionally via channel A of the Trigger and Timing Control (TTC) system [3]. The L1 signal is sent on channel A of the TTC system and trigger data associated with level 1 are sent as a message on channel B of the TTC system. The L2 trigger is sent as a message on the TTC system after a delay, currently 88 μs, to allow for the longest required past-future protection interval [2]. Outputs from the CTP go to the LTUs of each sub-detector. The LTU serves as an interface between the CTP and the sub-detector readout electronics. The LTU is also able to run in a stand-alone mode of operation, and the LTU fully emulates the CTP protocol, thus enabling sub-detectors to carry out development, test and calibration tasks independently of the CTP. The timing of the emulated trigger sequences is identical to the timing during the global run. The LTU can generate incomplete sequences and different types of errors can be introduced, either randomly or "on demand" (this option is available in both global mode and stand-alone emulation mode), all in order to verify the capability of the FEE to detect errors. The trigger electronics is based on ALTERA Cyclone FPGAs (Field Programmable Logic Arrays), which provide flexibility to modify the trigger system in the future. The system provides a range of monitoring and debugging options. Snapshot memories enable detection of any system inconsistency and an identification of possible faults. Around 1200 counters, with considerable built-in redundancy, are read at regular intervals (once per minute). This provides relevant physics information and also verifies the correct functioning of the hardware.   Figure 1: Alice Central Trigger Processor 259A. Alice trigger system parameters The main parameters of Alice trigger system are shown in Table 1.  Table 1: Main system parameters L0 trigger delivery to FEE 1.2 μs from interaction L1 trigger delivery to FEE 6.5 μs from interaction L2 trigger delivery to FEE 88 μs from interaction L0 trigger inputs 24 L1 trigger inputs 24 L2 trigger inputs 12 Classes 50 Clusters 6 Past-future protection circuit 4 for each trigger level Rare event handling see sec. B Interaction record  see sec. B  B. Classes and clusters The trigger class is a basic processing structure in the CTP logic. The CTP forms 50 independently programmable “physics” trigger classes [4]. Information about trigger classes is used at each level of the trigger decision. The use of the trigger classes can be understood by considering how the L0 trigger for given class is generated, as shown in Figure 2. The L0 trigger class condition is realized as a logical AND formed from all the 24 L0 trigger inputs, 2 scaled-down BC clocks and 2 random triggers. The trigger inputs for classes 1 to 44, the scaled-down BC clocks and the random triggers can either be selected, or set to a “don’t care” state. For classes 45 to 50, the trigger inputs can be selected, or their complement selected, or they can be set to the “don’t care” state. The two scaled-down BC inputs are 25ns-pulses, synchronous with the BC clock, with a programmable interval between the pulses in a range from 0 to ~25s (a 30-bit counter). The two random triggers inputs are random patterns of 25ns-pulses, synchronous with the BC clock, which are generated by a 31-bit linear feedback register. Both types can be used along with the physics input; it defines a trigger class condition. Each class has an associated detector cluster, i.e. a designated group of detectors which must be read out when the trigger class is activated. A trigger class is associated with a single cluster; the corresponding cluster BUSY reflects the BUSY status of all the sub-detectors included in the cluster. In addition, the DAQ BUSY, CTP BUSY and CTP dead time contribute to the overall BUSY state for a given cluster. They are mandatory vetos, i.e. they cannot be deselected. The DAQ BUSY and the CTP BUSY are set by software. The CTP dead time, currently 1.4 μs, ensures that there is sufficient time to transfer serialized data (52 bits) between boards. In addition to the 50 physics classes, there is also a test class, whose parameters can be configured at run time via software. Its principal purpose is to allow detector calibration during physics runs, though in principle it can be used for any software trigger. Figure 2 also shows certain other veto conditions which can be used to control the generation of a L0 trigger. The test class L0 signal is used as a veto to block physics when a software trigger is issued. The four bunch-crossing masks can be used to define which bunch crossings are to be allowed for trigger generation. The class mask is a software flag, which can disable the given class. The all/rare signal is used as part of the mechanism to ensure the protection of rare events. It is class dependent. For a non-rare trigger class, the signal is selected, and, if present enables the trigger class. If it is absent, it indicates insufficient buffering in the DAQ system, and the class is disabled, allocating only the rare trigger classes. The generation of L1 and L2 triggers is logically similar, but much simpler: more inputs can be received, but the only vetos are the corresponding past-future protection circuits for the given trigger level.    Figure 2: L0 trigger class C. Past-future protection In order to protect the detector from recording events which have significant levels of overlap from other interactions before or after the one selected by the trigger, a system of past-future protection has been implemented. There are four fully programmable past-future protection circuits at each trigger level. Each trigger class is associated with an arbitrary subset of them. There is also an additional identical circuit dedicated solely to the test class. The circuit is shown in Figure 3. The interaction inputs INTa and INTb are each a programmable function of four level 0 input signals. The signals Interaction 1 and Interaction 2 are produced in a similar way and their generation is shown in Figure 4 (see below). Each block has two programmable thresholds (THx1 and THx2) and two corresponding outputs (Px1 and Px2). The protection intervals (ΔTa, ΔTb) are independently programmable. The two delay blocks (Delay a, Delay b) serve to align the protection results with the time when the protection is checked (the Time alignment diagram in Figure 3). The protection output P is an arbitrary function of the P1, P2 and the delayed INT signals. The delayed INT carries the information about the interaction that triggered the event. It is common to all the Past-future protection circuits at the same trigger level. 260 Figure 3: Past-future Protection D. Interaction record The CTP generates two Interaction signals, which are simultaneously used by all Past-future Protection circuits and the interaction record circuits. The generation of the interaction signals is shown in Figure 4. A 16x1 programmable look-up table gives outputs which are generated from any logic combination of the four L0 trigger inputs. Alternatively, for system testing and development, any of the two scaled down BC clocks, or two random triggers can be selected.   Figure 4: Interaction record II. CTP ELECTRONICS The Central Trigger Processor – CTP (Figure 1) for the ALICE experiment consists of 11 active boards. There are: BUSY board; L0 processor board; L1 processor board; L2 processor board; INT board; six Fan-out boards. Connections among the CTP boards are made using the VME backplane with user-defined pins on the P2 connector. The connections on the VME backplane are described in ref. [5]. There are also 6 passive boards for trigger inputs, which serve to transform from LVDS connectors to a flat cable.  A. L0, L1, L2 processor boards These three boards have a similar design and functionality. They receive signals from trigger detectors, than compare these signals with defined classes and make a decision. They also serialize data and send them to the next trigger level via the VME backplane. Each of these boards has 4 Past-future protection circuits and a sampling memory with a recording period of 26ms. B. Fan-out board Inside the CTP processing is performed using only classes and clusters. On the fan-out board the cluster information is converted into a set of signals specific for each detector i.e. we determine which detectors will be read out. The outputs from the fan-out boards are connected to appropriate LTUs. Each fan-out board has 4 outputs, i.e. it can control 4 detector partitions. C. BUSY board The BUSY board receives BUSY signals from the 24 sub-detectors as LVDS signals and converts detector BUSY signals to the corresponding Cluster BUSY signal. BUSY signals from detectors that participate in a given cluster are all ORed together. The cluster BUSY signal is sent to the processor board where it is active as a veto in appropriate class. D. INT board The INT board sends the interaction record and CTP readout to the DAQ system. It controls the functionality of the ALICE SIU DDL module. III. LTU ELECTRONICS The Local Trigger Unit (LTU) [6] is designed to serve as the interface between the CTP and the detectors. It can run in a global mode or a standalone mode. In standalone mode it can fully emulate the CTP. This is the main functionality of this board because it allows each detector to work independently during the debugging or calibration phase. In global mode the LTU receives signals from the CTP and translates them to appropriate format (LVDS or formatted words to be sent through the TTC system). The LTU receives BUSY signals from detectors as LVDS signals and propagates them to the BUSY board, which is the part of the CTP where BUSY signals from all detectors inside a cluster are OR-ed together. It sends the L0 trigger to the sub-detector through an 261LVDS cable or through the TTC system and it sends L1 and L2 trigger messages through the TTC system.  IV. TTCIT BOARD In order to monitor incoming triggers and recognize possible errors in the trigger timing and the errors in trigger sequences, the TTCit board has been developed. The board can monitor the optical output and L0 output (LVDS signal) of each trigger partition. It can detect the arrival of the Bunch Crossing (BC), Orbit, PrePulse, L0, L1 signals, the L1 message, L2accept message and L2reject message, and in addition the Region of Interest (RoI) flag. It can also detect the following errors: spurious L0, L1, L1 message or L2 message (if trigger or trigger message come in wrong time window); missing L1 message or L2 message (if trigger message is completely missing); incomplete L1 message or L2 message (if trigger message is missing only partially); data error in L1 message or L2 message (if there are wrong data in message); PrePulse error; Calibration error; Bunch crossing id error (BCID from L2 message and BCID from TTCrx chip are different). A detailed description of these errors can be found in ref. [7]. In case of an error the information is displayed on the front panel of TTCit board. The same information can be read via the VME interface. For detailed information and a precise identification of errors, the content of a snapshot memory (26 ms) can be read out via the VME bus. The snapshot memory contains information triggered either by error in three modes (pre-trigger, middle-trigger or post-trigger) or by the first L0 trigger. For all detected triggers and trigger errors there are 32-bit counters implemented inside the FPGA, an Altera Cyclone EP1C12. This choice allows the possibility of remotely reprogramming the FPGA by loading new code from a flash memory Am29LV081B. The flash memory is accessible via a VME interface. Detailed information about the TTCit board can be found in ref. [8].  Software has been developed in order to control the TTCit board. As an example, the main panel and a panel for TTCit counters are shown on Figure 6. In the TTCit software we can set appropriate parameters, such as trigger error conditions, all programmable times, selection of scope signals, start the reprogramming of the FPGA, and read all counters. In addition to basic control and access to all TTCit registers, the control software  also provides the following features: decoding of the snapshot memory (SSM) contents and its display  in human readable form; analysis of the SSM contents, detection and counting of errors, and display of data in a human readable form suitable for quick and easy location and visualization of problems; monitoring of the TTC traffic, off-line SSM analysis with possibility to write snapshots into a file for later analysis by the TTCit software or some more sophisticated tool (e.g. ROOT). This functionality is complementary to the monitoring provided by the on-board logic. A detailed description of TTCit software can be found in ref. [9].  Figure 5: TTCit board   Figure 6: TTCit software V. SUMMARY The ALICE trigger system, including the Local Trigger Unit electronics, has been commissioned with all ALICE detectors on the surface and in the pit in parallel. Currently it is installed in the cavern where the full system is integrated with the other experiment service systems (Trigger - TRG, Experiment Control System - ECS, Data Acquisition System - DAQ and Detector Control System - DCS).  262VI. REFERENCES [1] D. Evans and P. Jovanovič, ALICE User Requirement Document, ALICE-INT-2003-055 [2] CTP Preliminary Design Review,  http://www.ep.ph.bham.ac.uk/user/pedja/alice [3] Trigger and Timing Control system, http://ttc.web.cern.ch/ttc/ [4] ALICE Technical Design Report on Trigger, Data Acquisition, High Level Trigger and Control System, CERN-LHCC-2003-062, 7 January 2004 [5] O. Villalobos Baillie et al., Proc. 12th Workshop on Electronics for LHC and Future Experiments, Valencia, Spain, September 2006 CERN-LHCC-2007-006, 15 January 2007 [6] Local Trigger Unit, http://www.ep.ph.bham.ac.uk/user/pedja/alice [7] P. Jovanovič: Theory of errors, http://epweb2.ph.bham.ac.uk/user/pedja/alice/ctp/fe_error.pdf [8] A. Jusko, P. Jovanovič: TTCit preliminary specification,  http://epweb2.ph.bham.ac.uk/user/pedja/alice/ttcit_22.pdf [9] I. Králik: User manual for TTCit software, http://home.saske.sk/~kralik/TTCit/fI.php    263

The ALICE trigger electronics

The ALICE trigger electronics

Abstract

Similar works

Full text

Available Versions

CERN Document Server