march 25 th 2003o. villalobos baillie – lhcc comprehensive review 1 the alice central trigger...

March 25th 2003 O. Villalobos Baillie – LHCC Comprehensive Review 1

The ALICE Central Trigger Processor

O. Villalobos Baillie

University of Birmingham

CERN March 25th 2003LHCC Comprehensive Review


PLAN OF TALK• INTRODUCTION

• RESOLUTION OF “REMAINING ISSUES”– Use of Vetos

– Past-Future Protection

– Evaluation of Cross Sections

– Handling of Rare Triggers

• TRIGGER SIMULATION

• TRIGGER SOFTWARE FRAMEWORK

• THE LOCAL TRIGGER UNIT (LTU)

• FUNDING AND STAFFING ISSUES

• SUMMARY


General layout of the ALICE CTP I

• The ALICE CTP consists of a number of 6U VME boards, which will go in a single crate.

• It will be surrounded by a number of Local Trigger Crates, where trigger signals are prepared for fanning out to individual detectors.

• The trigger installation also serves as the point from which the LHC clock signals are fanned out, using the TTC system.


General layout of the ALICE CTP II

RB 24RB 24

• The position of the CTP racks is now agreed.

• CTP racks will be placed underneath the dimuon trigger chambers.

• The implications of this for cable lengths have been studied.

Trigger racks Trigger racks go herego here


Recent History• The scope and functions of the trigger were greatly

increased after CR1 in 2001.• One year ago, the broad framework for the Central

Trigger Processor (CTP) had just been agreed through the approval of the User Requirement Document.

• This gave the green light for more detailed development of the Local Trigger Unit (LTU), which needs to be produced soon.

• A few issues remained to be defined regarding the functions of the CTP itself.


The “Remaining Issues”

• Use of Vetos– The original URD specified that for each class it

would be possible to specify three states for each input: required, “must-be-absent”, and “don’t care”.

– The extra condition (explicit “no”) had to be allowed for all 50 inputs for 50 classes; an extra 2500 control bits for the CTP.

– There are NO physics classes requiring the explicit “no” on the proposed list of classes.


No. Description Condition

1 MB [T0.V0MB.TRDpre]L0[ZDC1]L1

2 SC [T0.V0SC.TRDpre]L0[ZDC2]L1

3 CE [T0.V0CE.TRDpre]L0[ZDC3]L1

4 DMunlike high pT.TPC.MB [T0.V0MB.DMunlike high pT.TRDpre]L0[ZDC1]L1

5 DMunlike high pT.TPC.SC [T0.V0SC.DMunlike high pT.TRDpre]L0[ZDC2]L1

6 DMunlike high pT.no TPC.MB [T0.V0MB.DMunlike high pT]L0[ZDC1]L1

7 DMunlike low pt.no TPC.MB [T0.V0MB.DMunlike low pT]L0[ZDC1]L1

8 DMunlike low pT.no TPC.SC [T0.V0SC.DMunlike low pT]L0[ZDC2]L1

9 DMlike high pT.TPC.MB [T0.V0MB.DMlike high pT.TRDpre]L0[ZDC1]L2

10 DMlike high pT.TPC.SC [T0.V0SC.DMlike high pT.TRDpre]L0[ZDC2]L1

11 DMlike high pT.no TPC.MB [T0.V0MB.DMlike high pT]L0[ZDC1]L1

12 DMlike low pT.no TPC.MB [T0.V0MB.DMlike low pT]L0[ZDC1]L1

13 DMlike low pT.no TPC.SC [T0.V0SC.Dm like low pT]L0[ZDC2]L1

14 DMsingle.TRDe.MB [T0.V0MB.Dmsi.TRDpre]L0[TRDe.ZDC1]L1

15 DMsingle.TRDe.SC [T0.V0SC.Dmsi.TRDpre]L0[TRDe.ZDC2]L1

16 TRDe.MB [T0.V0MB.TRDpre]L0[TRDe.ZDC1]L1

17 TRD low pT.MB [T0.V0MB.TRDpre]L0[TRD low pT.ZDC1]L1

18 TRDhigh pT.MB [T0.V0MB.TRDpre]L0[TRDhigh pT.ZDC1]L1

19 TRDunlike high pT.MB [T0.V0MB.TRDpre]L0[TRDunlike high pT.ZDC1]L1

