The AIDA-2020 TLU: a Flexible Trigger Logic Unit for Test Beam Facilities

The AIDA-2020 Trigger Logic Unit (TLU) has been designed to be a flexible and easily configurable unit to provide trigger and control signals to devices employed during test beams, integrating them with the beam telescope. The most recent iteration of the TLU (v1E) has been re-designed within the AIDA-2020 project to integrate with hardware used in beam facilities. Configuration and communication with the TLU are performed over Ethernet. It can be employed as a stand-alone unit or be deployed as part of the EUDAQ2 data acquisition framework, which allows it to connect to a wide range of LHC readout systems. The TLU can operate with a sustained particle rate of 1 MHz and with instantaneous rates up to 20 MHz. In the current firmware iteration, the unit can time-stamp incoming signals with a resolution of 1.5 ns. The hardware, firmware and software designs of the TLU are freely accessible and benefit from constant inputs and upgrades from experienced users. TLU units have already been deployed successfully in beam lines at CERN and DESY.


Introduction
The AIDA-2020 [1] project has the aim of advancing detector technologies by facilitating hardware development and testing across European institutes, universities and technology centres. Its program includes offering test beam and irradiation facilities where users can find a standardized selection of software tools, data acquisition systems and beam hardware. Anyone who has been involved in beam tests of detectors will be familiar with the time involved in setting up their own hardware, integrating it with the beam line tools, defining the trigger and getting acquainted with the software before being able to take any data with the Device Under Test (DUT). The AIDA-2020 TLU is designed to minimise the setup time by providing a shared, flexible and programmable unit that can potentially substitute for tens of VME modules and a forest of cable connections.

Overview
DUTs can be connected to the TLU by means of High-Definition Multimedia Interface (HDMI) ports. The TLU can issue each DUT with trigger and synchronization signals as well as a system clock. The unit accepts asynchronous input signals from external sources, such as beam scintillators, and can generate and distribute a global trigger based on any logical combination of the individual trigger inputs. Upon issuing a global trigger to the DUTs, the unit stores the time-stamps of the individual inputs in an internal buffer to be read out over Ethernet. DUTs can send signals back to the TLU to indicate that they are busy. The response of the TLU can be programmed, for instance stopping issuing any further trigger until the DUT de-asserts its busy line. The TLU has been designed to integrate with existing pixel beam telescopes that operate in EU-DET/AIDA mode [2] and includes features that allow future expansion with other modes of operations. Communications between the Data Acquisition system (DAQ) and the TLU use the IPBus [3] protocol, a well-established and reliable protocol widely used in the CMS [4] and ATLAS [5] experiments at CERN. Amongst its main strengths, IPBus offers a reliability mechanism, which allows the client to detect and recover loss of packets. A set of Python scripts is available to configure, control and read out the TLU, allowing it to be used as a stand-alone tool. However, the full potential of the TLU is achieved when used in conjunction with the EUDAQ2 data acquisition framework [6]; EUDAQ2 is a powerful and modular framework that allows the users to integrate their own hardware with beam-telescopes software. A dedicated software module (called the producer) has been written for the TLU, allowing the easy inclusion of the TLU functionalities in any test facilities that provide the EUDAQ2 framework and hardware.

Hardware
The current version of the hardware (v1E) is an evolution of the trigger logic unit initially designed to work with EUDET telescopes [7,8]. The core element of the unit is a Printed Circuit Board (PCB) mezzanine designed at the University of Bristol. The mezzanine has no programmable logic so it must be connected to a Field Programmable Gate Array (FPGA) carrier board via a low pin count FPGA Mezzanine Card (FMC) connector. The choice of having a separate carrier for the programmable logic was made to reduce the complexity of the design and maintain a high level of flexibility in terms of FPGA choice. All the design and technical files are freely available on an open hardware repository [9]. A detailed user manual for the TLU is available online [10]. As part of the commitment to the AIDA-2020 project, a batch of units were manufactured and packaged for deployment in test beam facilities. These units include an Enclustra FPGA module based on the Xilinx Artix 7. An auxiliary board, installed with all the TLUs, can be used to provide power and control voltage to four photomultipliers. Two different enclosures designs were produced for the TLU: a table-top unit (figure 1) and a 19-inch rack mounted unit (figure 2). The table-top unit requires a 12 V supply to operate and, when fully configured, consumes about 15 W. The rack-mounted unit is identical to the table-top one with the exception that it uses 220 V mains supply and has an additional display to visualize information.

