First Ideas For CALICE Beam Test DAQ Paul Dauncey Imperial College London, UK 2 April 2003 Paul Dauncey - CALICE DAQ.
Download ReportTranscript First Ideas For CALICE Beam Test DAQ Paul Dauncey Imperial College London, UK 2 April 2003 Paul Dauncey - CALICE DAQ.
First Ideas For CALICE Beam Test DAQ Paul Dauncey Imperial College London, UK 2 April 2003 Paul Dauncey - CALICE DAQ 1 CALICE beam test overview • ECAL • 30 layers of tungsten • 9720 Si diode pads with analogue readout • HCAL • 38 layers of iron • 5000 55cm2 scintillator pads with analogue readout (AHCAL) OR • 350000 11cm2 RPC, scintillator or GEM pads with digital readout (DHCAL) 2 April 2003 Paul Dauncey - CALICE DAQ 2 Beam test aims • Want to do detailed studies of showers • Tune simulation accurately • Particularly important for hadronic showers • Want to run in many configurations • Particle type (e and ), energy (1-100 GeV), HCALs, preshower material, incident angle, etc • Want ~ 100 configurations, with ~ 106 events per configuration • Total event sample ~ 108 events • For each event, read out ECAL and either HCAL plus • Beam monitoring and trigger • “Tail catchers” for shower leakage • Purpose built readout board being developed • Based on CMS Si tracker Front End Board (FED) • 9U board; currently standard VME, upgradable to VME64x 2 April 2003 Paul Dauncey - CALICE DAQ 3 Readout board overview Readout board structure • Front End (FE) FPGA controls all signals to front end electronics • Back End (BE) FPGA gathers and buffers all event data from FE and provides interface to VME • Trigger logic in BE for timing and backplane distribution; only active in one board • First readout board prototypes in July 2003, final boards in March 2004 2 April 2003 Paul Dauncey - CALICE DAQ 4 Readout board features • Dual 16-bit ADCs and 16-bit DAC • DAC fed back for internal as well as front end calibration • No data reduction in readout board • DHCAL has zero suppression in front end • Read out all ECAL and AHCAL channels for every event • Maximum 3.5 kBytes per board, 30 kBytes total per event • On-board buffer memory; 8 MBytes • No buffering available in ECAL and AHCAL front end; must receive data from front ends for every trigger • Memory allows buffering of up to ~2k events on readout board in beam spill • Large amount of unused I/O from BE FPGA to backplane • Will implement trigger logic and control/readout interface to VME in BE • CMS version being debugged now • Will “borrow” a lot of software and DAQ from them 2 April 2003 Paul Dauncey - CALICE DAQ 5 DAQ requirements • Want 108 sample within a reasonable running time • 100 Hz average event rate • 1kHz peak event rate during beam bunch • Assumes 10% duty cycle for beam • Want to buffer 2k events during beam bunch • Handle beam bunches up to 2 secs • Robust, simple, flexible • Needs to be flexible for several different HCAL options and/or beam lines • Minimal fast control/timing system • Need simple trigger distribution • Solution: single PC and single VME crate if possible • No inter-PC communication issues • No trigger synchronisation issues 2 April 2003 Paul Dauncey - CALICE DAQ 6 Trigger/DAQ logic Idea is to implement trigger/DAQ interface for all subsystems VME IRQ BeamOn VME START Edge Detect SEQ Beam On Sync + Enable IRQ STOP 4x PreTrigger Trigger VME Trigger Window + Timer SEQ VME Pre-Trigger Sync + Enables START 4x SR STOP Width/ Delay Trigger Enable, Latch, Shaper, Veto Trigger Sync IRQ SINK VME VME SEQ 4x Activity VME Activity Sync + Enables VME Internal Trig Osc + Random + Timer 16 x Counter Delays (16bit?) 4x SR Delayed Trig 1 SINK Delayed Trig 16 SINK VME VME VME SEQ Veto VME 6x Spare Inputs 2 April 2003 Veto Sync + Enable SR ‘Digitiser’ 32bit Shift Registers, Storage Registers x9 Trigger Logic Block Diagram SINK Paul Dauncey - CALICE DAQ ‘Sequencer and Sink’ Seq (8 bit) + Sink (24 bit) RAM = 32KByte RAM 4x Spare Outputs 7 Trigger handling • Multiple (4) trigger and “activity” (background) inputs • Can be enabled and disabled through VME • Need clean events with no pile-up • Activity prevents subsequent triggers within configurable time period • Trigger records following activity; read out with event • Trigger latches off logic, preventing further triggers • Reset through VME; single reset for system so no synchronisation issues • Trigger is fanned out and sent to backplane connector • Distribution to other boards in crate using custom cable • Point-to-point LVDS (probably) • Trigger also configurably delayed and output to connector • For distribution to other systems (beam monitoring, HCAL?) • Assuming 16 outputs, LVDS; we have a LVDSNIM converter available • Beam on signal allows buffering during spill, readout after spill 2 April 2003 Paul Dauncey - CALICE DAQ 8 Modes of operation Readout board can run in any of three modes • Single trigger readout • Read all data between each trigger; slow but sure • Semi-buffered readout • Read minimal information from each board per event; e.g. trigger number and buffer occupancy • Must read any unbuffered electronics for each event • Buffer rest of data and read later (after beam spill) • Fully-buffered readout • Nothing read from readout boards per trigger; only unbuffered electronics • All readout board data buffered until end of spill • A missed trigger corrupts whole spill of data Semi-buffered is to avoid the need for a more sophisticated fast control and timing system 2 April 2003 Paul Dauncey - CALICE DAQ 9 DAQ readout rates Assumptions: • Average event data: ECAL 19 kBytes, DHCAL 5 kBytes (AHCAL 3 kBytes), other (beam monitoring, etc) 2 kBytes (?) • Average time for clear/trigger/interrupt from end of one event to start of read of next: 0.1ms. Implies beam rate >10kHz • VME data speeds: non-block transfer 4 MBytes/s, block transfer 16 MBytes/s • Semi-buffered readout of ECAL and HCAL is 400 Bytes per event total, read out with non-block transfer so takes 0.1ms • All beam monitoring, etc, data is always unbuffered and is read out with non-block transfer so takes 0.5ms per event • Disk write speed: ~ 20 MBytes/s; always outperforms VME 2 April 2003 Paul Dauncey - CALICE DAQ 10 DAQ readout rates (cont) Rates for the different modes: • Single trigger: 24kBytes block transfer 1.5ms, total 2.3ms per event; rate limited to 430Hz • Semi-buffered: 400 Bytes takes 0.1ms so 0.9ms per event during spill; rate limited to 1.1kHz. 1.5ms per event outside of spill; rate limited to 670Hz • Fully-buffered: Only time saved is readout of 100 Bytes, so 0.8ms per event during spill; rate limited to 1.2kHz. 1.6ms per event outside of spill; rate limited to 630Hz No significant gain from using fully-buffered mode over semibuffered mode • Simpler trigger, better error detection and event verification in semi-buffered mode 2 April 2003 Paul Dauncey - CALICE DAQ 11 Beam monitoring • Legacy equipment in beam line is big uncertainty • Potential beam lines have differing equipment, formats, etc. • VME, cPCI, CAMAC (!) all potentially needed • Uncertainty also in mode of use; still have one crate? • Use beam line DAQ? How interfaced? What OS? • Use crate with our PC? Is hardware control/readout software portable? 2 April 2003 Paul Dauncey - CALICE DAQ 12 Data distribution • Want to minimise any impact on DAQ rate • Disk I/O competition, network I/O, etc; need to test effect of these • Simplest system is two PCs with physically movable disks • “Offline” PC copies to permanent local and remote (DESY) storage • Also does pedestal subtraction and calibration to produced reduced data file • Downside; limits speed of data access after a run • Gives complete logical disconnect between DAQ and offline • Allows DAQ to be completely stand-alone if necessary 2 April 2003 Paul Dauncey - CALICE DAQ 13 Prototype DAQ software ideas Very little work (~ two weeks!) in this so far • Open to suggestions to use existing DAQ software 2 April 2003 Paul Dauncey - CALICE DAQ 14 Prototype DAQ software ideas (cont) • Simple prototype system working • Standard POSIX shared memory for event and control buffers • Standard signal IPC for throttle implementation • Dummy VME interface at present for tests; readout board memory map not yet defined • System will be Linux, software in C++ • This is where experience of developers lies • Probably borrow much from existing CMS FED teststand which also uses Linux and C++ • Monitoring will use ROOT • Have not yet decided on data persistency • Writer process could have optional different output formats • ROOT, SIO, ASCII have been discussed • Probably implement more than one 2 April 2003 Paul Dauncey - CALICE DAQ 15 Schedule • Still flexible as depends on development of prototype calorimeters, electronics, etc • Beam line(s) to be used not yet decided • Rough working assumption for outline schedule is • • • • Summer 2004 – ECAL only at DESY with 6 GeV electron beam Autumn 2004 – ECAL with tile AHCAL Winter 2004 – ECAL with RPC DHCAL Summer 2005 – ECAL with RPC/GEM/scintillator mixed DHCAL • First milestone for complete electronics and DAQ system • Cosmic tests of ECAL, Spring 2004 2 April 2003 Paul Dauncey - CALICE DAQ 16 Summary • Have around one year from now to build DAQ system for CALICE • Based on custom-built VME readout electronics • Aiming for rates of around 1kHz during a spill • Buffering up to 2k events during the spill on-board • Biggest uncertainties relate to beam line equipment • Grateful to hear from anyone with experience of likely beam areas • DAQ software at very preliminary stage • Output data format, etc, not yet decided 2 April 2003 Paul Dauncey - CALICE DAQ 17