ECAL Integration / CALICE DAQ task force Taikan Suehara (Kyushu University, Japan)
Topics SiW-ECAL and EUDAQ DAQ Task force 2014 trial 2016 plan (others?) DAQ Task force
Sc + Si TB at CERN Nov. 26 – Dec. 8, 2014, CERN PS 15 Sc layers (3 EBU + 12 HBU) 1 Si layer (FEB8, from Kyushu)
Si and Sc DAQ SKIROC2 SPIROC2 Flexi cable HDMI Ethernet Coaxial Si DIFs Sc DIFs Spill GDCC/LDA Si CCC Sc CCC xLDA Clock Acquisition cycle PC PC
Clock Synchronization PLL in ZedBoard (Scintillator CCC) It generates 40 MHz (for Sc) and 50 MHz (for Si) synchronized 50 MHz delivered to CCC clock input (LEMO) Old CALICE CCC (2010) convert the clock to HDMI BX (slow) clock generated independently
Timing chart of acquisition ~400 ms spill Sc livetime readout Sc busy Si “spill” readout “Acquisition cycle” number is consistent, but Si busy is not considered
Combined DAQ for Si + Sc LCIO file(s) EUDAQ Run control Event display (not finalized) start/stop run # Data collector start/stop Labview Sc data Si data calicoes/pyrame Sc hardware Si hardware
Actual implementation of Si-side Calicoes has a socket port to output raw DIF packets (1 port / DIF) LDA header is stripped within Calicoes EUDAQ SiProducer connected to the port and convert it to “EUDAQ packet” Actually two converters were implemented DIF packet to LCIO (LCGenericObject) including time stamping LCGenericObject ot EUDAQ RawDataEvent Generic, non-Si specific RawDataEvent submitted to the collector
Implementation: run control Adhoc solution Configuration of Calicoes is independent Done before EUDAQ configuration “Configure” signal received at Si producer is just to connect to the DIF port Start/stop do not send anything to DIF Just start/stop to record the DIF packet Packet just dropped during “configured” state
Data integration Checking consistency acquisition number is critical! (at least at the test stage) I used timestamp (wall time at PC) Scintillator CCC vetoed acquisition cycle at non-spill time Several events (in a spill); long pause; several events (in the next spill); ...
Screenshot of EUDAQ Master PC (Linux): EUDAQ + CALICOES (Silicon) Slave PC (Windows): LabView (Scintillator) Successfully took data for more than a week
Output files
Output files Calicoes raw output is kept for the backup solution Two output: raw from Calicoes and LCIO from EUDAQ Si and Sc data are integrated to one LCIO One LCEvent: two collection (Si + Sc) If no event in Si just have Sc collection
2014 integration: issues Si busy is not considered Configuration is independent Scalability (we just had one Si layer) Clock: 50 MHz vs 40 MHz “not 100% synchronized” Acquisition number between Calicoes and EUDAQ not consistent
2016 plan Combined TB Si + SDHCAL EUDAQ Kyushu group Integration test at April? Testbeam at June? (I informed today...) EUDAQ Extension of current implementation? I can contribute if it’s needed Or new implementation? Kyushu group Temporarily less activity... More manpower from (maybe) autumn 2016
Task force: summary of prev. mtg. Discussions on EUDAQ SDHCAL prefers two-stage initialization (initialize/configure), but not critical. EUDAQ developers prefers simpler state machine (idle/configured/running). Will stay simple now. EUDAQ new feature: will have a simple module which can be attached to subsystem DAQ to communicate with EUDAQ. Monitoring: should have close communication between EUDAQ monitoring (initially for AHCAL) and SDHCAL DQM. Duplicate efforts should be avoided.
Task force: summary of prev. mtg. Discussions on LCIO Keep data structure as near as raw data. A LCIO class with raw data stream + some configuration is possible. Should contact with F. Gaede / LCIO team Output from a DIF should be an LCIO object (esp. in SDHCAL).