Second-Level Trigger (SLT) Overview

• Second-Level Trigger (SLT) is a software-based filtering layer positioned between the initial hardware trigger and final event reconstruction, ensuring prompt event selection.
• It employs fast algorithms such as topological and coarse reconstruction filtering to effectively suppress background noise and reduce false triggers.
• SLT systems leverage diverse architectures including FPGAs, CPUs, and GPUs to meet strict latency and bandwidth requirements in high-energy physics experiments.

Second-Level Trigger (SLT) denotes a real-time trigger layer that sits above an initial hardware trigger or first detection-unit trigger and below the final event recording or full reconstruction stage. In H.E.S.S. phase 2, the SLT is a topological filter for the 28 m Large Cherenkov Telescope operated in monoscopic mode (Moudden et al., 2010). In ATLAS and CMS, the term historically refers to, or is logically embedded within, the software-based High-Level Trigger farm that refines Level-1 selections (Collaboration, 2020). A later cross-experiment usage defines the SLT as the “first software trigger stage” between the initial hardware trigger and the final high-level selections in ATLAS, CMS, LHCb, and ALICE (Albrecht et al., 2024). In GRAND, the SLT collects First-Level Trigger times and amplitudes from multiple detection units, performs a fast, coarse reconstruction of the candidate air-shower, and applies geometrical and polarization cuts before a full readout is saved (Correa et al., 6 Jul 2025).

1. Terminology and placement in trigger hierarchies

A recurring source of confusion is nomenclature. In ATLAS Run 2, the second level was historically called the Second-Level Trigger and was unified into the High-Level Trigger, whereas the 2024 cross-experiment summary uses “SLT” for the first software trigger stage sitting between the initial hardware trigger and the final high-level selections (Collaboration, 2020). In H.E.S.S. and GRAND, by contrast, SLT names a distinct online selection block with explicitly described inputs, cuts, and latency targets (Moudden et al., 2010).

System	Upstream stage	SLT role
H.E.S.S. phase 2	L1 camera trigger on the LCT	Topological rejection of NSB and single-muon events
ATLAS and CMS	Hardware Level-1	Fast, coarse software reconstruction before final HLT selection
LHCb	Continuous readout	HLT1, a fully software stage running on GPUs
ALICE	CTS-synchronized continuous readout	First HLT pass for cluster finding, zero-suppression and partial tracking
GRAND	FLT-0 and FLT-1 at each DU	Array-level coincidence, coarse reconstruction, and background rejection

For ATLAS and CMS, hardware Level-1 reduces $40\ \mathrm{MHz}$ to $100\ \mathrm{kHz}$ with fixed latency, and the software trigger farm then performs refined selection (Albrecht et al., 2024). In LHCb Run 3, the SLT corresponds to HLT1, a fully software stage running on GPUs immediately after continuous readout; HLT2 then performs full offline-quality reconstruction on CPU (Albrecht et al., 2024). In ALICE, the Central Trigger System synchronises continuous readout but performs no physics selection, so the SLT role is assumed by the first pass of the High-Level Trigger (Albrecht et al., 2024). In GRAND, the SLT sits above the FLT and uses only $t_i$, $V_i$, detector positions, and the local geomagnetic field vector $\mathbf B$ to decide whether full readout should be preserved (Correa et al., 6 Jul 2025).

2. Operational motivations and constraint envelope

In H.E.S.S. phase 2, the central motivation is monoscopic operation of the fifth 28-meter telescope. The smaller 12 m telescopes have thresholds above $\sim100\ \mathrm{GeV}$, so to reach the lowest energies $(\lesssim50\ \mathrm{GeV})$ one must accept monoscopic triggers from the LCT alone. A naive monoscopic rate would be dominated by random coincidences of NSB photoelectrons, isolated muon triggers from distant hadronic showers, and cosmic-ray hadron and electron showers. Without additional filtering, the L1 camera-level trigger of the LCT would fire at tens to hundreds of kHz, while the front-end readout dead time limits the acceptable input L1 rate to $\lesssim100\ \mathrm{kHz}$ and the rear-end Ethernet bandwidth constrains the output event rate to a few kHz. The H.E.S.S. SLT must therefore suppress the vast majority of accidental NSB clusters and single-muon events in monoscopic mode, operate in real time with mean per-event latency $\lesssim50\ \mu\mathrm{s}$, remain reconfigurable on-site, and always accept stereoscopic coincidences with zero extra latency (Moudden et al., 2010).

