1 / 25

Requirements from CALICE-DAQ for WP5

Requirements from CALICE-DAQ for WP5. Taikan Suehara (Kyushu University, Japan). 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

mattox
Download Presentation

Requirements from CALICE-DAQ for WP5

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. 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

More Related