1 / 17

First Ideas For CALICE Beam Test DAQ

First Ideas For CALICE Beam Test DAQ. Paul Dauncey Imperial College London, UK. CALICE beam test overview. ECAL 30 layers of tungsten 9720 Si diode pads with analogue readout HCAL 38 layers of iron 5000 55cm 2 scintillator pads with analogue readout (AHCAL) OR

benson
Download Presentation

First Ideas For CALICE Beam Test DAQ

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. First Ideas For CALICE Beam Test DAQ Paul Dauncey Imperial College London, UK Paul Dauncey - CALICE DAQ

  2. CALICE beam test overview • ECAL • 30 layers of tungsten • 9720 Si diode pads with analogue readout • HCAL • 38 layers of iron • 5000 55cm2 scintillator pads with analogue readout (AHCAL) OR • 350000 11cm2 RPC, scintillator or GEM pads with digital readout (DHCAL) Paul Dauncey - CALICE DAQ

  3. 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 Paul Dauncey - CALICE DAQ

  4. 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 Paul Dauncey - CALICE DAQ

  5. 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 Paul Dauncey - CALICE DAQ

  6. 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 Paul Dauncey - CALICE DAQ

  7. Trigger/DAQ logic Idea is to implement trigger/DAQ interface for all subsystems Paul Dauncey - CALICE DAQ

  8. 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 LVDSNIM converter available • Beam on signal allows buffering during spill, readout after spill Paul Dauncey - CALICE DAQ

  9. 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 Paul Dauncey - CALICE DAQ

  10. 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 Paul Dauncey - CALICE DAQ

  11. 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 semi-buffered mode • Simpler trigger, better error detection and event verification in semi-buffered mode Paul Dauncey - CALICE DAQ

  12. 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? Paul Dauncey - CALICE DAQ

  13. 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 Paul Dauncey - CALICE DAQ

  14. Prototype DAQ software ideas Very little work (~ two weeks!) in this so far • Open to suggestions to use existing DAQ software Paul Dauncey - CALICE DAQ

  15. 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 Paul Dauncey - CALICE DAQ

  16. 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 Paul Dauncey - CALICE DAQ

  17. 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 Paul Dauncey - CALICE DAQ

More Related