01 The problem
A trained model and a certifiable system rarely speak the same language
AI models are designed on machines with almost unlimited power and memory. The systems that would gain from them, in the air, in orbit, on the battlefield, are the opposite: small, power-constrained, and often held to the strictest safety regulation there is. Between a model that works in the lab and one an aircraft or a satellite is actually allowed to rely on, there is a long road.
Part of that road is a translation step: deciding exactly how the model is laid out on the hardware. On an FPGA, a chip you reconfigure to match the task rather than a fixed processor, that means choosing among an enormous number of possible implementations. But in a regulated domain the real obstacle is not only performance. It is whether the result can be approved at all, and for a learned model running on an FPGA that question does not yet have a settled answer.
02 Why it matters
The systems that most need embedded AI are the ones least able to adopt it
Avionics, space and defence run on hardware that has to be proven safe before it is trusted, governed by standards such as DO-254 in aeronautics and ECSS in space. Those standards ask, among other things, for a degree of traceability and justification that modern AI inference, and the FPGA designs that carry it, struggle to demonstrate. The pressure is rising rather than easing, because the functions programmes now want on board, signal processing, perception and classification on sensor data, increasingly depend on learned models.
Physical constraints
On board, available power is limited, heat dissipation is constrained, the temperature range is wide, and ionising particles can alter the state of the logic. Each of these constraints reduces what the model's implementation has to work with: logic area, timing margin, power.
Autonomy
A system that reasons on board does not depend on a link that may be slow, absent or contested, and in the cases that matter here there is often no link to fall back on at all.
Sovereignty
Europe builds comparatively few high-end defence-grade processors. Extracting more from the silicon that can actually be sourced turns a supply constraint into a design advantage.
03 Why it is hard
Why is a trained model hard to implement efficiently on an FPGA?
A trained model does not drop onto an FPGA as it stands: an implementation has to be chosen, and the two workable routes do not cost the same. Handing that choice to an abstraction tool returns a result, but the transformation then belongs to the tool, and the evidence has to be rebuilt afterwards. Relying on human expertise keeps the justification intact, but explores a handful of points, without knowing what the ones it did not see were worth. It is that choice, rather than learning itself, that decides certifiability today.
What the implementation inherits
On a processor, a multiplication and a division each cost one instruction. In configured logic each becomes its own quantity of silicon and its own path depth, so the implementation pays for operators the architecture could use freely on a machine where they did not show.
A combinatorial space
Numeric format, parallelism, dataflow and resource allocation multiply into more combinations than anyone can traverse by hand. The space being discrete, nothing ensures that a good design sits next to another, and each point evaluated calls for a synthesis run.
Measurement comes after synthesis
Since a path's delay depends on where the logic lands and how it is routed, the speed and resource predictions made before placement and routing often diverge from the measurement. A promising design can therefore fail timing after hours of build.
Resources that do not substitute
Arithmetic units, on-chip memory, logic and routing form separate budgets, and spending one does not release another: the parallelism that buys latency needs memory ports to feed it. Relieving the binding constraint usually moves it elsewhere, without any single quantity that would let one design be called smaller than another.
Behaviour before requirements
ED-324 / ARP6983 covers how a model is developed and described, then routes the realisation back to the existing standards, software items to DO-178C and airborne electronic hardware to DO-254. The latter assumes requirements settled before the design, where here the intended behaviour sits in an artefact already trained, from which the verification requirements have to be written.
Traceability all the way down
Certification runs on requirements, design data and verification evidence that stay linked to one another. An automated search that cannot say why it returned a given implementation breaks that chain.
04 Our approach
Where the evidence comes from
We treat the step from trained model to hardware as a step that has to produce its own evidence. Three choices carry the work, and each one settles who produces that evidence and who has to check it.
Whose transformation it is
The design data an authority reviews is the hardware description itself, written rather than generated, with no vendor IP instantiated inside the device. High-level synthesis can be carried through certification, but the transformation then belongs to the tool, which moves the burden onto qualifying it or re-verifying what it produces.
Checked against the reference, bit for bit
Quantisation produces a reference model from the trained model, and that is where the accuracy cost is paid, once per format considered. Below that point the requirement is equality rather than approximation: the hardware has to reproduce that reference exactly, and simulation checks the match across the verification corpus.
The trade-off front
Accuracy, logic area, memory, timing and power conflict, and that list is not closed. No single design wins on all of them, so what the work returns is a non-dominated set: the implementations that cannot be improved on one objective without giving up another. Each is individually traceable, and choosing among them stays a programme decision, taken by people against stated priorities.