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

Interfacing Calibration and DAQ - part I Nuno Barros November 5 th 2019 1

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

Conceptual operation of DAQ/Calib during a run Operator Calibration Run Control Hardware 1 “Fire calibration C 1 with frequency B , intensity C and direction D ” Trigger Cal Interface Calibration Dispatcher Software C 1 (t,C,D) Hardware N Validate calibration request Trigger(t,C,D) Trigger(t,C,D) —> Record data from TPC in [t,t+dt] Data from [t,t+dt] TPC Data Buffer Event Builder Stored Calibration Data 3

Conceptual operation of DAQ/Calib during a run Operator Calibration Run Control Hardware 1 “Fire calibration C 1 with frequency B , intensity C and direction D ” Trigger Cal Interface Calibration Dispatcher Software C 1 (t,C,D) Hardware N Validate calibration request Trigger(t,C,D) Trigger(t,C,D) —> Record data from TPC in [t,t+dt] Data from [t,t+dt] TPC Data Buffer Event Builder Stored Calibration Data 4

Zooming into the boundary between DAQ and Interface Calibration Hardware 1 Motors Trigger input Trigger(t,C,D) Timing system Filters Timing interface Sensors Several components to control from a single command received from the timing • system Most of these components are controlled independently • 5

CIB (calibration interface board) Calibration Hardware 1 CIB Motors Trigger input Trigger(t,C,D) Timing system Timing interface Filters Hardware control Sensors 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) • 6

(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 • 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 • …if only we had such a system around… (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

��� ��� ������� ���������� �� ������ �� ��� �� ������ ������ ��� �� ������� ���� ����� ��� ������� ������� 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 artdaq hardware trigger timing trigger distribution 1 9

CTB @ ProtoDUNE 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

(Some) requirements 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

Conceptual design Calibration Hardware 1 Timing interface Hardware I/O (CDR + SFP+) SOC (uZed, picoZed, UltraScale, …) Clock out Network (buffered) interface (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+ • 12

DUNE vs ProtoDUNE 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

Open Questions 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

Summary 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