20 TRDunlike high pT.SC [T0.V0SC.TRDpre]L0[TRDunlike high pT.ZDC2]L1

21 TRD like high pT.MB [T0.V0MB.TRDpre]L0[TRD like high pT.ZDC1]L1

22 TRD like high pT.SC [T0.V0SC.TRDpre]L0[TRD like high pT.ZDC2]L1

23 TRD jet high pT.SC [T0.V0SC.TRDpre]L0[TRD jet high pT.ZDC1]L1

24 TRD jet low pT.MB [T0.V0MB.TRDpre]L0[TRD jet low pT.ZDC1]L1

25 TRD jet low PT.SC [T0.V0SC.TRDpre]L0[TRD jet low pT.ZDC2]L1

26 PHOShigh pT.MB [T0.V0MB.PHOShigh pT.TRDpre]L0[ZDC1]L1

27 PHOS low pT.MB [T0.V0MB.PHOS low pT.TRDpre]L0[ZDC1]L1

28 PHOS low pT.SC [T0.V0SC.PHOS low pT.TRDpre]L0[ZDC2]L1

29 PHOS standalone [T0.V0MB.PHOSMB]L0[ZDC1]L1

30 EMCAL jet high pT.MB [T0.V0MB.EMCAL jet high pT]L0[ZDC1]L1

31 EMCAL jet med pT.MB [T0.V0MB.EMCAL jet med pT]L0[ZDC1]L1

32 EMCAL jet low pT.MB [T0.V0MB.EMCAL jet low pT]L0[ZDC1]L1

33 EMCAL jet low pT.SC [T0.V0SC.EMCAL jet low pT]L0[ZDC2]L1

34 ZDCdiss [BX]L0[ZDCspe]L1

35 cosmic [BX.cosmic_telescope]L0

36 beam gas [T0beamgas]L0

This list of classes is a first estimate of what will be needed for Pb-Pb running. It does not contain any negated inputs, and uses only the AND operation.


The “Remaining Issues”• Use of Vetos

– The original URD specified that for each class it would be possible to specify three states for each input: required, “must-be-absent”, and “don’t care”.

– The extra condition (explicit “no”) had to be allowed for all 50 inputs for 50 classes; an extra 2500 control bits for the CTP.

– There are NO physics classes requiring the explicit “no” on the proposed list of classes.

–Only useful for setting up (to check what is excluded) and possibly diagnostic tests.

O. Villalobos Baillie – Proposal for the Use of the “Explicit No” in Trigger Conditionshttp://www.ep.ph.bham.ac.uk/user/pedja/alice/veto.ps

EQUIP 6 classes only.



• Past-future protection in Pb-Pb interactions is mainly aimed at avoiding having two overlapping central events. Protection time windows differ for different detectors.

• In pp running, where luminosities are higher, pile-up is inevitable, but can be tolerated because multiplicities are much lower. Here the important parameter is to count how many overlapping events there are.



• Decisions– 4 independent past-future protection circuits, to be

associated with clusters (not classes).– Logic of circuit accepted.– Maximum programmable overlap threshold 64.

D. Evans Proposal for Past-Future Protection Handling in ALICEhttp://www.ep.ph.bham.ac.uk/user/pedja/alice/pf-prop.ps


The “Remaining Issues”• Cross section evaluation was one of the

issues governing the choice of scalers.

– We should measure cross sections (with total cross section norma-lization) using available scalers.

– This should be done with un-impaired statistical accuracy without unnecessary scalers.

• For each class, existing scalers follow the triggers surviving each reduction.

• Careful evaluation, by simulation and analytic evaluation, shows these can be used with optimal statistical accuracy for running times of more than a few seconds.

See R. Lietava and O. Villalobos BaillieCross section measurement in heavy ion collisions at ALICEhttp://www.ep.ph.bham.ac.uk/user/pedja/alice/cross_section.ps


• Rare Triggers. The application of many trigger classes running concurrently in ALICE raises a problem for ensuring that all get a reasonable share of the available luminosity.

• This is a complicated issue which needs to be checked in detail, taking into account detector buffer sizes, past-future protection, clearing response times, and response of DAQ.

• All these things have been studied in terms of a detailed detector data transfer simulation developed for this purpose in collaboration with DAQ group.



