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 the most 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 certified at all, and today, for AI inference on FPGA, it largely cannot.
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 demand a degree of predictability and traceability that modern AI inference, and the FPGA designs that carry it, cannot yet demonstrate. So the domains with the most to gain from on-board intelligence are precisely the ones that cannot certify it. Meanwhile, inference is now the main thing AI hardware does, and its energy cost keeps pushing it out of the data centre and onto the device itself. Closing that gap would be worth a great deal.
Safety-critical
Aircraft, satellites and defence systems cannot field intelligence they cannot certify. A certifiable path is what would let these domains use embedded AI at all.
Autonomy
A system that reasons on-board does not depend on a network link that may be slow, absent or contested. Edge inference is what lets a machine decide in the field, in milliseconds, on its own.
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
Efficiency is the easy half. Proving it safe is the hard one
Fitting an AI model onto an FPGA already means choosing between more possible designs than anyone can test by hand, and the usual estimates of how each will perform are unreliable. The deeper difficulty, in a regulated system, is assurance. Standards like DO-254 and ECSS were written for hardware whose behaviour can be traced and justified end to end, and neither modern AI nor the tools that map it to silicon fit that mould yet.
A combinatorial space
Precision, parallelism, dataflow and resource allocation multiply into far more combinations than anyone can try by hand. Most are poor, and the good ones are not obvious in advance.
No certified path yet
Hardware-assurance standards were written before machine learning. There is no accepted recipe for certifying a learned model and its implementation, which is exactly the gap this research looks at.
Traceability all the way down
Certification asks that every design decision be justified and traced. An automated search that cannot explain why it chose a given implementation is difficult to defend to an authority.
Deterministic timing
Certified systems need an answer within a fixed deadline, every time. Optimising average speed is not enough when it is the worst case that has to be bounded and proven.
Estimates that lie
Design tools predict speed and resource use up front, but those predictions often diverge from what the hardware actually does, so a promising design can disappoint only after hours of build time.
Accuracy on the line
Shrinking a model to fit can cost accuracy. The hard part is pushing efficiency to its limit without quietly degrading the very behaviour the model was chosen for.
04 Our approach
Traceable to the gate, and searched rather than guessed
We treat the step from trained model to hardware as something to be proven, not trusted. Three choices carry the work, and together they are what makes a certifiable result plausible where an off-the-shelf toolchain forecloses it.
Transparent to the gate
The implementation stays legible all the way down to the logic gates, with no opaque high-level-synthesis or vendor-IP black box in the middle. Assurance standards ask for that transparency. The usual high-level toolchains lose it.
Verified against the reference, bit for bit
The hardware is checked to reproduce the trained model exactly, to the last bit, not merely to approximate it. A whole class of errors between the certified model and the one actually deployed is removed by construction.
Trade-offs searched, not hand-picked
Accuracy, logic area, timing and power genuinely conflict, and no single design wins on all of them. Instead of hand-crafting one point, we explore the space automatically and surface a set of implementations, each individually traceable, to be chosen against real priorities.
05 Where it stands
The pipeline runs. Certification is the open front
This line predates the company: it grew out of avionics engineering practice, which is why certifiability is the design constraint. It is applied research, not a finished product. The pipeline runs end to end, from a trained model to hardware verified against it, and early results justify continuing. The approach is aligned with the emerging assurance frameworks for airborne AI, DO-254 and ECSS among them. The method itself is deliberately not described here and is protected by a dated proof of anteriority. Sovereignty and freedom from vendor lock-in follow from the same design choices.