First Ideas For CALICE Beam Test DAQ Paul

First Ideas For CALICE Beam Test DAQ Paul Dauncey Imperial College London, UK for IC, Manchester, RAL, UCL 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 5 5 cm 2 scintillator pads with analogue readout (AHCAL) OR • 350000 1 1 cm 2 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 • • • Want to run in many configurations • • Particle type (e and ), energy (1 -100 Ge. V), 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 • • • Tune simulation accurately Particularly important for hadronic showers Beam monitoring and trigger “Tail catchers” for shower leakage Purpose built readout board being developed • • Based on CMS Si tracker Front End Board (FED) 9 U board; currently standard VME, upgradable to VME 64 x 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 • • No data reduction in readout board • • • No buffering available in ECAL and AHCAL front end; must receive data from front ends for every trigger Memory allows buffering of up to ~2 k events on readout board in beam spill Large amount of unused I/O from BE FPGA to backplane • • DHCAL has zero suppression in front end Read out all ECAL and AHCAL channels for every event Maximum 3. 5 k. Bytes per board, 30 k. Bytes total per event On-board buffer memory; 8 MBytes • • DAC fed back for internal as well as front end calibration 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 • • Want to buffer 2 k events during beam bunch • • Needs to be flexible for several different HCAL options and/or beam lines Minimal fast control/timing system • • Handle beam bunches up to 2 secs Robust, simple, flexible • • 100 Hz average event rate 1 k. Hz peak event rate during beam bunch Assumes 10% duty cycle for beam Need simple, fast (180 ns latency) 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 2 April 2003 Paul Dauncey - CALICE DAQ 7

Trigger handling • Multiple (4) trigger and “activity” (background) inputs • • Need clean events with no pile-up • • Distribution to other boards in crate using custom cable Point-to-point LVDS (probably) Trigger also configurably delayed and output to connector • • • Reset through VME; single reset for system so no synchronisation issues Trigger is fanned out and sent to backplane connector • • Activity prevents subsequent triggers within configurable time period Trigger records following activity; read out with event Trigger latches off logic, preventing further triggers • • Can be enabled and disabled through VME 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 2 April 2003 Paul Dauncey - CALICE DAQ 8

Modes of operation Readout board can run in any of three modes • Single trigger readout • • Semi-buffered readout • • Read all data between each trigger; slow but sure 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 k. Bytes, DHCAL 5 k. Bytes (AHCAL 3 k. Bytes), other (beam monitoring, etc) 2 k. Bytes (? ) • Average time for clear/trigger/interrupt from end of one event to start of read of next: 0. 1 ms. Implies beam rate >10 k. Hz • 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. 1 ms • All beam monitoring, etc, data is always unbuffered and is read out with non-block transfer so takes 0. 5 ms 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: 24 k. Bytes block transfer 1. 5 ms, total 2. 3 ms per event; rate limited to 430 Hz • Semi-buffered: 400 Bytes takes 0. 1 ms so 0. 9 ms per event during spill; rate limited to 1. 1 k. Hz. 1. 5 ms per event outside of spill; rate limited to 670 Hz • Fully-buffered: Only time saved is readout of 100 Bytes, so 0. 8 ms per event during spill; rate limited to 1. 2 k. Hz. 1. 6 ms per event outside of spill; rate limited to 630 Hz 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, c. PCI, 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 • • Simplest system is two PCs with physically movable disks • • Disk I/O competition, network I/O, etc; need to test effect of these “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 (MIDAS? ) 2 April 2003 Paul Dauncey - CALICE DAQ 14

Prototype DAQ software ideas (cont) • Simple prototype system working • • System will be Linux, software in C++ • • 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 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 • • Rough working assumption for outline schedule is • • • Beam line(s) to be used not yet decided 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 2 April 2003 Paul Dauncey - CALICE DAQ 16

Summary • Have around one year from now to build DAQ system for CALICE • • Aiming for rates of around 1 k. Hz during a spill • • Buffering up to 2 k events during the spill on-board Biggest uncertainties relate to beam line equipment • • Based on custom-built VME readout electronics 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