Interfacing Calibration and DAQ - part I Nuno Barros November 5 th - - PowerPoint PPT Presentation

Interfacing Calibration and DAQ - part I

Nuno Barros

1

November 5th 2019

• This is still ongoing work
• Several discussions (both on calibration and DAQ sides) are required

2

Disclaimer

3

Conceptual operation of DAQ/Calib during a run

Operator Run Control Cal Interface Software Calibration Hardware 1 Trigger Dispatcher Event Builder Stored Calibration Data TPC Data Buffer Calibration Hardware N

“Fire calibration C1 with frequency B, intensity C and direction D” C1(t,C,D) Validate calibration request Trigger(t,C,D) Trigger(t,C,D) —> Record data from TPC in [t,t+dt] Data from [t,t+dt]

4

Conceptual operation of DAQ/Calib during a run

Operator Run Control Cal Interface Software Calibration Hardware 1 Trigger Dispatcher Event Builder Stored Calibration Data TPC Data Buffer Calibration Hardware N

“Fire calibration C1 with frequency B, intensity C and direction D” C1(t,C,D) Validate calibration request Trigger(t,C,D) Trigger(t,C,D) —> Record data from TPC in [t,t+dt] Data from [t,t+dt]

5

Zooming into the boundary between DAQ and Interface

Timing system

Trigger(t,C,D)

Calibration Hardware 1 Motors Filters Trigger input Timing interface Sensors

• Several components to control from a single command received from the timing

system

• Most of these components are controlled independently

Calibration Hardware 1 Motors Filters Trigger input Sensors CIB 6

CIB (calibration interface board)

Timing system

Trigger(t,C,D)

• Act as interface layer between the DAQ and the calibration systems (as a whole)
• Receive DAQ commands through the timing system
• Translate commands into low level actions in the hardware (or respective

interfaces)

• Drive calibration firing (synchronous with timing)
• Receive information from the hardware (sensor data)

Timing interface Hardware control

• Timing system interface
• The only connection to the DAQ currently foreseen
• (optional) Data interface to the DAQ (still an open discussion point)
• Eg.: Get accurate mirror position by checking laser firing time with DAQ
• CPU + network interface
• (optional) Data interface to monitoring/slow control/database
• CPU + network interface
• Translate timing commands into low level hardware commands
• Easily done with an FPGA
• Alternatively network interface to pass software commands
• Live in the same ground as the calibration hardware
• Simpler than overly complicated ground isolation over hardware interfaces
• Capability to digitise sensor data

7

(Some) requirements

• Timing system interface
• The only connection to the DAQ currently foreseen
• (optional) Data interface to the DAQ (still an open discussion point)
• Eg.: Get accurate mirror position by checking laser firing time with DAQ
• CPU + network interface
• (optional) Data interface to monitoring/slow control/database
• CPU + network interface
• Translate timing commands into low level hardware commands
• Easily done with an FPGA
• Alternatively network interface to pass software commands
• Live in the same ground as the calibration hardware
• Simpler than overly complicated ground isolation over hardware interfaces
• Capability to digitise sensor data

8

(Some) requirements

…if only we had such a system around…

9

ProtoDUNE CTB

The Central Trigger Board (CTB)

• Hardware electronics with an embedded system

with FPGA and CPU for trigger decision and data streaming

• Motherboard implements hardware interface

with different systems

• FPGA implements trigger logic, interface with

timing

• CPU/Software manages FPGA configuration and

communication with DAQ software

• trigger

timing trigger distribution artdaq hardware

1

• Consists of a motherboard that provides (mostly) logic conversion and I/O
• Uses a MicroZed as the main processing and decision unit
• FPGA implements timing interface logic, low level logic
• CPU implements multiple network connection slots, configuration management,

monitoring, communication with DAQ software (slow control, monitoring, etc)

• Multiple network slots
• Control and configuration
• Data stream
• Monitoring / data statistics
• Remote management through ssh
• The board runs a linux system on the CPU
• Generic configuration through software (JSON configuration file)
• Fast data throughput (DMA + GB ethernet) - capable of handling ~10 MHz

data rates

10

CTB @ ProtoDUNE

• Timing system interface
• (needs upgrade to use CDR chip + fiber instead of copper)
• (optional) Data interface to the DAQ
• CPU + network interface
• (optional) Data interface to monitoring/slow control/database
• CPU + network interface
• Translate timing commands into low level hardware commands
• Contains both FPGA and CPU
• Live in the same ground as the calibration hardware
• 3U rack mount footprint (likely need to be revised)
• Capability to digitise sensor data
• ADC in MicroZed not fast enough (good for monitoring slow signals, though)

11

(Some) requirements

12

Conceptual design

Calibration Hardware 1 Network interface (SFP) Hardware I/O SOC (uZed, picoZed, UltraScale, …) Timing interface (CDR + SFP+) ADC

• Reuse as much design from CTB as possible
• Hardware, FPGA IPs and software (both hardware and DAQ side)
• Learn from the past : replace copper timing interface by CDR+SFP+

Clock out (buffered)

• The issue the CIB addresses is common to both DUNE and PD
• The difference is the number and type of calibration interfaces to manage
• First step is to implement the CIB in ProtoDUNE
• Ideal testing ground
• Use PD experience to optimize design for DUNE
• Have requested funding to build 2 prototypes for PD
• DUNE will possibly require larger number (need accurate I/O count)

13

DUNE vs ProtoDUNE

• How many I/O ports are needed per calibration system?
• Do we need to provide event data to the DAQ?
• Eg. cross the hardware firing time with the DAQ request for accurate

knowledge of mirror position

• Where should the calibration hardware data go?
• Monitoring infrastructure, database, secondary output file?
• What’s the granularity of calibration configuration?
• Event configuration, run configuration, etc
• Interface to monitoring. Via CIB or other way?

14

Open Questions

• This is an initial proposal to create a flexible interface between DAQ and

calibration

• Allows more flexibility in the design of the calibration hardware by

aggregating the DAQ specific bits

• Could be used also as interface for monitoring infrastructure
• Would need clear requirements
• Based on existing system that has successfully proven its reliability and

flexibility

• Currently being used as the hardware trigger of PD-SP
• Low maintenance, possible for remote management, on-the-fly updates

15

Summary