Interfaces
The TLU can be configured to generate trigger signals based on the combination of up to 6 inputs. The signals, usually provided by a Photo Multiplier Tube (PMT), are routed to the TLU using single-pole LEMO connectors1 and are fed to fast discriminators with independently configurable thresholds. The thresholds can be adjusted in the range [-1.3, +1.3] V with 40 µV resolution by means of a 16-bit Digital to Analog Converter (DAC). The input stage is protected by clamping diodes that limit the voltage within the range [-5, +5] V. Any of the 2 6 combinations of the inputs can be flagged as a valid word to issue a global trigger and multiple words can be defined in logical OR. This allows the user maximum flexibility in defining the trigger condition for their experiment. One of the LEMO inputs can also be configured to receive a special synchronization signal (BEAM) from the beam-line. The user can choose to use the BEAM input as a special veto signal and program the TLU to only issue triggers within a  configurable time window relative to the reception of the BEAM, as described in section 4. The unit can provide 12 V power and control voltage to up to 4 photomultipliers by means of dedicated 9-mm LEMO connectors2. The control voltage can be configured in the range [0, +1] V using 16-bit DACs. During normal operation the TLU exchanges control signals with the DUTs according to one of the modes of operation described in Section 4. The DUTs are connected using four standard HDMI connectors. All control signals (clock, trigger, busy, control, spare) are Low Voltage Differential Signaling (LVDS) 3.3 V logic and use bi-directional half-duplex buffers so that any differential pair can be configured to feed signals from the DUT into the TLU, or from the TLU to the DUT. Additionally, the unit can provide +3.3 V power to the DUT on a dedicated pin of the connector. To maintain retro-compatibility with existing hardware, the pin-out of the HDMI connectors is the same as used in previous versions of the TLU (table 1). A Small Form-factor Pluggable (SFP) interface can be used to connect transceivers to the TLU. The data stream from the transceiver is processed by a Clock and Data Recovery (CDR) and fed to the FPGA. The recovered clock can be used as a reference for the on-board clock chip. The SFP interface has been used to successfully exchange data using a 250 MHz clock. This feature, not 2LEMO part number EXP.0S.304.HLN. Table 1: HDMI pin mapping for the device under test. The pin-out is inherited from the CALICE ILC calorimeter project and has been kept unaltered to allow back-compatibility with the previous TLUs.

HDMI PIN TLU SIGNAL HDMI PIN TLU SIGNAL
SP ARE required in the AIDA-2020 mode of operation, allows the TLU to be used as a timing distribution system, as described in Section 6. All communications between DAQ and TLU occur over a RJ45 interface directly connected to the FPGA: by using the IPBus protocol, the user can send configurations commands to the TLU as well as retrieve status information and data from it. In order to easily update the firmware, the unit has a Universal Serial Bus (USB) interface directly connected to the Joint Test Action Group (JTAG) pins of the FPGA. A secondary USB interface allows connection to the universal asynchronous receiver-transmitter (UART) port of the device to enable the possibility of connecting to the TLU using a serial interface. An additional two-pin LEMO connector3 is configurable as either clock output or input, as explained in the next section.

Clock capabilities
The TLU hosts an advanced clock multiplier and jitter attenuator [11] that can be programmed to provide any clock frequency from 100 Hz to 1028 MHz. Users can modify the configuration file to generate any frequency suitable for their project. Each DUT is connected to a dedicated clock output so that, potentially, each device can be operated with a different clock frequency. The clocks are distributed to the DUTs via the HDMI connection. A clock signal is also available on a differential LEMO output on the front panel. When using the TLU as part of an AIDA-2020 test-beam infrastructure, the chip is configured by default to provide a 40 MHz clock. This clock is fed to the DUTs and used to provide time stamps for the trigger signals. The time stamps are stored in two separate registers, one containing a coarse stamp in 25 ns units and one containing a finer stamp in 1.56 ns units (obtained by clockmultiplication within the FPGA). The fine time-stamp is recorded separately for each input.
In order to lock the internal Phase-Locked Loop (PLL), the TLU requires a reference clock of 50 MHz; normally this is provided by an on-board crystal but in some scenarios it might be desirable to use a specific clock source to prevent random phase shifting. This can be achieved 3Part number EPG.00.302.NLN. by changing the reference source: the unit can be configured to retrieve the reference from the differential LEMO on the front panel, from one of the DUT connectors, or from a clock retrieved from the SFP.

Firmware
The current version of the firmware is designed to be deployed on an Enclustra Mars AX3 FPGA and uses an Artix 7 as target. The files are available from a Git repository [12] so that any user can fork and modify them according to their needs. The firmware contains a series of registers that can be addressed to configure any operational aspect of the TLU. Two software components of IPBus, the ControlHub and µHAL, allow the implementation of a reliability mechanism as well as providing an end-user Application Programming Interface (API) to read and write the IPBus registers.