In ATLAS Run 2, the two-level trigger system records data at an average rate of $1\ \mathrm{kHz}$ from physics collisions, starting from an initial bunch crossing rate of $100\ \mathrm{kHz}$0. Level-1 reduces the input to up to $100\ \mathrm{kHz}$1 in $100\ \mathrm{kHz}$2, and the HLT rejects $100\ \mathrm{kHz}$3 of L1-accepted events, with $100\ \mathrm{kHz}$4 and $100\ \mathrm{kHz}$5, implying an overall $100\ \mathrm{kHz}$6 (Collaboration, 2020). CMS describes the same design tension as a tradeoff between the complexity of the algorithms running on the available computing power, the sustainable output rate, and the selection efficiency. In 2012, CMS reduced $100\ \mathrm{kHz}$7 to $100\ \mathrm{kHz}$8, with $100\ \mathrm{kHz}$9 and an average CPU budget per event of $t_i$0 (Gori, 2014).

The broader LHC comparison emphasizes that constraint sets differ by experiment. ATLAS and CMS operate post-L1 at $t_i$1 and $t_i$2, with latency budget at SLT of $t_i$3 per event and end-to-end HLT of $t_i$4. LHCb HLT1 processes $t_i$5 continuous readout and reduces it to $t_i$6, while ALICE treats the first HLT pass primarily as an online compression and calibration stage with throughput reduction from $t_i$7 to $t_i$8 (Albrecht et al., 2024). GRAND states the goal even more explicitly: the SLT aims to reduce the prototype array central trigger rate from $t_i$9 to $V_i$0 by rejecting RFI with minimal inter-DU data transfer (Correa et al., 6 Jul 2025).

3. Algorithmic structure and decision logic

In H.E.S.S., every L1 camera trigger on the LCT sends a combined map of $V_i$1 pixels to the SLT, with each pixel encoded by two thresholds $V_i$2. The two binary maps are

$V_i$3

The SLT may apply denoising and clustering filters on $V_i$4, beginning with removal of isolated pixels,

$V_i$5

and may optionally demand clusters of size $V_i$6. A typical point-source algorithm then computes weighted Hillas moments on the combined map with

$V_i$7

forms the center of gravity $V_i$8, and accepts a true $V_i$9-ray from a known point source only if

$\mathbf B$0

A typical cut $\mathbf B$1 removes $\mathbf B$2 of single-muon triggers while retaining $\mathbf B$3 of $\mathbf B$4-quanta at $\mathbf B$5 (Moudden et al., 2010).

The H.E.S.S. example algorithm is explicitly staged. On each L1 trigger, the system first accepts immediately if TLCentral says “stereo.” Otherwise it loads $\mathbf B$6 and $\mathbf B$7, denoises by zeroing all pixels with zero first-neighbor sum, rejects if the result is empty, restricts to clusters $\mathbf B$8 by requiring a non-zero second-neighbor convolution, forms combined weights, computes $\mathbf B$9, $\sim100\ \mathrm{GeV}$0, and $\sim100\ \mathrm{GeV}$1 via fast lookup-table summation, and finally applies the $\sim100\ \mathrm{GeV}$2 cut (Moudden et al., 2010).

ATLAS and CMS implement a different but structurally analogous hierarchy. In ATLAS Run 2, HLT supervision nodes receive L1 RoI descriptor words, decide which ROS fragments to fetch, run fast trigger algorithms inside each processing unit, and, if the fast stage passes, execute offline-like precision algorithms for the final decision. A typical RoI-based chain performs calorimeter topological clustering, then fast tracking, then a precision stage with offline-like calorimeter and inner-detector reconstruction (Collaboration, 2020). CMS describes each HLT path as a chain of ever more CPU-intensive reconstruction and selection steps: seed on the L1 accept and specific L1 objects, perform fast regional reconstruction, then regional tracking in the silicon tracker, then higher-level object reconstruction such as Level-3 muons or Particle-Flow jets (Gori, 2014). This suggests a common SLT design principle: inexpensive regional or topological filters are used to prevent full-precision reconstruction from being executed on all accepted L1 events.

GRAND also uses staged rejection, but the observables are inter-station timing, footprint geometry, and polarization rather than calorimeter and tracker features. The SLT first fits a plane-wave-front model,

$\sim100\ \mathrm{GeV}$3

computes residuals $\sim100\ \mathrm{GeV}$4, and rejects any DU with $\sim100\ \mathrm{GeV}$5. It then fits an ellipse to the remaining $\sim100\ \mathrm{GeV}$6 points weighted by $\sim100\ \mathrm{GeV}$7, extracts $\sim100\ \mathrm{GeV}$8, and applies

$\sim100\ \mathrm{GeV}$9

Finally, it computes

$(\lesssim50\ \mathrm{GeV})$0

and requires $(\lesssim50\ \mathrm{GeV})$1 (Correa et al., 6 Jul 2025).

4. Hardware, software, and data movement

