2 April 2003Paul Dauncey - CALICE DAQ1 First Ideas For CALICE Beam Test DAQ Paul Dauncey Imperial College London, UK for IC, Manchester, RAL, UCL

2 April 2003Paul Dauncey - CALICE DAQ2 ECAL 30 layers of tungsten 9720 Si diode pads with analogue readout HCAL 38 layers of iron  5cm 2 scintillator pads with analogue readout (AHCAL) OR  1cm 2 RPC, scintillator or GEM pads with digital readout (DHCAL) CALICE beam test overview

2 April 2003Paul Dauncey - CALICE DAQ3 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 ~ 10 6 events per configuration Total event sample ~ 10 8 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 Beam test aims

2 April 2003Paul Dauncey - CALICE DAQ4 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 Readout board overview

2 April 2003Paul Dauncey - CALICE DAQ5 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 Readout board features

2 April 2003Paul Dauncey - CALICE DAQ6 Want 10 8 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, fast (180ns latency) trigger distribution Solution: single PC and single VME crate if possible No inter-PC communication issues No trigger synchronisation issues DAQ requirements

2 April 2003Paul Dauncey - CALICE DAQ7 Trigger/DAQ logic Idea is to implement trigger/DAQ interface for all subsystems

2 April 2003Paul Dauncey - CALICE DAQ8 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 LVDS  NIM converter available Beam on signal allows buffering during spill, readout after spill Trigger handling

2 April 2003Paul Dauncey - CALICE DAQ9 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 Modes of operation

2 April 2003Paul Dauncey - CALICE DAQ10 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 DAQ readout rates

2 April 2003Paul Dauncey - CALICE DAQ11 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 semi- buffered mode Simpler trigger, better error detection and event verification in semi-buffered mode DAQ readout rates (cont)

2 April 2003Paul Dauncey - CALICE DAQ12 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? Beam monitoring

2 April 2003Paul Dauncey - CALICE DAQ13 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 Data distribution

2 April 2003Paul Dauncey - CALICE DAQ14 Very little work (~ two weeks!) in this so far Open to suggestions to use existing DAQ software (MIDAS?) Prototype DAQ software ideas

2 April 2003Paul Dauncey - CALICE DAQ15 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 Prototype DAQ software ideas (cont)

2 April 2003Paul Dauncey - CALICE DAQ16 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 electron beam Summer 2004 – tile AHCAL only at DESY with 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 Schedule

2 April 2003Paul Dauncey - CALICE DAQ17 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 Summary