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

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

Embed Size (px)

Citation preview

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun. 2015 page 1

Requirements fromCALICE-DAQ

for WP5

Taikan Suehara(Kyushu University, Japan)

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

CALICE DAQ StructureTLU?

CALICE Master CCC tracker etc.

Si CCC Sc CCC SDHCAL SDCC

LDA / GDCC WingLDA / MiniLDA DCC

Si DIF Sc DIF SDHCAL DIF

PC PC

data

RPI

data

data

PC

SKIROC SPIROC HARDROC

Not realized yetClock, start/stop, validation, busy

HDMIEthernetUSB

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun. 2015 page 4

First trial of Si+Sc TB 2014

1 Si layer upstreamScECAL + AHCAL (~1m)

EUDAQ+ adapterused

Timingsynchronization

confirmed

ScCCC as master

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

Hardware / Firmware

Mainly based on discussion in CALICE DAQ TF with some personal bias

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun. 2015 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. 2015 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. 2015 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. 2015 page 11

CCC LDA1. 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 CCC4. Busy (either oscillating or non-

oscillating)5. Serialized data transfer (not used)

(used for LDADIF communication)

HDMI between CCC & LDA

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun. 2015 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. 2015 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. 2015 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 DAQ

Software

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun. 2015 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. 2015 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. 2015 page 17

EUDAQ

From my personal observation of EUDAQ 1.4.1, not EUDAQ 2

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun. 2015 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. 2015 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

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…

EUDAQ: communication

Taikan Suehara, AIDA-2020 kickoff meeting, 3 Jun. 2015 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. 2015 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. 2015 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 development

Summary