The H.E.S.S. topological SLT is a dedicated hardware system implemented on a 6U CompactPCI carrier board with rear I/O translating 64 LVDS links from the 256 front-end boards. The carrier hosts four Xilinx Virtex-4 FX12 mini-modules and one Virtex-4 FX12 evaluation board; each FX12 embeds a 32-bit PowerPC 405 at $(\lesssim50\ \mathrm{GeV})$2. The evaluation board collects incoming $(\lesssim50\ \mathrm{GeV})$3 bit-streams and dispatches work to the mini-modules via Xilinx I/O-SERDES fast links, while a Spartan-3AN handles cPCI-PCI switching, JTAG download, and slow control. Each FX12 has $(\lesssim50\ \mathrm{GeV})$4 DDR SDRAM for code, LUTs, and intermediate buffers, and the PowerPC APU unit allows offloading of custom accelerators to FPGA fabric while retaining C-callable function interfaces (Moudden et al., 2010).

ATLAS and CMS use software-trigger farms built from commodity servers. ATLAS Run 2 employed a software farm of $(\lesssim50\ \mathrm{GeV})$5 Processing Units, with accepted events built in the Sub-Farm Output and sent to permanent storage (Collaboration, 2020). The 2024 cross-experiment summary describes ATLAS as using $(\lesssim50\ \mathrm{GeV})$6 commodity Linux nodes in the HLT farm, FELIX read-out cards, a $(\lesssim50\ \mathrm{GeV})$7 Ethernet switch fabric, and the AthenaMT software framework. CMS is described as using $(\lesssim50\ \mathrm{GeV})$8 x86 servers in the Event Filter Farm, front-end data via $(\lesssim50\ \mathrm{GeV})$9 uTCA / AMC13 links, and the CMSSW framework to execute SLT sequences followed by the full PF-based HLT (Albrecht et al., 2024). CMS’s 2012 description already had the essential pattern: Read-Out-Boards, Builder Units, event assembly, Filter Units, and HLT algorithms on a large switched network fabric (Gori, 2014).

LHCb and ALICE extend the implementation space beyond CPU-only farms. LHCb HLT1 uses commercial servers hosting FPGA cards for $\lesssim100\ \mathrm{kHz}$0 event-building plus GPUs for parallel track reconstruction via the Allen framework, while HLT2 runs on an Event Filter Farm of $\lesssim100\ \mathrm{kHz}$1 CPU nodes using the Gaudi framework (Albrecht et al., 2024). ALICE uses First Level Processors, High-Level Processors, FPGA cluster-finding, and GPU kernels within a custom message-passing HLT framework built on ZeroMQ/MPI (Albrecht et al., 2024). GRAND, although described at the algorithmic level rather than at board granularity, is explicitly designed to achieve online rejection with minimal inter-DU data transfer (Correa et al., 6 Jul 2025). A plausible implication is that SLT implementation is not tied to a single platform: FPGA-resident logic, CPU farms, and GPU-centric real-time processing all appear in current practice.

5. Performance characteristics and rejection behavior

The H.E.S.S. evaluation makes the rate-reduction logic unusually transparent. Simulations and prototype measurements give L1 monoscopic rates from $\lesssim100\ \mathrm{kHz}$2 to $\lesssim100\ \mathrm{kHz}$3 for NSB alone, and $\lesssim100\ \mathrm{kHz}$4 particle background at $\lesssim100\ \mathrm{kHz}$5. After clustering on $\lesssim100\ \mathrm{kHz}$6, NSB is reduced by factors up to $\lesssim100\ \mathrm{kHz}$7, while particle background is unchanged. After the CoG cut $\lesssim100\ \mathrm{kHz}$8, single-muon triggers are reduced by $\lesssim100\ \mathrm{kHz}$9, electrons by $\lesssim50\ \mu\mathrm{s}$0, and the total monoscopic background becomes $\lesssim50\ \mu\mathrm{s}$1 for typical $\lesssim50\ \mu\mathrm{s}$2 combinations. For monoscopic $\lesssim50\ \mu\mathrm{s}$3-rays at $\lesssim50\ \mu\mathrm{s}$4, clustering retains $\lesssim50\ \mu\mathrm{s}$5, the CoG cut retains $\lesssim50\ \mu\mathrm{s}$6, and the overall L2 efficiency is $\lesssim50\ \mu\mathrm{s}$7. The minimum $\lesssim50\ \mu\mathrm{s}$8 efficiency is $\lesssim50\ \mu\mathrm{s}$9 at $1\ \mathrm{kHz}$0, then rises due to stereo. Mean latency is $1\ \mathrm{kHz}$1, with sustained peak throughput $1\ \mathrm{kHz}$2 (Moudden et al., 2010).

