Speaker
Description
In the ALICE read-out and trigger system, the present GBT and CRU based solution will also serve for Run4 without major modifications. By now, the GBT protocol has been superseded by lpGBT, and the GBT ASIC is not available for new productions. Extensions of the ALICE system (e.g. the planned FoCal detector) will therefore require to use lpGBT while keeping the compatibility with the existing system. In this presentation we show the implementation and testing of a possible integration of the lpGBT-FPGA IP into the CRU firmware, allowing the extension of the present system, keeping it more versatile and future-proof.
Summary (500 words)
The present integration and testing work of lpGBT in ALICE CRUs will cover the following points:
Downlink: Interfacing the ALICE Trigger and Timing Subsystem and the lpGBT downlink is constrained by the given clock frequencies at the two sides. In ALICE, the clock and trigger are delivered to the CRU via 9.6 Gb/s 10GPON links. The CRU firmware exploited the advantage that this speed was just the double of the 4.8 Gb/s GBT downlink speed. This allowed that the 240 MHz clock recovered in the 10GPON receiver block could be used directly as the reference clock for the GBT downlink transmitters resulting a stable and deterministic clock and trigger transition from the 10GPON to the GBT. However, in the 2.56 Gb/s lpGBT downlink, the transmitter reference clock is 160 MHz resulting that we have to divide the recovered 240 MHz clock of the 10GPON by three and multiply by two. This clock division introduces new phase uncertainty which can be fixed by an additional phase alignment block which will recognize the position of certain unique header bits in the data. In new front-end developments it also has to be considered that the lpGBT downlink transfers less trigger data (64-bits instead of 120-bits) in every clock cycle.
Uplink: The lpGBT uplink supports 5.12 and 10.24 Gb/s speeds. The CRU hardware, the FPGA and the transceivers, all support 10 Gb/s, but the internal interfaces in the CRU firmware need to be modified to suit the lpGBT communication. Instead of the 120-bit GBT payload at 240 MHz, the link will now provide 128-bit or 256-bit data for the User Logic at 160 MHz. The new User Logic will have to run from this new interface clock. On the other side, the interface to the PCIe DMA engine will remain the same, feeding the dual-port FIFOs with 2x256 bits but with the new User Logic clock. The CRU driver, the low-level read-out software, and the O2 software stack will remain intact.
Slow Control: The lpGBT protocol still supports the 80 Mb/s control channels from the CRU to the front-end electronics. In lack of the GBT-SCA peripheral controller ASIC the front-end card designers can make use of the built-in controllers of the new lpGBT chip. The implementation of these control channels through the CRU firmware is transparent, thus the access of the of target devices on the new front-end cards needs only software development in the host computer of the CRU (FLP) and the detector control system (DCS).
Testing: The implementation will be tested with an VLDB+ eval board hosting a VL+ optical transceiver, the lpGBT ASIC, and an e-links interface through FMC connectors. For uplink testing the built-in packet generator of the ASIC will be used. Downwards, we will test the phase coherent clock and data recovery by an oscilloscope at the VLDB+ clock and e-link connectors. It is also possible to loop-back e-links at the FMC connectors and/or testing the communication with prototype front-end cards as soon as they get available.
