Skip to content
All projects

ML on Edge Hardware

Real-Time Energy Regression GNN on FPGA

Carnegie Mellon University · CMS / CERN · 2024 – 2026

Designed and trained a dynamic GNN that regresses particle energies in real time for the CMS hardware-trigger upgrade, improving resolution ~20% over the classical baseline. Co-designed its streaming dataflow implementation on a Xilinx Alveo U50 FPGA at 0.28 ms latency, published as DGNNFlow.

The problem

The CMS detector at the LHC produces collision data at 40 MHz. Its hardware trigger has microseconds to decide what to keep — a decision made in FPGA firmware, not software. Reconstructing particle energy accurately at this stage directly improves what physics the whole experiment can access downstream.

Classical energy estimates leave resolution on the table because they treat detector hits independently. The relationships between hits carry information — which is exactly what a graph neural network can exploit, if it can be made to fit a fixed hardware latency and resource budget.

The model

I built a dynamic GNN that constructs a graph over detector hits and learns to aggregate neighborhood information into a per-object energy estimate. "Dynamic" means the graph edges are computed on the fly from the input, rather than fixed ahead of time — more expressive, but harder to map to streaming hardware.

Training used quantization-aware training so the model is accurate at the reduced numerical precision the FPGA runs. The result improved energy resolution by roughly 20% over the classical baseline.

Dynamic GNN architecture diagram: detector hits to graph to energy regression head.
Dynamic graph construction over detector hits, feeding an energy-regression head.

Getting it onto hardware

Accuracy is only half the job — the model has to run inside the trigger latency. I contributed to a streaming dataflow architecture (published as DGNNFlow) that maps dynamic GNN inference onto a Xilinx Alveo U50 FPGA, hitting 0.28 ms end-to-end latency while preserving the resolution gains.

This is the part that most resembles production ML engineering: co-designing the model and its deployment target together, trading numerical precision and architecture choices against a hard latency-and-resources budget.