Abstract
As from the run 3 of CERN LHC scheduled in 2022, the upgraded ALICE experiment will use a Common Readout Unit (CRU) at the heart of the data acquisition system. The CRU, based on the PCIe40 hardware designed for LHCb, is a common interface between 3 main sub-systems: the front-end, the computing system, and the trigger and timing system. The 475 CRUs will interface 10 different sub-detectors and reduce the total data throughput from 3.5 TB/s to 635 GB/s. The ALICE common firmware framework supports data taking in continuous and triggered mode and forwards clock, trigger and slow control to the front-end electronics. In this paper, the architecture and the data-flow performance are presented.
Highlights
Heart beat and time frame triggers indicating the boundaries between Heart Beat Frames (HBF) and Time Frames (TF) are distributed to the Common Readout Unit (CRU) via the Passive Optical Network (PON) network by the Central Trigger Processor (CTP)
For every HBF the CRU sends an acknowledge message to the CTP informing whether the corresponding HBF has been correctly received and forwarded to the First Level Processors (FLP)
The GBT_wrapper permits external and internal loop-back tests which allow the validation of the CRU-front-end electronics (FEE) communication and the CRU data path operation once installed in the system
Summary
The ALICE computing upgrade concept consists of transferring all detector data unfiltered (triggerless) to the computing system. Heart beat and time frame triggers indicating the boundaries between HBFs and TFs are distributed to the CRU via the PON network by the Central Trigger Processor (CTP). In this scheme, the task of the CRU is to collect the data continuously and to check the successful heart beat frame transmission to each first level processor. The CTP distributes heart beat triggers defining whether the corresponding HBF should be accepted (HBaccept—HBa) and forwarded to the FLP or deleted (HBreject—HBr). This scheme allows the data throughput to be adjusted to match the available bandwidth during commissioning and dedicated calibration runs. For every HBF the CRU sends an acknowledge message to the CTP informing whether the corresponding HBF has been correctly received (data received properly from all links involved in the data taking) and forwarded to the FLP
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
