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

2. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann2 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-T 0 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. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann3 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 T 0 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. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann4 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. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann5 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. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann6 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 T 0 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. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann7 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 T 0 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. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann8 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. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann9 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. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann10 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. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann11 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. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann12 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. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann13 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. 2006.3.17SuperB Trig/DAQ/Elec - Gregory Dubois-Felsmann14 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