Porting Allen to RISC-V 64

Allen is the LHCb HLT1 Trigger Software Framework. It is a large and complex codebase, with many dependencies and execution paths. Porting it to a new architecture is an interesting challenge. It does have several backends supported natively, but RISC-V is not one of them. But why not try to see if we can make it work?

So I started this as a simple-sounding experiment:

Can Allen build and run on riscv64?

That question is too vague to be useful. "Run Allen" can mean many things: CUDA, HIP, CPU, standalone, Gaudi-integrated, full HLT1, a tiny sequence, native hardware, cross-compilation, QEMU, monitoring, no monitoring, real input, synthetic input, and so on.

So the first thing I had to do was make the target smaller.

The goal became this:

Build Allen for riscv64 Linux, using the standalone CPU backend, and run a

small real sequence on a small MDF input.

No CUDA. No HIP. No RVV optimization. No throughput claim. No full LHCb stack integration. The point was portability, not performance.

The first milestone was a 10-event velo run inside a riscv64 QEMU system VM, with Allen linked against a ROOT build made natively inside that VM. It read the input MDF, ran the VELO sequence, completed processing, and wrote a ROOT monitoring file.

After that worked, I pushed the same path further and tried the full default HLT1 sequence, hlt1_pp_default. That also ran on riscv64, with one important detail: the Debug build was too slow under qemu-system, but the Release build completed a one-event full-HLT1 smoke test and wrote a ROOT monitoring file.

This post is about the path to get there. Not just the final version, but the debugging trail: what I checked first, what failed, why I changed direction, and what ended up being the reproducible route.

Starting with the smallest useful target

[!NOTE]

All the code and scripts are available in the Allen repository in melashri_riscv branch.

Allen has several possible execution paths, and choosing the wrong first target would…