Bloodworth, Ian J

Di Marzo-Serugendo, G

Evans, D

Jones, G T

Jovanovic, P

Jusko, A

Kinson, J B

Kirk, A

Lenti, V

Lupták, M

Norman, P I

Sándor, L

Van de Vyvre, P

Villalobos Baillie, O

CERN Document Server

THE ALICE CENTRAL TRIGGER PROCESSORI.J. Bloodworth[1], G. Di Marzo Serugendo [2], D. Evans [1], G.T. Jones [1], P. Jovanovic [1],A. Jusko [3], J.B. Kinson [1], A. Kirk [1], V. Lenti [4], M. Luptak [3], P.I. Norman [1],L. Sandor [3], P. Vande Vyvre [2] and O. Villalobos Baillie [1], for the ALICE collaboration.[1] Department of Physics and Astronomy, The University of Birmingham, Birmingham, UK[2] CERN, European Organization for Nuclear Research, CH-1211 Geneva 23, Switzerland.[3] IEP, Slovak Academy of Sciences and Safarik University, Kosice, Slovakia.[4] Dipartimento di Fisica dell’Università and Sezione INFN, Bari, Italy.AbstractThe principal features of the ALICE Central TriggerProcessor are presented, as described in the draft UserRequirement Document currently under discussion.1. INTRODUCTIONThe Alice Central Trigger Processor design must becompleted and the electronics built within a short timefrom now. Many sub-detectors are now developing theirfront-end electronics, so it is necessary to define fully theinterfaces between the Central Trigger Processor (CTP)and each of the sub-systems with which it interacts. Thishas been done following the guidelines of ISO 9001 asadapted by CERN. At present a User RequirementDocument (URD) [1] incorporating earlier ideas has beenwritten and is under review. Work is beginning on aTechnical Specification, though this cannot proceed faruntil the URD has been frozen.The ALICE experiment [2] aims to measure all thesignatures currently being considered for the production ofthe Quark-Gluon Plasma. It will be the first time that allthe signatures have been studied in a single experiment,and the requirement makes a number of importantconstraints on the system. In particular, the cross sectionsfor different processes to be measured differ by severalorders of magnitude, and therefore special action must betaken to allow simultaneous measurement of all of them.The other principal challenge for the ALICEexperiment comes from the very high multiplicities to beexpected in Pb-Pb collisions at LHC energies. ALICE isdesigned to cope with a maximum rapidity density dN/dyof 8000, since there is a great uncertainty as to theexpected rapidity density at LHC energies. Thisrequirement has motivated the choice of a collection ofdetectors having very different properties as regardssensitive windows and readout times. These differ by morethan two orders of magnitude between different sub-detectors. We have learnt that at RHIC the measuredmultiplicities have come out at the bottom end of theexpected range (dN/dy of 555 ± 12 ± 35 at √s = 130 AGeV) [3], but this does not tell us very much aboutALICE conditions, as a quite different part of the nucleonstructure function is explored in the collision.2. FUNCTIONS OF THE CENTRALTRIGGER PROCESSORThe principal functions of the CTP are summarized inthe context diagram shown in figure 1.Fig. 1 ALICE CTP context diagramThe CTP is controlled by the ALICE run control. Itreceives trigger signals from a subset of (triggering) sub-detectors, and BUSY signals from all detectors. On thebasis of this information, it sends to all the sub-detectorstrigger signals which control the stages in the sub-detectorreadout. At the same time, monitoring information iscollected and sent to the DAQ, both in the form of scalerinformation and in the form of more detailed informationbundled into special “trigger event” records. In addition tothe different types of physics triggers, the CTP alsocontrols calibration triggers; these are submitted asrequests to the CTP, which then sends the detector aRUNCONTROLControlDAQScalersBUSYCalibration RequestsFRONT-END SYSTEMSALL DETECTORSCENTRALTRIGGERPROCESSORDAQ (RORC)Trigger InputsTTCTrigger OutputsFRONT-END SYSTEMSTRIGGER DETECTORSTrigger Inputsspecial calibration sequence, while protecting the detectorfrom any competing physics triggers till the calibrationsequence is completed.Trigger information is checked and a decision made foreach bunch crossing, i.e. at 25 ns intervals. In the case ofion running, where bunch crossings are separated by 125ns [4], a mask can be applied to ensure that only filledLHC clock cycles are considered.3. TRIGGER INPUTS AND LEVELS The ALICE trigger system is currently organized intothree trigger levels: level 0 (L0), which acts after 1.2 µsand sends an early strobe to the front-end systems; l eve l1  (L1) receives further information, and allows a re-classification of the trigger class at 5.5 µs; level 2  (L2)awaits the end of the longest detector sensitive period todetermine whether the event should be rejected because ofpile-up (see below for more details).A third trigger level (L3), allowing partialreconstruction of events online in a PC farm, is beingconsidered, but is beyond the scope of the presentdiscussion.The trigger inputs contributing to L0 and L1 aregrouped according to their latencies. All and only signalswhich can be transmitted to the CTP electronics in under900 ns from the time of the interaction are considered forL0. The L1 trigger receives all signals which are (i) toolate for L0 and (ii) can be delivered in under ~5 µs, inorder to deliver the signal to all sub-detectors in under 5.5µs. The maximum numbers of inputs for each level,allowing for a possible expansion during the life-time ofthe experiment, have been fixed to the values shown inTable 1.Table 1: Trigger inputs for each trigger level.Level Number of TriggerinputsL0 16L1 12L2 4The trigger inputs themselves are sent as signals inNRZ format (i.e. they retain their value throughout thefull bunch crossing cycle.)The CTP treats these inputs in three different ways.Inputs may be definitely required, explicitly not required,or ignored. The purpose of the “explicit no” is to vetoinputs rapidly. It is expected to be useful during setting-up of the experiment in order to check the complementsof trigger conditions.A sub-detector receiving a L0 trigger sets a BUSYimmediately, and holds it until it is ready to read the nextevent. Note that in ALICE the sub-detector  dead times areall independent.4. TRIGGER CLASSESThe input and output sides of the ALICE trigger arelogically linked through trigger classes. In order to definea trigger class, a collection of input and outputrequirements must be specified. For the input side, thestatus of the trigger inputs at each of the three triggerlevels (according to the three-input-state description givenabove), must be specified. On the output side, the requiredsub-detector set for the class is to be specified. For atrigger to be issued, all the sub-detectors in its list mustbe ready, and all must be clear of pile-up. This isdetermined by specifying a past-future protection windowfor each sub-detector. The past-future protection windowfor a given class is defined to be the longest past-futureprotection for any detector in the class.The protection interval specified for the trigger classthen serves to determine the future of that class. If, afteran event has taken place, a second event arrives within theprotection interval for a class, the class is rendered invalid.It is possible for an interaction to satisfy the inputtrigger conditions for more than one trigger class at thesame time. In this case all the relevant trigger classesbecome active. Some may be eliminated subsequently iffurther interactions occur before the expiry of theirprotection intervals. The final (level 2) trigger is then sentto all the detectors listed in the surviving trigger classes.A further refinement of this idea is required in thecase of pp interactions. Here the lower multiplicitiesmean that some degree of pile-up can be tolerated in thedetectors. In order to accommodate this, past-futureprotection circuits keep track of how many interactionsoccur within a given time-window centred on the triggeredinteraction, and flag a rejection if a pre-specifiedmaximum is exceeded.The use of trigger classes may be illustrated by theexample shown in figures 2 and 3. For simplicity, onlylevel 0 trigger inputs are considered. Figure 2 shows (top)a set of trigger inputs, which may be matched against therequirements for a number of trigger classes. If all therequired inputs are found, and none is contra-indicated, theclass is accepted. On output, the sub-detector lists for agiven class are matched against the BUSY/protectionstatus of the detector. In the example given in figure 3,two detectors (the CPV and the TPC) are found to beBUSY. Comparison with the lists for three differenttrigger classes shows that only in one case (class 2) are allthe required sub-detectors ready. In this example, triggerclass 2 is selected on input, and all its sub-detectorrequirements are met, so a trigger is issued to each of thedetectors in the class 2 list.   NOYESYESFig. 2-3 Examples of trigger classes on input and output.5. CALIBRATION TRIGGERSAll sub-detectors require calibration triggers, butthese are relatively infrequent compared with physicstriggers. The ALICE CTP always generates calibrationtriggers inside the “long gap” of 3.17 µs inside eachLHC orbit. A sub-detector requests a calibration triggervia software. A program arbitrates in case ofsimultaneous requests and the trigger is performedduring the first available calibration slot.The sequence of signals sent to a sub-detector inthe case of a calibration trigger is as follows: first, apre-pulse is sent, which can be used by the sub-detector, for example, to activate its calibration circuit;a fixed time later, the usual L0-L1-L2 sequence isinitiated.All the calibration requests share a singlereconfigurable trigger class, in which such parametersas the detector set to be read out and the past-futureprotection conditions to be applied can be specified foreach new calibration. Note that the past-futureprotection conditions, if applied, mean that the successof a calibration trigger cannot be guaranteed. That is tosay, as a result of the past-future protection conditionsspecified for a calibration trigger, the L0-L1-L2sequence following the pre-pulse may be missing ortruncated. The CTP does not report failed calibrationtriggers. Instead, at sub-detector level, two courses ofaction are possible. It may be sufficient to account forfailed calibration triggers on a statistical basis simplyby increasing the number of triggers required.Alternatively, if a strict count of calibration triggers isrequired, the condition can be readily monitored in theLocal Trigger Crate (see below) since the pre-pulsewhich flags the calibration sequence is always delivered.6. MONITORINGMonitoring of the CTP will proceed via two mainmethods: recording of scalers and the production ofsnapshots.The normal operation of the trigger is performedby counting, using scalers, all the inputs and outputsof the CTP and by timing all the BUSY contributions.These are read out at regular intervals on a “round-robin” basis, and thus in general not simultaneously.However, in order to trap specific errors, it is possibleto start and stop the scalers at fixed points, and thusforce a correlated count.A listing of bunch crossings containinginteractions is issued for every orbit. This is done inorder to allow the offline reconstruction software tocompute the positions of “ghost” vertices from pile-upinteractions in the case of pp interactions.The other major monitoring tool is the “snapshot”.For a period of a few milliseconds, the trigger data fromeach bunch crossing are recorded, whether a trigger wasissued or not. This allows the trigger algorithms to bechecked offline and gives an indication of thebackgrounds behind accepted triggers.The backgrounds to accepted triggers can also bemonitored by the use of random triggers, which can beissued at any time and for which all inputs and outputsare recorded. A special trigger class is reserved forrandom triggers. In this case, detectors are also read out,giving further information as to how the backgroundsare caused.7. TRIGGER OUTPUTS AND THE TTCSYSTEMThe basic output of the trigger system is the set oftrigger pulses for levels 0, 1 and 2. Because of thecritical latency for level 0, fast coaxial cables (4 ns m-1)are used. The other levels are sent using the TTCsystem [5]. The level 1 trigger uses the TTC channel“A” [6]. As this level has a precise latency, the bunchcrossing in which it arrives can be used to label theevent. In ALICE each detector receives a differentstream of triggers, depending on the classes for which itis included. This makes event labelling by orbit andbunch number an easier choice to implement thanlabelling by trigger number, as done in otherexperiments.The level 2 triggers and the calibration trigger pre-pulse are carried by the TTC channel “B”, as is theorbit reset signal. The orbit reset and calibration pre-pulse signals come at fixed points in the orbit cycle andthey do not overlap. They use the highest priority TTCinputs B-Go<0> and B-Go<1>. The level 2 triggermust be sent with lower priority, and for this reasoncannot be guaranteed to have a fixed latency. (Separatesignals are sent for L2 accept and L2 reject, using B-Go<2> and B-Go<3>.) The level 2 trigger may jitterby up to a few microseconds if it collides with a higherpriority signal. ALICE makes a fairly heavy use of theTTC facilities. The system is currently underevaluation.In addition to these pulses, a certain amount ofdigital information is sent. In principle, the TTCsystem broadcasts an event number following everylevel 1 (channel “A”) trigger; in the ALICE case thiscan be modified to be the orbit number, though inpractice it is proposed that the number be countedlocally at the TTCrx receiver by an associated FPGA,as this reduces the load on the “B” channeltransmissions.  In addition, eight further bits can besent to define a trigger type. This is discussed in thefollowing section.8. LOCAL TRIGGER CRATEThe use of the “trigger type” bits is currently underdiscussion. They may be used to control the front-endoperations, such as the suspension of zero suppression.In general, the actions for each sub-detector may bedifferent, and for this reason, an interface is required toadapt the trigger commands appropriately. In principle,the maximum information available from the CTP atlevel 1 is the full set of active trigger classes. Thisinformation, together with any local informationavailable to the sub-detector, can be used to determinewhich trigger type bits should be sent on the local TTCsystem. In order to do this, an additional board, LocalTrigger Unit (LTU), can be placed in a VME crateassigned to each sub-detector, which translates the CTPinformation into the signals to be transmitted by theTTCvi. The transfer of signals between the CTP andthe LTU is shown schematically in figure 4. Additionalapplications of the Local Trigger Crate, such as its usein monitoring the status of calibration triggers, arebeing considered.Fig. 4 Connections between CTP and Local Trigger Crate.A useful by-product of the Local Trigger Unit is thatit allows the sub-detector to be operated in stand-alonemode. Using simple logic, the LTU can be driven by alocally produced set of pulses, and these allow the sub-detector to operate independently. In this way, the sub-detector can be tested, using a standard environment,well before it is installed in the experimental area.9. SUMMARYThe ALICE experiment uses a variety of detectorshaving significantly different sensitive windows andreadout times. This leads to a trigger logic in whichpast-future protection is important, and where theproposed mode of operation involves independent deadtimes for each sub-detector. A draft User RequirementDocument describing the Central Trigger Processorfunctions has been issued, and is under discussion. ATechnical Specification is in preparation.10. REFERENCES[1] Central Trigger Processor draft UserRequirement Document.  http://www.ep.ph.bham.ac.uk/user/pedja/alice/ urd01.ps  [2] ALICE Technical Proposal. CERN/LHCC 95-71 LHCC/P3[3] B.B. Bock et al. hep-ex/007036; submitted toPhysical Review Letters.[4] LHC conceptual design. CERN/AC 95-05(LHC)..[5] B.G. Taylor IEEE Trans. Nucl. Sci. 45 (1998)821M. Ashton et al. CERN/LHCC 2000-002 [6] Ph. Farthouat and P. Gällnö, TTC-VMEbusInterface TTCvi – Mk II User Manual  http://ttc.web.cern.ch/TTC/TTCviSpec.pdf   READOUTCRATEBUSYLOCAL TRIGGER CRATEF.E.TTCrxorbitresetCTP

The ALICE central trigger processor

The ALICE central trigger processor

Abstract

Similar works

Full text

Available Versions

CERN Document Server