Software
In order to simplify the usage of the unit, the TLU can be used in conjunction with the EUDAQ2 framework. To this purpose a TLU producer is available in the EUDAQ2 Git repository [13]. As with any other EUDAQ2 producer, the hardware configuration can be defined by means of two configuration files parsed by the run control state machine. Details on the configuration parameters and their meaning are provided in the TLU user manual.
The producer can access all TLU registers via the abstraction provided by µHAL. It handles the commands from run control and provides high level configuration to the unit. It also reads the data buffer in the TLU and sends the corresponding stream of data to the EUDAQ data formatter. All the functionalities of the TLU EUDAQ2 producer are also available in a Python command line interface. This allows users to test and debug the TLU as a stand-alone unit, without having to install the EUDAQ2 framework.

Modes of operation
The TLU offers a flexible and simple way of implementing any logical combination of the six input signals and producing a corresponding trigger output that is then distributed to the DUT. Any of the 2 6 = 64 combinations of the input signals can be selected to provide a valid trigger function. To account for differences in cable lengths, the input signals can be stretched and/or delayed in 6.25 ns units (up to 190 ns) ( figure 3). Additionally, the unit can be configured to periodically generate internal triggers as a way to debug hardware without having to rely on external detectors. When a valid trigger is formed, the TLU creates an event data structure and stores it in an internal event buffer that can be read out via IPBus. Up to 1356 events can be stored in the buffer. The structure of a data event is shown in figure 4 and is based on six 32-bit words: • type (4-bits) contains information about the type of trigger (for instance to distinguish internally generated triggers from triggers due to input signals).
• trigger data (12-bits) indicates which of the six inputs were active when the trigger was generated.  18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1   • coarse time-stamp (48-bits) is used to tag each trigger with respect to the system clock. Under normal conditions this counter increases in 25 ns units.
• fine time-stamp (8-bits): for each of the inputs, a 5-bit fine time-stamp is stored and padded to 8-bits. This counter increases in 1.5 ns units.
• reserved (8-bits) these bytes are reserved for future expansions of the TLU hardware.
• spare (32-bits) this word is reserved for future expansions of the EUDAQ2 producer.
During normal operation with EUDAQ2, the TLU can sustain a continuous trigger rate of 1 MHz with instantaneous rates up to 20 MHz.

Handshake
Valid trigger signals are propagated to any DUT connected and enabled. The TLU can implement different handshake protocols depending on the type of device connected and the selected mode of operation. Two main modes of operation are traditionally referred to as EUDET mode and AIDA mode. EUDET mode is also referred to as trigger handshake mode, while the AIDA mode is TRIGGER   T0  T1  T2  T3  T4  T5  T6  T7  T8  T9 T10 T11 T12 T13 T14 T15 DUT BUSY DUT CLOCK TLU STATE ACTIVE VETO ACTIVE SWITCH b t Figure 5: EUDET handshake mode: the TLU is unable to issue any trigger until the handshake protocol is terminated. The total handshake has a duration of ∼450 ns referred to as simple handshake mode. Each DUT connected to the unit can operate in either mode independently. When in EUDET mode (figure 5): 1. Upon generating a valid trigger, the TLU asserts the TRIGGER line.
2. On receipt of the TRIGGER signal, the DUT asserts the BUSY line.
3. The TLU acknowledges the DUT being busy by de-asserting the TRIGGER line and switching its control to the output of a shift register containing the trigger number. As long as BUSY is active the TLU cannot issue any further trigger to any device.
4. The DUT controls the data transfer by toggling the DUT CLOCK line. Data changes on the rising edge and the least significant bit of the trigger data is shifted out first. Only the least significant 15 bits of the 32-bit trigger counter are clocked out. If more than 15 clock pulses are issued on the DUT CLOCK line the TRIGGER output is set to zero. The DUT should issue 16 clock pulses in order to clock out the 15 bits of the trigger number and return the TRIGGER line to logical low. This avoids glitches on the TRIGGER line when the DUT de-asserts the BUSY line.
5. The DUT de-asserts the BUSY line whenever the shifting of the trigger number is completed and the detector is ready to accept a new trigger. At this point the system returns in the initial state.
In EUDET mode the fastest trigger rate is limited by the slowest detector in the system. As long as one of the DUTs is busy, the TLU is in a veto state and no further triggers can be issued. However, it is possible to configure the TLU to ignore the busy line on a specific device. In this case the handshake protocol will proceed in the same way as described, but that the BUSY line will affect only the DUT generating it. Therefore, the TLU will still issue triggers to any device which is not in a busy state. This modified handshake mode allows the system to operate at a higher trigger rate but has the drawback that different devices in a run can receive a different number of triggers, thus requiring the data to be realigned off-line. The AIDA mode of operation ( figure 6) adopts a simpler protocol: 1. When a valid trigger is formed, the TLU asserts TRIGGER synchronously with its internal clock  Figure 6: AIDA handshake mode. No data is exchanged between DUT and TLU; upon the reception of a trigger, the unit is ready to issue new triggers after 1 clock cycle unless a device asserts its busy line.
2. The line is maintained for one clock cycle and then de-asserted. At this point the system is ready for a new trigger.
3. If at any time the TLU receives a BUSY signal from a DUT, it will veto all incoming triggers while the signal is active.
Operating in AIDA mode means that no information is passed between the TLU and the DUTs with respect to the current trigger number. As such, normally it is necessary that all the devices register all the triggers received to ensure that the data can be correctly aligned at the end of the run. However, as in the EUDET mode, it is possible to configure the TLU to ignore the BUSY signal from specific DUTs. Choosing this mode of operation means that the only limiting factor to the trigger rate is the capability of the TLU of issuing triggers but has the drawback that a DUT will record a only subset of the total number of triggers issued. Re-alignment of the data must necessarily be performed off-line, for instance by comparing the time stamps of the recorded triggers.

