Speakers
Description
The LHCb-UpgradeI experiment has adopted a heterogeneous computing-based trigger system that relies on the reconstruction of all collision events, occurring at 30MHz. In this context, a two-dimensional FPGA-based cluster-finding architecture has been developed to reconstruct in real time hit positions in the vertex pixel detector, capable of processing $\sim10^{11}$ hits/second, and freeing computing resources of the high-level-trigger.
We report on developments and design optimizations of the cluster-finder firmware, based on the operational experience acquired in 2024 while running at the LHCb-UpgradeI design luminosity, as well as new firmware implementations to support the high-occupancy conditions unique to the LHC Heavy-Ion program.
Summary (500 words)
Architecture overview
Designed as a self-contained block of the VELO early DAQ stage (Fig.1), the clustering firmware receives as input the coordinates of active pixels in a given event and returns, on-the-fly, the centers of mass of the reconstructed clusters. Within the VELO framework, the detector is read in 2x4 pixel blocks called SuperPixels (SPs). Clusters can be made of pixels belonging to a single SP (isolated) or to contiguous SPs (with neighbors). SPs are flagged as isolated in a dedicated block and they are resolved in clusters using a LUT. Clusters extending over more than one SP are resolved by filling a set of matrices with non-flagged SPs (Fig.2). Each matrix can contain 3x3 SPs and the coordinates of the SPs that can be accommodated in the matrix are set by the first SP that fills the matrix. If the coordinates of a SP belongs to a matrix, the SP fills that matrix otherwise it checks the next matrix in the set. If a SP does not belong to any previously filled matrix, it fills a blank one. Once all SPs have been processed, each pixel in each matrix verifies if its neighbor pixels belong to some pre-defined search patterns and multiple cluster candidates are identified.
pp design optimizations
A baseline version has been integrated in the readout boards of the VELO detector since the beginning of the Run3, providing excellent performances in 2022-2023 data-taking, saving 11% of the HLT throughput and 30% of the VELO output bandwidth. Extrapolation up to the design LHCb running conditions showed that the baseline implementation of the firmware could not cope with the expected interaction rate for the 2024 data-taking (Fig.3). The firmware design has been improved in different steps, aiming at speeding-up the slowest components. The firmware has been validated during the 2024 data-taking period and is running as default in the LHCb data-acquisition chain, allowing for new real-time measurements (luminosity and beamspot parameters) to be performed at the readout level. The firmware improvements, such as the timing and logic optimization of the Isolation Flagging component and the balancing of the data loads both at the output and in the internal propagation of the data frames, will be described in this report.
Heavy-Ions design implementation
The 2024 LHC Heavy-Ion program provides an excellent stress test to evaluate the performance of the architecture in high-occupancy scenarios that emulate the expected conditions of Run5. In order to reconstruct with high-quality the pixel-clusters, the much higher occupancy during heavy ions collisions requires a significantly higher usage of logic resources than needed for pp collisions. Given the actual limited availability of resources in the FPGA, a looping mechanism (Fig.4) has been implemented in order to increase the effective number of matrices, without increasing the resource usage. This mechanism, optimized to be accurate on big event and fast on smaller one, has been used for the first time in the 2024 heavy ions fills, and will be reported here for the first time along with quantitative results.