CALICE DAQ Task Force hardware summary first draft: May 2015

1. Scope

This document aims to define a hardware baseline for CALICE common DAQ system. Target of the system includes concurrent run of any combinations of three subsystems of SiECAL, ScECAL/AHCAL and SDHCAL at test beam environments and other test setups. The system should be also compatible with possible upper control - such as TLUs to enable combined run with trackers etc.

2. Master CCC

A 'Master CCC' should be on the top of the CALICE common DAQ system.
The master CCC should provide following functions:
- Master clock of ~5 MHz. This should be treated as BX clock at each system.
- Fast clock of 50 MHz to SiECAL subsystem instead of master clock
- start_acq and stop_acq signals in fast command format (HDMI) and level output (TTL at LEMO00 connector). The signals can be supplied with fixed delay on each port. The delay can be configured from PC. This is to synchronize livetime of each subsystem with various inactive time after start_acq.
- Functionality to synchronize to upper control (details are not decided yet).  
The master CCC should accept
- Busy signal from each subsystem. The busy can either be oscillated or level, from HDMI or TTL level from LEMO00 connector.

At least two running modes are required to be implemented at the Master CCC:
(i) ILC mode, accepting external signal to start and stop the acquisition cycle regardless of busy state.
(ii) TB mode, controlling start_acq and stop_acq by looking at Busy signals from each subsystem. In the TB mode, stop_acq is immediately issued after receiving Busy from any of the subsystems, and waiting for Busy from all subsystems to be cleared before issueing next start_acq. External signal (spill) is used to veto the next start_acq.

The Master CCC may accept artificial triggers of start_acq and stop_acq from control PC, or automatic periodic generation of those (configured from PC).

The Master CCC should have at least following I/Os:
- Minimum two HDMI connections, to communicate with ScECAL/AHCAL and SDHCAL systems.
- Minimum three LEMO connections, to provide clock, start_acq/stop_acq and to accept busy from SiECAL system.
- Minimum one HDMI(?) for upper connection
- Minimum one port to communicate with PC - can be RJ45/ethernet

The Master CCC should be provided to all subsystem groups (2-3 per subsystem). This can be a single board or a commercial board + mezzanine. The commercial board may be purchased by each subsystem group if it is easily available worldwide.
We expect that the first Master CCC will be developed based on commercial Zedboard which ScECAL/AHCAL group has experiances. The mezzanine boards will be provided from DESY/Mainz to all subsystem groups.

3. Run/Acquisition cycle/Bunch crossing definition

Run is a set of acquisitions at one continuous running period. The condition within a run is normally considered not to be changed. Typical period of a run is 1 hour - 1 day, but no strong restriction is applied for the run period. It should be discussed among the subsystem representatives at combined runs.
Consistent numbering of run is required at every combined run (and recommended in any runs of single subsystem except short test runs). The run number should be 8 digits with first 3 digits of unique testbeam number and 5 digits of run number in the testbeam period. 

Acquisition cycle or AC is a single acquisition and readout cycle, from a start_acq signal to the next start_acq signal. The first cycle of AC should be numbered zero. The consistent numbering of any subsystem joined in the combined testbeam is critical to synchrnoize the data.
AC should be at least 16 bits. AC should be counted at hardware (LDA etc.), but the higher bits can be compensated by intermediate software.

Each AC should have a timestamp on each subsystem to cross-check the consistent numbering. Format of communicating the timestamp is wall time in millisecond resolution. The timestamp can be added on acquisition PC of each subsystem, but it is recommended to assign at the most upstream point of acquisition as possible. Proper NTP is needed to synchronize the timestamp.

Spill signal is not supplied from Master CCC so there is no possibility to count the spill in each subsystem. Master CCC may count the spill number.

Bunch crossing (BX) number is assumed to be the number of pulses in master clock from certain time of start_acq. The BX number is not needed to be fully consistent in each subsystem at hardware level, but it should have only a fixed offset among the subsystems. It is not recommended to use inconsistent clock frequency to the orignal clock of Master CCC. The consistent renumbering of BX number should be performed by reconstruction software.