Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 1 Requirements from CALICE-DAQ for WP5 Taikan Suehara (Kyushu University, Japan)

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 2 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 CALICE-DAQ introduction SiECAL (2012) ScECAL+AHCAL (2014)SDHCAL (2014)

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 3 CALICE DAQ Structure TLU? CALICE Master CCC tracker etc. Si CCC Sc CCC SDHCAL SDCC LDA / GDCCWingLDA / MiniLDA DCC Si DIF Sc DIF SDHCAL DIF PC data RPI data PC SKIROC SPIROCHARDROC Not realized yet Clock, start/stop, validation, busy HDMI Ethernet USB

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 4 First trial of Si+Sc TB Si layer upstream ScECAL + AHCAL (~1m) EUDAQ + adapter used Timing synchronization confirmed ScCCC as master

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 5 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 CALICE DAQ Task Force

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 6 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 Targets of CALICE DAQ TF

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 7 Hardware / Firmware Mainly based on discussion in CALICE DAQ TF with some personal bias

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 8 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 TLU and CALICE Master-CCC Possible to combine TLU and CALICE master CCC? (+ even individual CCCs (Si, Sc, SD) ?)

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 9 ILC mode (fixed frequency, no busy control) –Not necessarily 5 Hz in testbeam (for efficiency) –Signal from FG etc. just used as start/stop of acq –Preferred for power-pulsing operation (power-on at only active time: for heat reduction) –(Possibly) spill is used as anti-veto of the start –Data quality should be monitored TB mode (with busy control, variable acq period) –Start – stop at busy – restart at busy clear –Spill is anti-veto of the restart –Maximize data taking efficiency in testbeam TLU: Required running mode

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 10 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 TLU: misc

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 11 CCC  LDA 1.Clock (freq. varies by subsystem) 2.Validation (or trigger) 3.Serialized command line –8b/10b encoding in some subsystems –Common commands defined (like start/stop) LDA  CCC 1.Busy (either oscillating or non-oscillating) 2.Serialized data transfer (not used) (used for LDA  DIF communication) HDMI between CCC & LDA

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 12 Not realized yet (DESY or/and Kyushu will contribute) –Planned to be implemented in Zync FPGA Overlap of function with TLU –We expect compatibility with non-TLU run and TLU run Master CCC

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 13 Software Not discussed yet in CALICE DAQ TF, so this is mainly my personal opinion…

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 14 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 DAQSoftware

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 15 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? LCIO trasfer

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 16 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 LCIO structure for CALICE raw data

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 17 EUDAQ From my personal observation of EUDAQ 1.4.1, not EUDAQ 2

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 18 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 Eutelescope which requires broader range of ILCsoft) Dynamic loading of DLL may be necessary EUDAQ: structure

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 19 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 TCP as 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… EUDAQ: communication

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 20 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? EUDAQ: scalability

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 21 ‘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 EUDAQ: contribution from CALICE

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun page 22 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 developmentSummary