Note N01 · CERN openlab · CMS Level-1 Trigger
Measured against your own flow
End-to-end latency through an AI Engine array on a Versal VEK280, measured on hardware, came in 1.25 % from what Vitis predicted. The agreement is the result. It only held because of where the probes went.
Measured on VEK280 hardware
Vitis hw_emu and aiesimulator
Deviation, four-head attention, four sequential AIE passes
Scope
At CERN openlab, for the CMS Level-1 trigger upgrade toward the High-Luminosity LHC, I built the programmable-logic side of a real-time transformer-based anomaly-detection pipeline on a Versal AI Edge VEK280 (VE2802). The model was someone else's. The path that keeps it fed was mine.
Stating that boundary precisely matters, because the interesting claim in this note is about measurement rather than about machine learning.
What was built
axis_fifo_core, a dual-clock AXI4-Stream FIFO with block-burst admission logic, bridging AXI4-Stream input into the AI Engine array.- An asynchronous FIFO for clock-domain crossing, plus an elastic output buffer.
axis_broadcast, distributing the input stream to two AIE input PLIOs through two input FIFOs.- Two latency probes, both in the programmable-logic domain, placed before the input FIFO and after the output FIFO.
- The full memory streaming path: PS to PL FIFO to AIE to PL FIFO to PS.
- PCIe-based external host control, with the freed PS core repurposed for telemetry and health monitoring.
- A Python generation flow around
build.toml:gen_link.py,package_xo.py,workspace.py,build.py.
The finding
The agreement between hardware and simulation only holds if both probes sit entirely inside the programmable-logic domain. Instrumenting across the processing-system boundary folds host-side scheduling jitter into the measurement, and the number stops meaning anything. It does not fail loudly. It produces a confident figure that is wrong.
Anyone benchmarking AI Engine designs against aiesimulator and
finding a large discrepancy should check probe placement before concluding
anything about the tool.
What this does not claim
34.02 µs is not a competitive latency figure, and I am not presenting it as one. The workload was four-head attention run as four sequential AIE passes, one per head, and that sequential decomposition is the reason. A mapping with fewer passes and higher data reuse would look materially different.
What the result establishes is that the model of the system was correct before the board existed, which is a claim about rigour rather than about speed.
The honest crossover
I also established the condition under which the AIE-ML array outperforms a programmable-logic DSP implementation of the same workload, rather than assuming it does. The crossover depends on arithmetic intensity and on how many AIE passes the mapping needs.
For workloads that decompose into few passes with high reuse, the array wins clearly. For a four-pass sequential decomposition it is much closer, and a DSP implementation stays competitive. Sustained utilisation on the real mapping decides this, not peak throughput.
What I would work on next
The generation flow around build.toml was the part I rebuilt,
because the stock path did not fit a multi-PLIO broadcast topology. The gap
between what an array can do and what a competent engineer can get it to do
in an afternoon is where adaptive compute wins or loses designs.
That gap is now my research: compiler and runtime support for a CGRA toolchain at EPFL's Embedded Systems Laboratory, currently an on-array DMA engine and the compiler support that decides to use it.