TWiki> ALICE Web>AliceTriggerIntroduction (18 Dec 2008, _47DC_61ch_47DC_61cern_47OU_61Organic_32Units_47OU_61Users_47CN_61mbombara_47CN_61555683_47CN_61Marek_32Bombara? ) EditAttach
-- MarekBombara - 18 Dec 2008

ALICE trigger system for newcomers

Basic terminology (timing, inputs, signals,...)

The basic time unit for (almost) all electronics in ALICE and in LHC is 25 ns or one bunch crossing (BC) - it is a time distance between two bunches of protons. The adequate maximal rate is then 40 MHz. In LHC circuit there can be up to 3564 valid bunches and those represent one orbit - in the time terms one orbit is about 90 μs (i.e. the time needed for one bunch to do one round in LHC). The clock of the electronics in the trigger system works also in BC units.

Trigger is an electronic system which makes a decision whether the collision is worth to save or not. The input to the trigger is represented by triggering detectors which send the signal to the trigger when collision occurs. The output from the trigger is represented by readout detectors which detect the collision. The basic scheme for the signal propagation is:

triggering detector ---------------------> trigger -------------------------> readout detector

Note that triggering detectors can be also readout detectors. The signals from triggering detectors to the trigger are called "trigger inputs". Signals from trigger to readout detectors are called "signals" or simply "triggers". Sometimes they are called also "trigger signals". We can update our scheme:

triggering detector ------trigger input---------> trigger -----trigger signal------> readout detector

The trigger system consists also from some parts. For the first approach we can consider only two basic parts - Central Trigger Processor (CTP) which is the decision maker (In fact it consists from several electronic boards). And Local Trigger Unit (LTU) which works as an interface between readout detector and CTP. LTUs are the same for all detectors. So we can update our basic scheme to:

triggering detector ------trigger input-----> CTP ------trigger signal------> LTU ------> readout detector

The ALICE trigger is 3-level trigger system. It can have 3 consecutive trigger inputs - L0, L1 and L2 and 3 consecutive signals (or triggers) - also L0, L1 and L2 (actually the L1 signal is called L1 message and L2 signal is called L2a (accepted) or L2r (rejected) but it is not necessary to know it at this level). What does it mean and how does it work? 3-level trigger is a consequence of different event processing speed of various detectors. Let's have some real life example:

TRD wants to trigger on jet events. Those events have a different topologies from the usual minimum bias events. When particles from the collision pass the TRD the TRD sends L0 trigger input to CTP that there was apparently some collision (does not know yet if it is jet event or not). When there are no other problems (see Vetoes section) CTP sends L0 signal to readout detectors (for example to TPC). In TPC after L0 signal came the digitization of each channel starts and lasts for 96 μs which is TPC drift time. Now the TRD has a bit of time to calculate online some characteristic of the event. If the event passes some additional criteria for the jet event the TRD is sending L1 trigger input to CTP and CTP then sends L1 signal to TPC. If the TRD does not send the L1 trigger input in some time limit the CTP also does not send L1 signal (between L0 and L1 signal should be exactly 6.5 μs). The TPC checks for L1 signal for confirmation to continue processing the event. If it did not come in time TPC ignores that event. If the L0 and L1 trigger inputs were succesfully sent to CTP the TRD has now even more time (up to ~ 100 μs) to calculate other characteristic of the event and if everything goes fine (event looks like jet event) TRD sends the final L2 trigger input. CTP then sends L2 signal to TPC and TPC sends the processed event to the DAQ (Data Acquisition).

There can be up to 24 L0 trigger inputs, 24 L1 trigger inputs and 12 L2 trigger inputs. It means that you can physically connect 24 cables from the detectors (or their parts) to the CTP (for the L0 trigger inputs propagation). So far all those 24 L0 inputs are shared by many detectors or their parts but only one L1 trigger input is in use (TRD). There is no L2 trigger input so far. So most of the trigger settings do not have L1 trigger input. In this case CTP does not wait/check for L1 trigger input and automatically sends 6.5 μs after L0 the L1 signal and after cca 100 μs L2 signal to readout detectors. (In reality CTP makes decision every clock (1 BC = 25 ns) and does not wait for anything but it may get to complicated at this level of understanding.) Familiar scheme related to the example:

TRD --------L0trginp------> CTP ------L0sig------> LTU_tpc ----> TPC
TRD --------L1trginp------> CTP ------L1sig------> LTU_tpc ----> TPC
TRD --------L2trginp------> CTP ------L2sig------> LTU_tpc ----> TPC