Detailed Trigger Simulation• There have been several approaches tried over the years to

simulate the response of the ALICE detector to varying rates of triggers.

• Recently, a new and powerful approach based on the Berkeley PTOLEMY package has allowed a fast and detailed simulation.

• The scope of the simulation includes the reaction to triggers, the data traffic in the front-end buffers, and the subsequent transfer of data in the Data Acquisition system. (T. Antičić et al. Trigger and DAQ Simulation, ALICE-INT-2003-001-v1)


Front End Model

• A generic model of the front-end electronics for each detector was developed, and parameters collected from each detector group. (L. Musa Presentation to ALICE Technical Board, September 2002.)

• This, in conjunction with timing information supplied by the detector groups, is the basis for the trigger model.

• In addition the basic characteristics of the interaction (multiplicity) is modeled, allowing the data volume distribution to be modeled for use in the DAQ simulation.

DET L0–DL L1–DL L2–DL F2D-DLL0SEB

L0MEB

L1SEB

L1MEB

L2SEB

L2MEB

RORC

L0 L1 L2


Results

.

•In order to simulate Pb-Pb running with competing frequent and rare triggers, a case with three triggers, Minimum Bias, dielectron and dimuon, was set up.

•It was found that the bandwidth for rare triggers could be protected if “high-” and “low-water marks” for occupancy were monitored on the LDC/FEPs, and common triggers only enabled when the buffer space used was below the high water mark. Re-enabled when occupancy goes below low-water mark again.

Dynamic disabling of common trigger classeswhen buffer space is almost used up.


CTP Software

• The framework for the CTP software was discussed at a three day workshop held in Birmingham in April 2002.

• This was followed up with two day meeting in Košice in October 2002, where details of the control structure were discussed in more detail.


Basic Decisions Made

• Compatible with ECS Run Control– Human interface: Tcl/Tk and/or Python/Tk– Communication: DIM– Control: SMI

• Documentation: – LaTeX, MS Word published as postscript– Figures published in postscript

• Software tools– Code accessing CTP Hw: C/C++


Computing Infrastructure

TT

Cvi

LTC

CLT

U

TT

Cex

TRGLDC

RO

RC

CT

PC

CT

P

CTP boards

CTP crate LTU crate (6x)

TTC partition (4x)

DAQ Network

controlmonitoringDDL


CTP Readout (1)• Event data (For every L2A)

– 8 words (L2a message content) from CTP to TRG LDC– Over DDL (SIU as mezzanine card of 1 of the CTP boards)– Contribution from CTP to event-building

• Interaction records– Header with:

• Orbit number (for every orbit)– List of records containing:

• Bunch crossing with MB interaction and centrality flag (MB/SCE)– buffer overflow is acceptable; error flag is added at end of record.– Sent for each orbit over DDL


CTP Readout

DAQ Network

GDCGDC GDC GDC

TRGLDC/FEP

TRG CTP

DDL

RORCDDL DIU

DDL SIU

L2Board

B2TRGCTPSBC

VME

CTPCTRL

CTPMon. Tx

CTPMon. Rx

DATEReadout

LAN / DIM

DATERecorder

Event Data,Interaction data

EORRecord

B2OtherBoards

CTP Readout


Trigger Monitoring

• Monitor of CTP scalers and timers– Periodic process compatible but independent from

DAQ Performance Monitoring– Consider AFFAIR package

• Snapshots of CTP– Collected over LAN and processed on monitoring

computer

• Error messages submission and handling: – Should be compatible with DATE/ECS facility


Trigger Monitoring

TRGLDC

TRG CTP

TRGCTPSBC

VME

CTPCTRL

CTPMon. Tx

CTPMon. Rx

LAN / DIMAFFAIRServer

TRG Rates performances

RoundRobin DB

ROOTDB

ROOTPlots

ROOTPlots

for Web

Scalers monitoring

CTPSnapshot

LAN / DIM

DAQ at EOR


Trigger Control Software Implementation

• Basic structure uses SMI for– Synchronization with external tasks (Partition

Control Agent),– Keeping CTP internal tasks in consistent state.

• Development is a result of ongoing discussions with ECS group. We have basic plan for trigger structure.


Trigger objects

TriggerClass1