ATLAS Run 2 reports $1\ \mathrm{kHz}$3, $1\ \mathrm{kHz}$4, and overall $1\ \mathrm{kHz}$5. Average processing time per event is $1\ \mathrm{kHz}$6, with hard timeouts of 3 min in 2015, 5 min in 2016, and 7 min in 2017–18. Cost monitoring indicates a double peak in calorimeter clustering time due to RoI versus full-scan modes, and fast tracking at $1\ \mathrm{kHz}$7 per call with $1\ \mathrm{kHz}$8 of total CPU fraction (Collaboration, 2020). CMS in 2012 reduced $1\ \mathrm{kHz}$9, with $100\ \mathrm{kHz}$00 and $100\ \mathrm{kHz}$01. Its measured latency distribution had 50% of events processed in $100\ \mathrm{kHz}$02 and 99% in $100\ \mathrm{kHz}$03, while $100\ \mathrm{kHz}$04 summarized the pile-up dependence (Gori, 2014).

GRAND reports performance at the cut level. For events with at least 5 DUs of $100\ \mathrm{kHz}$05, the $100\ \mathrm{kHz}$06 cut keeps 95% of simulated showers and rejects 82% of background, the $100\ \mathrm{kHz}$07 cut keeps 95% of signal and rejects 98% of background, and the polarization cut $100\ \mathrm{kHz}$08 retains 95% of true-shower events while rejecting 23% of the background database. Taken together, the three steps promise to reduce the prototype array central-trigger rate by roughly an order of magnitude (Correa et al., 6 Jul 2025).

System	Input regime	Output or reduction
H.E.S.S. monoscopic LCT	L1 at tens to hundreds of kHz without extra filtering	Monoscopic background $100\ \mathrm{kHz}$09; accepted rate $100\ \mathrm{kHz}$10
ATLAS Run 2 HLT	$100\ \mathrm{kHz}$11	$100\ \mathrm{kHz}$12, $100\ \mathrm{kHz}$13
CMS 2012 HLT	$100\ \mathrm{kHz}$14	$100\ \mathrm{kHz}$15, $100\ \mathrm{kHz}$16
GRAND SLT	$100\ \mathrm{kHz}$17 prototype central trigger	$100\ \mathrm{kHz}$18 target

The cross-experiment whitepaper summarizes the broader operating regimes as $100\ \mathrm{kHz}$19 and $100\ \mathrm{kHz}$20 for ATLAS and CMS, $100\ \mathrm{kHz}$21 for LHCb HLT1, and $100\ \mathrm{kHz}$22 in the first HLT pass of ALICE (Albrecht et al., 2024).

6. Validation, scalability, and future trajectories

ATLAS Run 2 treats trigger evolution as a controlled software and operations problem. Its validation cycle included nightly builds with regression tests on $100\ \mathrm{kHz}$23 Enhanced-Bias events, weekly HLT reprocessing of $100\ \mathrm{kHz}$24 Enhanced-Bias events on the Grid using $100\ \mathrm{kHz}$25 CPU h, rate-prediction comparisons over 957 chains, and $100\ \mathrm{kHz}$26 HLT releases deployed during Run 2 (Collaboration, 2020). CMS likewise frames SLT design as continual optimization under pile-up and resource pressure, using seeding, prescaling, regional unpacking, and pile-up subtraction to keep farm cost within budget (Gori, 2014).

The HL-LHC literature shifts attention from classical CPU farms to heterogeneous architectures and larger buffered dataflows. CMS upgrade studies state that the HLT will face $100\ \mathrm{kHz}$27 at $100\ \mathrm{kHz}$28 and must reduce it to $100\ \mathrm{kHz}$29, with raw event size $100\ \mathrm{kHz}$30, DAQ network throughput of $100\ \mathrm{kHz}$31, and a $100\ \mathrm{kHz}$32 buffer of $100\ \mathrm{kHz}$33. To remain within farm capacity, the average per-event CPU time must be held below $100\ \mathrm{kHz}$34, driving algorithmic optimization, multi-threading, and hardware accelerators such as GPU-accelerated pixel tracking (Tomei, 2020).

The 2024 LHC comparison presents a related but more explicitly stage-split outlook: ATLAS and CMS aim to increase their SLT input rates to $100\ \mathrm{kHz}$35 while keeping output at $100\ \mathrm{kHz}$36, with target metrics $100\ \mathrm{kHz}$37, $100\ \mathrm{kHz}$38 to final HLT, and $100\ \mathrm{kHz}$39 on mixed CPU+GPU. The same summary states that LHCb and ALICE will largely extend their Run 3 SLT paradigms into Run 4, adding more GPUs and increased continuous-readout capacity (Albrecht et al., 2024). This suggests that “SLT” is increasingly best understood as a functional layer—fast software-trigger processing under strict latency and bandwidth constraints—rather than as a single fixed architectural component.