Requirements from CALICE-DAQ for WP5 - PowerPoint PPT Presentation

mattox
requirements from calice daq for wp5 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Requirements from CALICE-DAQ for WP5 PowerPoint Presentation
Download Presentation
Requirements from CALICE-DAQ for WP5

play fullscreen
1 / 25
Download Presentation
167 Views
Download Presentation

Requirements from CALICE-DAQ for WP5

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Requirements fromCALICE-DAQfor WP5 Taikan Suehara (Kyushu University, Japan)

  2. CALICE-DAQ introduction • Three types of calorimeter being actively developed • Silicon ECAL • Scintillator strip ECAL / Analog HCAL • Semi-digital RPC HCAL • Individual DAQ hardware and software • Conceptually based on UK(~2008) scheme SiECAL (2012) ScECAL+AHCAL (2014) SDHCAL (2014)

  3. CALICE DAQ Structure HDMI Ethernet USB TLU? CALICE Master CCC tracker etc. Not realized yet Clock, start/stop, validation, busy PC PC Sc CCC Si CCC PC SDHCAL SDCC data data RPI DCC WingLDA / MiniLDA LDA / GDCC data SDHCAL DIF Sc DIF Si DIF SPIROC HARDROC SKIROC

  4. First trial of Si+Sc TB 2014 ScCCC as master 1 Si layer upstreamScECAL + AHCAL (~1m) Timingsynchronizationconfirmed EUDAQ+ adapterused

  5. CALICE DAQ Task Force • Experts’ meeting discussing common DAQ • Members • Silicon: R. Cornat, F. Magniette, T. Suehara • Scintillator: J. Kvasnicka, M. Reinecke • Semi-digital HCAL: L. Mirabito, C. Combaret • 2 years of mandate • ~ 1 meeting per month • 5 meetings held • First agreement is being made for hardware


  6. Targets of CALICE DAQ TF • Common DAQ • Common clock and acquisition cycle (AQC) • Synchronized data taking and event matching • Common run control • Interface to upper control (TLU) • Combined testbeam • Minimize total work by sharing tasks • Currently ‘minimal effort’ basis • Acceptable combination with minimal effort

  7. Hardware / Firmware Mainly based on discussion in CALICE DAQ TF with some personal bias

  8. TLU and CALICE Master-CCC • Common function of TLU and MCCC • Provide common clock (BX clock?) • Busy & validation • Start/Stop Acquisition cycle (AQC) • MCCC-only function: • Provide synchronized configurable fast clock • Configurable delay of Start/Stop AQC • HDMI serialized format for start/stop • At least three output HDMI for each technology Possible to combine TLU and CALICE master CCC?(+ even individual CCCs (Si, Sc, SD) ?)

  9. Running mode: TB spill CCC start stop stop start LDA Busyclear Busy Busyclear For maximum efficiency at testbeam

  10. Running mode: ILC • 5 Hz, 1 mslivetime in ILC, variable in TB • Preferred for power-pulsing operation • Data quality should be monitored “AQC” CCC start stop stop start LDA Spill(optional)

  11. TLU: misc • Master clock can be assumed as ‘BX’ clock • Some of CALICE subsystem may not accept this directly • ‘Start’ and ‘Stop’ should be synchronized to the clock • Scintillator subsystem requires dedicated LED calibration run at some period • No need for Si and SDHCAL

  12. HDMI between CCC & LDA CCC  LDA • Clock (freq. varies by subsystem) • Validation (or trigger) • Serialized command line • 8b/10b encoding in some subsystems • Common commands defined (like start/stop) LDA  CCC • Busy (either oscillating or non-oscillating) • Serialized data transfer (not used)(used for LDADIF communication)

  13. Master CCC • Not realized yet(DESY or/and Kyushu will contribute) • Planned to be implemented in Zync FPGA • Overlap of function with TLU • We expect compatibilitywith non-TLU run and TLU run

  14. Software Not discussed yet in CALICE DAQ TF,so this is mainly my personal opinion…

  15. Software • Common DAQ needs common software for • Run control and configuration • Data integration, monitoring and validation • Requirement for Common DAQ • Flexibility • (At least some) support • Scalability to at least full layer prototype • Multiple DAQ machine • Upgradability to real ILC DAQ

  16. LCIO trasfer • LCIO is our common data format • LCIO cannot be easily transferred via TCP • SIO uses stream but hard-coded to file IO • ‘Major effort’ needed to modify that but we desire to do so • Can be contributed by this WP?

  17. LCIO structure for CALICE raw data • Format of raw data is not structured in LCIO • Usually LCGenericObject is used • Something like ‘RawCaloData’ is desired • Main components of raw data • Address – LDA/DIF ID (optional), ASIC ID, cell ID, event buffer ID (usually 0-15) • Time component: Run, AQC, BX • Several analog or digital data per every cell • ADC, TDC, trig/hitbit etc. • Condition variables (temperature etc.) • Should be easily calibrated

  18. EUDAQ From my personal observation of EUDAQ 1.4.1, not EUDAQ 2

  19. EUDAQ: structure • In the current EUDAQ structure project-specific codes are not well separated from core • We want to compile minimum-core + ILC specific + LCIO (and not Eutelescopewhich requires broader range of ILCsoft) • Dynamic loading of DLL may be necessary

  20. EUDAQ: communication • We would keep the independence of individual DAQ frameworks • Well-defined communication protocol is desired between EUDAQ and individual DAQ • Controlling EUDAQ from scripts is also desired • One proposal • Configuration by xml which can be transferred via TCPas well as gotten from a file • Each control command is communicated with xml structure, can be communicated from scripts as well • Data can be exchanged in a desired format by users,for us LCIO if available…

  21. EUDAQ: scalability • Our (quasi-final) prototype may consist of • ~ 1k ASICS, ~ 100k channels per subsystem • Should be acquired by 1-10 PC per subsystem • Of course integration to 1 PC should be a bottleneck  parallel acquisition is necessary • Real ILC: ~ 1M ASICS, ~ 100M channels O(1k) PCs?

  22. EUDAQ: contribution from CALICE • ‘CALICE’ part of EUDAQ should be controlled by us, with support from core-developers • Of course contribution from core-developers are mostly very welcome • We want to propose or contribute to core-code as well • We need regular communication for co-development of EUDAQ and CALICE-EUDAQ

  23. Misc: condition database • Condition should be stored and managed at some good coordination • Easy interface (from web, from script, etc.) • Accessibility from the web • Access control • Safety (backup, conflict, etc.) • Local replication (for testbeam etc.) • Flexible structure (multiple calibration, etc.) • What to store (example) • Layer structure (LDA#, DIF#, ASIC#...) • Calibration constants and settings(gain, noise, bias HV etc.) • General condition (place, TB used, failure, repair etc.)

  24. Misc: beam interface • Communication to facility (accelerator) is usually not well established during the short TB period • Standard interface is important • Desired functions: • Logging various accelerator parameter • Stored on condition database?? • Easy access online/offline • Time stamping according to run/AQC/(BX) • Maybe receiving TLU

  25. Summary • We recognize that CALICE-DAQ related work is a big part of WP5, and WP5 is important for CALICE-DAQ • For hardware, TLU and master CCC should be in close connection • For software, closer collaboration is needed for further development