Trigger

TDetector1

DetectorCluster1

LTU1

TriggerClass2 TriggerClass50

DetectorCluster2 DetectorCluster6

TDetector2 TDetector10

LTU2 LTU3 LTU4 LTU24

...

...

...

...

proxy:

proxy:


TriggerDB and Trigger SM

TRGDB

DB editor

LOAD

UIRTLDetector ClusterX

Detector Cluster SetX

UIRTL

Operator GUI

when any_inwhen all_in...each insert/remove is

represented by 1 action, i.e.~ 50*(1+10)+6*24 actionsin total in TriggerSM

TriggerSM


VME board testing and configuration

Board configuration

file compilerBoard.h Board.c vmedef.c

cc

Command lineInterface for testingGUI.py popen

•GUI separated from VME application (and can run on separate computers)• this way of programming was already used for 2 real VME boards (TTCvi, JTAG-Ke)• platforms (tested with TTCvi board):

• Motorola SBC, AIX (in Birmingham)• PC + NI-VXI, W2000 (in Košice)

User.py


TTCvi control (gui)


Trigger Software – next steps

• Trigger GUI for CTP states

• Full definition of LTU domain (in progress)

• LTU software for standalone mode• Testing

• Configuration

• GUI


LTU Preliminary Design Review

• The Local Trigger Unit (LTU) proceeded to a full description in the summer of 2002.

• After a period of discussion a Preliminary Design Review was held at the beginning of October 2002, with participation from ALICE members and two external referees (Thorsten Wengler – ATLAS, and Richard Jacobsson – LHCb). The document was approved.

• Following the review, detailed work on the schematic capture for the board has begun, and will be presented in the near future.


LTU Context Diagram

• The LTU performs the transmission of signals from the CTP to a given detector (where appropriate via the TTC).

• It is placed in a Local Trigger Crate, with four detector partitions per crate.

L2 Data

L1

BC

L1 Data

L0

LTU Orbit

Pre-pulse

TTCvi Orbit

Pre-pulse

L1

BC BC

A

B

TTCex

TTCcf

BC BC

TTCit

320

1

TTCrx

L0

L0

BUSY

Local pulser

Sub-detector readout electronics

Sub-detector TTC partition

CTP TTCmi

Orbit

BUSY

L2 Strobe

Control Processor (VME)

- Control - Monitoring

VMEbus

BU

SY

bo

ard

VM

E s

lave

VM

E m

aste

r

FA

N-O

UT

bo

ard

to F

IFO

- L1 Message - L2r Word - L2a Message


Region of Interest Context Diagram

• The LTU has been designed to take into account the provision of a future Region of Interest (RoI) option.

• Only a few detectors in ALICE have expressed interest in readout by sectors as proposed here.

• RoI can, however, be useful as input for the HLT.

LTU TTCvi TTCex

VMEbus

Ll

Sub-detector TTC partition

L0

L2

DAQ Sub-detector electronics

TTCrx

RORC DDL

L0 L1 L2a L2r

CTP

RoII

L1 Strobe

RoIP

RoI Data

RoI

inpu

ts

CT

P in

puts

L1 Data


LTU Modes

• The LTU can be programmed to receive signals from the CTP, in which case it retransmits them, suitably re-encoded, to the TTC system.

• It can also be used in standalone mode. In this case, the CTP is replaced by a programmable sequence emulator, allowing pre-programmed sequences of triggers to be delivered.


Mode

Local BUSY

CTP

CTP emulator

BUSY logic

Selector

Emulated inputs

LTU logic

LTU inputs

External inputs

Mode Snap-shot memory

Monitoring counters

(to RoII)

LTU outputs

(to TTCvi/TTCex)

(to TTCvi)

Backplane copy

VME outputs

BUSY output

(to CTP)

BUSY input

FAN-OUT board

Block Diagram of the LTU


Sequence name Sequence structure Sequence code

L0 sequence L0 1

L2a sequence L0 - L1 - L2a 2

L2r sequence L0 - L1 - L2r 3

Calibration Pre-pulse sequence Pre-pulse 4

Calibration L0 sequence Pre-pulse - L0 5

Calibration L2a sequence Pre-pulse - L0 - L1 - L2a 6

Calibration L2r sequence Pre-pulse - L0 - L1 - L2r 7

