350 likes | 365 Views
The ALICE Central Trigger Processor. D. Evans 1 , S. Fedor 2 , G.T. Jones 1 , P. Jovanov ić 1 , A. Jusko 1 , I. Kr á lik 2 , R. Lietava 1 , L. Šá ndor 2 , J. Urban 3 , and O. Villalobos Baillie 1 for the ALICE collaboration. O. Villalobos Baillie University of Birmingham
E N D
The ALICE Central Trigger Processor D. Evans1, S. Fedor2, G.T. Jones1, P. Jovanović1, A. Jusko1, I. Králik2, R. Lietava1, L. Šándor2, J. Urban3, and O. Villalobos Baillie1 for the ALICE collaboration. O. Villalobos Baillie University of Birmingham LECC Heidelberg Sept 2005 • School of Physics and Astronomy, The University of Birmingham, Birmingham, UK • Institute of Experimental Physics, Slovak Academy of Sciences, Košice, Slovakia • P.J. Šafárik University, Košice, Slovakia
Plan of Talk • CTP Requirements • Running conditions • Special features (e.g. p/f , rare events) • Chosen characteristics • CTP Design • Description of system and common features of boards. • Status • LTU Review • Main characteristics and tests • Test beam summary • Software • Framework • Examples • Summary O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
ALICE Running Conditions • The ALICE experiment aims to run in several different modes, both ion-ion and pp, giving very different requirements for multiplicity and rate. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
CENTRAL TRACKER ● pixel ● Silicon Drifts ● Silicon Microstrips ● TPC ● TRD ● TOF HIGH multiplicity tracking, Overall rate relatively low (TPC) HIGH data output DIMUON TRACKER ● absorber ● Tracking chambers ● Trigger chambers HIGH rate LOW(er) data output O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Trigger Requirements • The ALICE Central Trigger Processor (CTP) must balance these requirements. For example… • Protect against pile-up when two central Pb-Pb events are superimposed [past-future protection] • Allow higher trigger rates for (e.g.) dimuon arm, which can run faster than central section and requires higher rates for physics [dynamic partitioning] • Ensure that some part of the DAQ bandwidth is reserved for rare events, over and above data traffic for normal events [rare event handling] O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
CTP Specification • 3 Trigger levels: • L0 inputs up to 800 ns; delivered to detector 1.2 μs from interaction; • L1 inputs to 6.1 μs; delivered to detector 6.5 μs from interaction; • L2 delivered to detector 88 μs from interaction. • 60 inputs • L024; L124; L212. • 6 partitions (clusters). • 4 past/future protection circuits. • 4 bunch crossing masks; 2 random triggers; downscaling. • Rare-event handling; interaction recording. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Trigger Classes and Logic • A trigger class consists of • A set of trigger inputs • A defined trigger output cluster • Specification of past-future protection, rare-event handling, downscaling, RoI handling. • TRIGGER LOGIC • It was found that almost all ALICE triggers require only AND logic • 44 classes allow only AND • classes also allow complement of input to be required • In addition, for 4 chosen inputs, a look-up table allows arbitrary logic • functions to be specified (e.g. to define INTERACTION). The result • of this logic can be used as an additional trigger input. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
CTP Data • Trigger data are sent as TTC broadcasts with both L1 and L2 triggers • L1 message: calibration flag; readout control bits(4); segmented readout flag; L1 software class flag; L1 active trigger classes (50). • L2 message: bunch crossing ID(12); orbit ID(24); calibration flag; L2 software class; L2 cluster mask (6); L2 active trigger classes (50). • The same data is kept by the DAQ on the trigger LDC. • In addition, the trigger sends to the DAQ an interaction record, indicating for each orbit which bunch crossings gave an interaction (whether triggered or not) and its multiplicity classification (peripheral or semi-central). This is used for • Past-future protection checks • Evaluation of secondary vertices in reconstruction. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
events e1 triggers e2 triggers e1 e2 L0 L1 L2 L0 L1 Past-Future protection I TPC drift time past/future protection interval • Programmable width 200 s • Programmable number of permitted interactions (up to 32) in 1 interval • 2 interaction inputs – low/high multiplicity events are recognised • Pb-Pb: pile-up is avoidable, several ‘piled-up’ peripheral events allowed, but only 1 central event. • p-p: pile-up is unavoidable, large number of events are tolerated in TPC, but only few events in ITS O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Past-Future Protection II • Each logic block set with moving time window of length ΔTA/B, with thresholds on the number of interactions inside time window. • In ion-ion mode, block A checks for (semi)-central events (NO pile-up), block B for peripheral events (some pile-up tolerated) • In pp mode, both blocks use MB interaction; different thresholds set for TPC (wide pile-up tolerance) and ITS (restricted pile-up tolerance). O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
‘Rare’ events: simulation • In order to study event flow in ALICE, a generic model was developed (L. Musa; T. Anticić et al.) allowing study of events, controlled by trigger/DAQ protocols, from FE to main DAQ. • Study showed that without care, trigger rates for frequently ocurring triggers would dominate DAQ, meaning bandwidth was always saturated when a rare trigger arrived. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
‘Rare’ events - solution • Solution is to use software signals from DAQ to flag when buffers are close to full, and at this point only allow trigger classes flagged as rare. (Sometimes not so rare.) • When buffers have emptied sufficiently, non-rare classes are again enabled. • Scalers have to be chosen so as to allow correct book-keeping for this on-off of non-rare triggers. Checked to be OK. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Design of Boards • The CTP electronics has been designed to fit onto 6 different kinds of 6U VME boards. • Trigger inputs are LVDS • A special J2 backplane transfers signals from one board to the next. • Outputs are sent to Local Trigger Units (LTUs) where conversion to output format occurs. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Typical CTP board Layout • L0 board • ALTERA EPM3512 FPGA for VME control, close to J1 connector • ALTERA CYCLONE EPIC20 FPGA for main logic • On-board flash memory (Am29LV081) loaded through VME • 1 Mword 32 bit word ‘snapshot’ memory (2 CY7C1382 ICs) • PCF8591 ADC for readout of voltages and fuse status via I2C. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
32 SCL 31 SDT 2 2 I C control bus 1 I C control bus 2 30 29 28 27 CTP BUSY 26 Interaction 1 25 Interaction 2 24 Strobe L2 Data 23 Strobe Data 1 Class L0 22 Data 2 Data Strobe 21 Cluster Class L1 BUSY 20 Data 19 18 17 Cluster L1 16 15 14 13 12 11 10 9 Cluster L0 8 7 6 5 Pre - pulse 4 ScopeProbe A 3 ScopeProbe B 2 Orbit 1 BC BUSY L0 L1 L2 FO1 FO2 FO3 FO4 FO5 INT FO6 1 2 3 4 5 6 7 8 9 10 11 Signal source Common ground connection Cluster signal groups Signal destinati on Serialised link, data and strobe line, 40 MHz 2 Bus termination I C control bus, clock and serial data CTP backplane O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
32 32 32 32 32 32 32 32 32 32 32 1 1 I2C2 I2C1 20 20 20 20 20 20 20 20 20 20 20 GND GND 10 10 10 10 10 10 10 10 10 10 10 (50µm thick) SMD resistor (100Ω, size 0603) Ground plane Kapton foil (100Ω diff. pairs) Rigidiser LVDS pair - LVDS pair + Not connected 10-pin IDC connector Tracks Ground BUSY L0 L1 L2 FO FO FO FO FO FO INT I2C signal 1 1 1 1 1 1 1 1 1 1 C A C A C A C A C A C A C A C A C A C A C A 75 μm double sided copper-clad Kapton film: signals transmitted as LVDS pairs. (CERN, SCEM 09.55.05.609.6) (CERN, SCEM 09.61.33.610.3) DIN41612 connector, a+c O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Current Status • Boards were designed at Birmingham and built through RAL. • All but one of the boards (plus backplane) now built. • Final tests starting at Birmingham prior to shipping to CERN early 2006. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Local Trigger Unit (LTU) • Described in detail last year. • Serves as interface between CTP and detectors. • Produces detector specific signals (LVDS and TTC controls) which are then sent to detectors • Can also emulate all CTP functions so as to produce a full ALICE-like environment. • Accepts external input for use with test beam. • 53 LTUs built, some for ALICE experiment, some for detector groups for development work. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
ITS Beam Test 2004 • At the end of 2004, a system of three LTUs was used to provide triggers to a system of three ITS detectors (Pixels, Silicon Drifts, Microstrips) running together in a test beam. • The trigger was integrated with the other ALICE control systems (DAQ, DCS, ECS) all of which worked well. • A run of 5 ´ 106 triggers was recorded with all three detectors under stable conditions. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Software • Software development is essential to operate the trigger. • The software framework for the trigger was agreed in 2003 • Main programming language: C • Interface to ECS: SMI++ and DIM • Graphical interface: Python/Tk and Tcl/Tk • Monitoring: use ALICE AFFAIR package where possible (implies use of ROOT). O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Example 1: LTU Emulation • Example shows: • Main menu • Scalers • Snapshot control • Snapshot dump • Emulation editor for embedded errors. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Example 2: CTP Control • Example shows: • ‘shared resources’: available bunch crossing masks, random triggers etc. • Available trigger ‘descriptors’ (i.e. trigger input sets) • Definitions of two classes, with trigger descriptors and output clusters. • Details (i.e. p/f definitions, use of shared resources) for one of these • HELP facilities (built up as software is developed.) O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Example 3: AFFAIR monitoring • AFFAIR monitoring of VME processor running CTP control in Birmingham, monitored from Košice and published on web. • Further functions under development. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Summary • CTP specification has evolved in response to the specific requirements of ALICE, rather different from those of other LHC experiments. • Careful study has allowed design to be based on 6U VME boards and backplane • Logic handled on FPGA loaded via flash memory. Makes upgrades easy to implement and distribute. • Software has developed in parallel, making use of similar tools to other ALICE control systems where possible • ITS combined test beam 2004 was a major milestone and demonstrated that the trigger system can be integrated with detectors and control systems • CTP hardware now almost all ready. Commissioning at CERN starts early next year. O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
events e1 triggers e2 triggers e3 triggers L2 L1 e1 e3 L0 e2 L0 L1 L0 L2 L1 s 1.2 6.5 88 Trigger protocol e2 signals not generated by CTP, information is kept only in Interaction record L1 rejection: L1 is not generated(no explicit reject message) L2 rejection: There is always L2 message (L2accept or L2reject) Earliest time for next L0 is at the time of L1 (on the LTU output), i.e. no L0 between L0, L1 for 1 detector O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
LTU board O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
LTU block diagram O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Front-panel connectors Backplane connector J2 RoI interface CTP LTU emulator Mode Enable BUSY1 BUSY1 Enable BUSY2 LTU BUSY2 Testbeam setup Simplified block-diagram of LTU from/to CTP • RoI output signals are used for feeding of the next LTU • 2 BUSY inputs of 1 LTU can be used to combine BUSY from 2 detectors (common BUSY) from detector O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
Testbeam setup CTP Test-beam trigger (PULSER input) LTU emulator Stand-alone Enable BUSY1 BUSY1 Sub-detector 1 Enable BUSY2 • Thanks to programmability of busy logic and LTU Mode, any LTU can become Master (CTP emulator) by simple reprogramming of LTUs • If trigger is connected to all the LTUs, the exclusion of any detector is possible without recabling • Advantage: all three LTUs operate together, without additional hardware. • If > 3 LTUs, recabling necessary for some configurations BUSY2 LTU CTP LTU emulator Global Enable BUSY1 BUSY1 Sub-detector 2 Enable BUSY2 BUSY2 LTU CTP LTU emulator Global Enable BUSY1 BUSY1 Sub-detector 3 Enable BUSY2 O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005 BUSY2 LTU
CTP emulation • Together with selector, LTU can run in STANDALONE mode, presenting the same FE interface as in GLOBAL mode • 7 legal sequences • Programs of max. 32 sequences are prepared in emulator memory. L1 and L2 data are fully programmable • Sequence execution triggered by Start signal derived from BC scaled down, random generator, external pulser or software request • Error prone flag enables programmable random errors in STANDALONE mode with chosen sequences in order to allow the FE electronics testing for error recovery • Errors on demand can be generated in both modes O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
LTU sequences Possible sequences: L0 L0 - L1 - L2a (DAQ) L0 - L1 – L2r PP PP – L0 PP – L0 – L1 – L2a (DAQ) PP – L0 – L1 – L2r Error-prone sequences: L0 - L1 - L2a PP – L0 – L1 – L2r - O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
ECS for ITS O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
ECS – Screen shot All together O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005
ECS – Screen shot SDD and SSD O. Villalobos Baillie - 11th LECC Workshop - Heidelberg 2005