Shutter signal
During standard operation, all inputs of the TLU are interchangeable in terms of functionality. However, it is possible to assign special behaviour (beam) to one of the inputs in order to act as a reference to operate a virtual shutter within the unit (figure 7). The TLU will issue the shutter signal to any DUT configured to receive it and only issue triggers while in the active part of the cycle. The DUT will start taking data only during a well-defined window with respect to the arrival of the beam signal. The feature can be useful if the device has limited buffer capability preventing it from taking data continuously. The relative time position of the active shutter window with respect to the input signal is configured by two parameters (SHUTTER_ON_TIME and SHUTTER_OFF_TIME in the diagram). A third parameter (VETO_OFF_TIME) is used to define when, within the shutter active window, the TLU can issue triggers to the DUT.

Distribution and usage
The version of hardware described in this work has already been distributed to CERN and DESY to be used in test beam campaigns. The first test of the AIDA-2020 TLU in its intended role, i.e. providing timing and synchronization signals to a prototype detector using the beam-test infrastructure, was carried out during a TORCH [14] hardware test in October-November 2017. During this campaign the TLU was successfully used to synchronize data from the AIDA beam-telescope and a prototype from the TORCH detector R&D project [15]. Since then, the AIDA-2020 TLU has been available at both DESY and CERN, typically in parallel with the old EUDET TLU to allow users to familiarize themselves with the new unit, while the AIDA TLU slowly replaces the old EUDET TLU in the beam line facilities.

Use as a flexible master clock unit
Thanks to the flexibility in its design, the TLU was also adopted to act as master clock unit in the protoDUNE experimental setup [16]. Figure 8 shows a schematic representation of the master synchronization distribution. The unit receives synchronization and trigger commands from the software DAQ, as well as a precise 10 MHz clock reference. The internal clock generator is used to produce a 250 MHz clock, phase-aligned with the 10 MHz one, which is then encoded with the data using 8b/10b encoding. The data stream is broadcast to the endpoints via a series of optical and electronic fan-out units. For this application the unit is programmed with a dedicated firmware, developed in parallel to the one used for the AIDA2020 trigger unit.  Figure 8: Schematic representation of the TLU usage in the protoDUNE setup: the TLU exchanges synchronization signals with the instrumentation rack, receives commands from the DAQ and distributes an encoded data stream via its SFP interface.

Conclusions
The trigger logic unit developed for the AIDA-2020 program has successfully been deployed in real data-taking scenarios in several beam tests, allowing users to integrate their hardware with the EUDET telescopes. While it is fully back-compatible with the existing EUDET type telescopes, it introduces new modes of operation that increase the achievable trigger rate even in the presence of slow devices in the system. The new unit is fully integrated in the EUDAQ2 framework, allowing users to easily set-up their hardware using a set of consistent tools. As EUDAQ2 is the chosen DAQ at many beam-lines, including CERN and DESY, we expect that more and more users will soon become familiar with the AIDA-2020 TLU, abandoning the now out-of-date EUDET TLU. The flexibility of the hardware, combined with its availability as an open-source project and the continuous feedback from users and beam-line operators, means that new features can be added to the unit making it a truly powerful and easy-to-use device in a beam-test.