List of valid emulation sequences

It is also possible to program invalid sequencesto test error detection logic.


Definition of LTU sequences

• A format exists for defining all the trigger messages and codes for each trigger in a sequence

• An editor will be developed to allow easy coding of sequences.

Word Bit Data

15 ClT

14..11 RoC[4..1]

10 ESR

9 L1SwC

8..7 L1Class[50..49]

6..5 Spare

4 Last

3 Restart

Word 0

2..0 SCode[2..0]

Word 1 15..0 L1Class[48..33]

Word 2 15..0 L1Class[32..17]

Word 3 15..0 L1Class[16..1]

15 L2arF

14 ClT

13 L2SwC

12..7 L2Cluster[6..1]

Word 4

6..0 L2Class[50..44]

Word 5 15..0 L2Class[43..28]

Word 6 15..0 L2Class[27..12]

15..5 L2Class[11..1]

Word 7 4..0 Spare


1st sequence

2nd sequence

Last

1st sequence

2nd sequence

Last Restart

1st sequence

2nd sequence

Restart

Last Restart

1st sequence

2nd sequence

Restart

Last (a) Single pass (b) Continuous loop (c) Extended continuous loop (d) Extended loop variation

(a) (b)

(c) (d)

Generation of “super-sequences”


Generation of sequence START signal

• Several possibilities exist for starting a super-sequence

• These can be– A software signal– An external pulser (can

be external trigger) –useful for test beams.

– A random trigger– A scaled down BC clock


Funding and Staffing Issues

• Section on trigger from CRII report:– Finally, the Committee noted that due to an anticipated reduction in the

funding from the UK, re-organization of the Central Trigger project is in progress.

• One year on, we report on the outcome of the expected budget cuts and the organization of the project.


Outcome of U.K. Budget Reductions (SCP4)

• Expenditure on ALICE tightly constrained by Memorandum of Understanding, which was already signed.– CTP CORE expenditure maintained.– DAQ CORE expenditure (RORC costs) 10% cut.– RAL Electronics group support 75% cut, absorbed by rest of

collaboration (shift of bulk of production to Slovakia).– Travel. In principle a substantial cut, but reviewed year-by-

year.

• We are able to continue.


• Although it has not (yet) proved possible to enlarge the trigger group, the Birmingham and Košice teams have consolidated over the past year.– Birmingham: D. Evans, P. Jovanović, J.B. Kinson,

R. Lietava, O. Villalobos Baillie, and new post.– Košice: S. Fedor, A. Jusko, I. Králik, (M. Krivda),

and J. Urbán. (Electronics engineer Software engineer

)

Size of Trigger Group


Chronology

Date Item

February 22nd 2002 URD acceptedMarch 20th 2002 L1 data format accepted

Layout and connections for CTP acceptedApril 24th-26th 2002 3 day trigger software workshop in BirminghamMay 14th 2002 L2a data format accepted

Region-of-Interest handling acceptedJuly 15th 2002 CTP data readout and interaction record acceptedOctober 3rd-4th 2002 2 day meeting in KošiceOctober 10th -11th 2002 LTU Preliminary Design ReviewNovember 26th 2002 Past-Future Protection proposal acceptedDecember 16th 2002 Proposal for use of scalers in cross section measurement

Rare Trigger handlingMarch 10th 2003 Model for SMI structure for CTP presented in ALICE week.


Next Steps

• 2003 will be dedicated mainly to – the the delivery and commissioning of the Local

Trigger Unit (hardware/software) [November 2003],

– The Preliminary Design Report for the full Central Trigger Processor [July 2003], and

– The writing of the Trigger/DAQ Technical Design Report [December 2003].


LTU Milestones

DONE

DONE

Shifted MAY 2003to allow tests of cables


CTP Milestones

DONE


Summary• There has been substantial progress in the last year,

and the financial framework has re-stabilized.• The conceptual uncertainties for the CTP and the LTU

have been resolved.• The design for the LTU is in progress• The software framework for the experiment has been

established, and the first development steps taken.• We have a detailed simulation of the response of the

trigger and DAQ, which is already proving useful for checking the feasibility of different trigger operating modes.

march 25 th 2003o. villalobos baillie – lhcc comprehensive review 1 the alice central trigger...

Documents