Dune cdr the Single-Phase Protodune

Chapter 2: Detector components
2–87
2.9.4
RCE-based readout
The data from the WIB are received by processing units called RCEs (Reconfigurable Cluster
Element), [9] which are housed in industry-standard ATCA shelves on COB (cluster-on-board)
motherboards that are designed at SLAC for a wide range of applications. The RCE is a SoC
from the Xilinx Zynq family and contains a full Linux processor system on the chip accompanied
by 1 GByte of DRAM. The primary processing functions of the RCEs are compression (and/or
zero-suppression) and buffering of the raw data and then sending data to the back-end upon the
receipt of an external trigger. Each COB carries eight RCEs for data processing, all connected to
each other via an on-board 10-Gbps Ethernet switch, which also sends data out of the COB to the
back-end DAQ PCs.
The interface with the WIB is provided via the ATCA compliant rear-board, the RTM (Rear
Transition Module). This application-specific board uses a set of QSFP transceivers to receive the
data from the WIB and an SFP+ (small form-factor pluggable) optical interface for communication
with the timing and trigger distribution system.
As the multiplexed data from the WIB come into the RCE FPGA fabric, it is de-multiplexed
and buffered into per-channel, fixed-time-length chunks (for instance 512- or 1024-ticks). These
chunks are compressed and written to the DRAM where the RCE processor waits for a trigger
(also handled by the FPGA) to arrive. Upon a trigger, the processor sends data for a fixed window
in time, including pre- and post-trigger time chunks for all channels, to the back-end PCs.
For ProtoDUNE-SP, 256 wires worth of data (2 FEBs) are sent to each RCE. Given that there
are 120 FEBs in ProtoDUNE-SP, 60 RCEs are needed to readout the full detector. These fit into
eight COBs which in turn reside in a single 14-slot ATCA shelf.
2.9.5
FELIX-based readout
The FELIX is a PCIe card receiving data on point-to-point links from the detector electronics and
routing those through a switched network to computers. The aim is to reduce to a minimum any
specific hardware developments and to fully rely on commercial networks and servers to perform
the DAQ tasks. For ProtoDUNE-SP, data from five WIBs (20 FEBs) are read out over ten 9.6-
Gbps links into two FELIX cards. Grouping time slices around a trigger signal, as well as data
compression, is dealt with in software. Similar to the RCE-based readout, the FELIX generates
artDAQ fragments to be sent to the event builder.
2.9.6
PDS and beam instrumentation data readout
A combination of externally triggered events and self-triggered events make up the PDS data.
The external triggers come from the beam instrumentation via the trigger system at 25 Hz. This
amounts to 118 Mb/s. The self-triggered data are induced by cosmic rays. A cosmic rate of
ProtoDUNE Single-Phase Technical Design Report

---

Chapter 2: Detector components
2–88
10 kHz is assumed, totalling 1106 Mb/s. The combined rate comes to ≈1.2 Gb/s. An alternative
scheme with just self-triggered header-only data with a resultant rate of ≈1.1 Gb/s is considered
for implementation if the former proves difficult.
2.9.7
Event-building software
Developed within the Fermilab Scientific Computing Division and already used for the 35-t proto-
type, artDAQ provides data transfer, event building, and event analysis functionality. This latter
feature includes built-in support for the art event analysis framework, also developed at Fermi-
lab [10], allowing experiments to run art modules for real-time filtering, compression, disk-writing
and online monitoring. As art is also used for offline analysis, a major advantage of artDAQ is
that it allows developers to easily switch between developing online and offline software.
ArtDAQ provides three types of processes, each of which fulfills a specific role. In the order of
upstream-to-downstream, these are boardreader processes, eventbuilder processes, and aggregator
processes. A given boardreader process is intended to be associated with a particular geographical
region of the detector, and provides hooks (in the form of C++ base classes) for an experiment’s
developers to embed experiment-specific code (called “fragment generators”), designed both to
upload configuration values to hardware and to read out the hardware. For ProtoDUNE-SP, the
full DAQ consists of 87+ boardreaders, in charge of the 60 RCEs, 24 SSPs, the timing system,
the Central Trigger Board, and at least one for the beam instrumentation. For testing purposes,
fragment generators can perform useful functions such as providing a “playback" mechanism,” and
modeling sudden or unexpected data flow events.
Downstream of the boardreader processes are the eventbuilder processes. An eventbuilder receives
data from every boardreader (a chunk of data from one boardreader corresponding to an event is
referred to as a “fragment”), and assembles the fragments for a given event into a raw, complete
data event. Optionally, filtering via art modules can be performed at this stage.
The most downstream process type is the aggregator. Traditionally in artDAQ-based DAQ sys-
tems, there are two aggregators, one in charge of writing data to disk and reporting aggregate
statistics (e.g., MB/sec), and one in which experiments can run art analysis modules for real-time
online monitoring. For ProtoDUNE-SP this model will change as artDAQ becomes more flexible
and throughput capability increases. The functionality of aggregators may be replicated in event-
builders. While this solution reduces the number of interprocess connections in the DAQ software,
the number of processes assembling raw events is the same as the number of processes writing to
disk.
For the 35-t prototype, artDAQ processes were controlled by a program called DAQInterface.
DAQInterface takes charge of launching the artDAQ processes, checking for error states, and shut-
ting down processes in an orderly fashion as needed, to avoid improperly closed output files, zom-
bie processes, etc. For ProtoDUNE-SP, some of the functionality of DAQInterface (e.g., querying
status) is shifting to JCOP (Joint Controls Project); DAQInterface code is reused as appropri-
ate/possible, to minimize duplication of effort.
ProtoDUNE Single-Phase Technical Design Report

---