or with only one L0 trigger input (more often scenario during ALICE tests so far)

TRD --------L0trginp------> CTP ------L0sig------> LTU_tpc ----> TPC
after 6.5 μs CTP ------L1sig------> LTU_tpc ----> TPC
after ~100 μs CTP ------L2sig------> LTU_tpc ----> TPC

This is often confusing for newcomers and it is worth to be repeated: signals from triggering detectors to CTP are called L0, L1 and L2 trigger inputs, the signals from CTP to readout detectors are called simply L0, L1 and L2 signals (or sometimes trigger or trigger signals).

Classes and clusters

Classes define how CTP inputs are configured and clusters define how CTP outputs are configured. The classes and clusters are software extension of the inputs to the trigger (triggering detectors) and outputs to the trigger (redout detectors). So far we had one example of one L0 one L1 and one L2 trigger input from one detector (TRD) and output to one readout detector (TPC). To be more efficient we can group triggering detectors (make classes) and have more than 1 trigger input and group readout detectors (make cluster) and have more than 1 detector measuring the event. The advantage is that while the slow detectors (like TPC) are processing some event - during that time another fast detectors (like SPD) can process other events. The total number of classes can be 50 and total number of clusters can be 6. Those numbers are related how they (classes and clusters) are implemented in the hardware. Examples of classes and clusters:

1 class (1 L0 trigger input SPD) ------> CTP ------> 1 cluster (TPC)

Class represented by one L0 trigger input.

1 class (1 L0 trigger input SPD + 1 L0 trigger input V0) ------> CTP ------> 1 cluster (TPC)

Between SPD trigger input and V0 trigger input should be a coincidence, i.e. signals from those two triggering detectors must arrive at the same BC to CTP otherwise no L0 signal will be generated!

1. class (1 L0 trigger input SPD) ------> CTP ------> 1. cluster (TPC)
2. class (1 L0 trigger input V0) ------> CTP ------> 1. cluster (TPC)

So we have two classes associated with the same cluster. Now at least one class has to fire to generate L0 signal and to be sent to the cluster.

1. class (1 L0 trigger input SPD) ------> CTP ------> 1. cluster (TPC)
2. class (1 L0 trigger input V0) ------> CTP ------> 2. cluster (TOF, TRD)

Two classes two clusters. Note: you can not have one class associated with two clusters! (But you can clone that class to have two same classes for 2 clusters - remember we have 50 classes implemented in the hardware and only 6 clusters).

Classes are not represented only by trigger inputs. There are more settings associated with the class like for instance BC mask or Past-Future protection (these will be mentioned in Vetoes section) or some others. In general class defines all trigger input settings.


What are the reasons when the L0 signal is not generated (CTP decides for some reasons (vetoes) the collision will be ignored)?:

  1. Cluster busy - at least one detector in the cluster is busy (for instance the TPC has an multi-event buffer, i.e it can readout more than one event, but if this buffer is full the TPC sends a busy signal to the trigger - it means: Do not send me another trigger signal I do not have a memory to read it!)
  2. Past-Future protection - if for example time between two central lead-lead collisions is smaller than TPC drift time it would lead to an unreconstructable mess in TPC. To get a rid of those pile-up events at the online level the Past-Future protection was developed. So if there are some critical number (depending on Past-Future protection settings) of other events in some past or future time interval of the actual event - such event is not taken for the triggering.
  3. DAQ busy - can be set by software any time
  4. CTP busy - DAQ problem (overloaded by data, computers restarted...)
  5. CTP deadtime - when L0 trigger input arrives CTP cannot process another L0 trigger input in next 1.6 μs
  6. Test Class L0 - when calibration (software) trigger arrives at same BC as L0 trigger input
  7. BC Mask - we can define "valid BCs" in the orbit by setting BC mask. If we do not expect to have a trigger in this BC we will ignore that event
  8. Class Mask - check if the L0 trigger input is associated with the active class
  9. All/Rare - sometimes a very rare event is overwhelmed by ordinary events i.e. detectors are busy with some ordinary event and must ignore rare event. Each class can be sensitive to that.

For L1 and L2 signal the only veto (apart from no L1 and L2 trigger input if there are set any) is Past-Future protection.

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 18 Dec 2008 - _47DC_61ch_47DC_61cern_47OU_61Organic_32Units_47OU_61Users_47CN_61mbombara_47CN_61555683_47CN_61Marek_32Bombara?
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback