Electronics / Trigger / DAQ considerations Gregory Dubois-Felsmann SLAC SuperB Workshop16-18 March...

Electronics / Trigger / DAQ considerations

Gregory Dubois-FelsmannSLAC

SuperB Workshop16-18 March 2006

2006.3.17 SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann

2

Time structure is the key

• Entire electronics / trigger / DAQ design depends on: – Interval between crossings; continuous or in trains?– Interval between luminosity-driven interactions– Probability of overlap

• In the same crossing• Within the detector response time

• Choices– Electronics:

• Response times• Known-T0 shaping/filtering vs. peak-finding• Number of channels depends on detector technology choices

– Especially the possibility of an all-silicon tracking system

– Trigger:• Beam-crossing-driven vs. data-driven

– DAQ: • Pipeline design depends on minimum possible interval between triggers,

probability of overlap between readout frames


3

0.1-1 MHz design approaches nirvana

• Electronics– Easy to achieve no significant overlap between events from

different crossings– Little pressure to go to very fast detector response times

• Waveform sampling doesn’t need to be any faster than for BaBar• Except possibly in calorimeter endcaps

– Precise knowledge of T0 simplifies shaping/filtering, improves noise rejection

• Trigger– Trigger decision needs to be evaluated only once per crossing

• 0.1-1 MHz rate - c.f. BaBar 4/8 MHz

• DAQ– Nonoverlapping readout frames: straightforward pipeline– Maximum instantaneous trigger rate is limited - queuing problems

reduced


4

Almost nirvana

• Simultaneous interactions are main remaining problem– Bhabhas: 50-5% probability of coincidence– Single-particle backgrounds from QED, 2-photon processes not yet

evaluated• Possibly troublesome background for recoil-based analyses

• Needs some very simple MC tests to evaluate

– Nothing can be done about this at E/T/D level: it’s a problem for reconstruction


5

Yesterday’s developments

• Latest Raimondi and Seeman parameter sets envision essentially continuous collisions at ~500 MHz

• Consequences:– Luminosity per crossing goes way down vs. low-rate models:

very little chance of a problem with simultaneous interactions– More of a problem with overlapping (but not simultaneous)

interactions• Continuous collisions: not too much worse;

mostly driven by short-interval tail of Possion distribution of event times• Bunch trains: worst-case scenario, could approach 100% overlap

– More or less impossible, and essentially pointless, to make a hardware trigger decision on every crossing:Trigger must be data-driven, much like present B-Factory triggers

– Beam currents back up, so beam backgrounds play a larger role again


6

Quick thoughts on the new model

• Electronics– Beam backgrounds back up:

detector response times must be reduced, especially in calorimeter

– Lack of an a-priori T0 requires peak-finding

• Either with conventional electronics or waveform sampling

• Nature and severity of beam backgrounds needs to be known better in order to make this decision

– Waveform sampling rates may need to be considerably higher• Compare BaBar EMC: 4 MHz sampling

• Continuous collisions require continuous sampling - potentially very high raw data volumes in pipeline


7

Quick thoughts on the new model - II

• Trigger– Return to B-Factory model:

Make trigger decisions at a speed set by the scale of the T0 resolution (“latency jitter”) achieved in the hardware trigger• 4/8 MHz for BaBar

• Does it need to be faster?

• Main advantage of going faster: allows narrowing readout window– Rejects noise hits before they start getting transported through DAQ and

reconstructed– Ultimately limited by physics of detector systems (e.g., drift time)

• My guess: probably won’t want to go more than 2x faster at most

– Expect very high rates, which will affect…


8

Quick thoughts on the new model - III

• DAQ– Need a much deeper pipeline than used in BaBar (4 buffers) to

deal with high rate– Data movement tends to dominate cost/performance of front-end

DAQ: need a design that can construct overlapping readout frames by indirection• Instead of requiring multiple copies of event data in the pipeline

• Basically true of BTeV, already done in a rudimentary way in one part of the BaBar DAQ

– Crucial to avoid any fixed per-trigger deadtime• BaBar has 2.7us - intolerable at 100 kHz, major loss even at 10 kHz


9

General considerations - triggering

• Taking as long-established the idea that we must preserve the “open trigger” model of BaBar and Belle– Too difficult to narrowly identify specific B-physics modes at trigger

level– Recoil analyses are poorly matched to narrow triggering


10

General considerations - Level 1 rate

In any of these models:• Substantive detectable Bhabha rate is O(50 kHz)• Rates from beam background are not yet known

– Expected to be much smaller in LC-type designs

• Fundamental choice:– Generate a Level 1 (hardware) trigger on everything that looks like

a multiple-particle interaction coming from the beam spot• 50-100 kHz rate• LHC-like electronics and front-end DAQ: high cost

– Attempt to veto Bhabhas at Level 1• Must not veto interesting events with overlapping Bhabhas• BaBar experience with vetoing Bhabhas in Level 3 suggests that fairly

simple algorithms can work at a 50-70% level, but they do need to be global: probably increases latency and thus pipeline length

• How good does the veto need to be to be worth doing?


11

General considerations - downstream T/DAQ

• Loosely speaking, this is a solved problem– Demonstrated several years ago that:

• Commodity networking hardware can handle event building

• Commodity computing can handle software triggering and full event reconstruction

… just by scaling from BaBar

– Some changes in how technology evolved:• Failure of CPU manufacturers to stay on expected Moore’s Law curve

for single-core clock speeds– Still stuck below 4 GHz

• Parallelism of anticipated farms will have to be higher than expected, by up to 5x

• Multiple-core CPUs will help keep the number of boxes down, but still have to run many streams of processing at once

– Some work on scaling will be needed


12

General considerations - computing

• Not much to say about post-reconstruction computing– Analysis on B-Factory-type data at this scale is a hard problem– Lack of distinctive trigger signals makes this harder “per unit data”

than at Tevatron/LHC• Skims often have large selection fractions

– Moore’s Law does not save you:random access performance is not increasing as fast as other indicators of computing technology

– Electronic-memory-based storage (RAM or flash) provides a possible answer• Being investigated at SLAC (“PetaCache”): 1 TB prototype running and

being studied, 10 TB prototype (large enough to use for real BaBar analyses) being designed, proposal prepared


13

Desirable near-term actions

• Collect channel counts and readout requirements– Requires detector technology choices– Timing requirements, A-to-D bit depth, need for waveforms

• Determine electronics required for calorimeter• Collect relevant cost estimates from LHC, LHC-B, BTeV• Determine single-particle cross-sections for photons and

charged particles– May be less important now if low-rate models have really been

discarded

• Study practicality of hardware Bhabha veto• Review existing “deadtimeless” overlapping-frame DAQ

designs


14

Conclusions

• Technology required fits within LHC / BTeV envelope,so probably no show-stoppers

• LHC approach is expensive:Need to evaluate estimated cost of electronics required to operate at 100 kHz

• Cost may make intensive R&D on efficient Bhabha veto well-justified

Electronics / Trigger / DAQ considerations Gregory Dubois-Felsmann SLAC SuperB Workshop16-18 March...

Documents

Transcript of Electronics / Trigger / DAQ considerations Gregory Dubois-Felsmann SLAC SuperB Workshop16-18 March...