Inside Embedded AI: AMD Versal AI Edge — Ep 3: AI That Survives Radiation

Inside embedded AI. AI that survives radiation. Episode 2 was about beating a clock. This one is about outlasting an environment that's actively trying to corrupt your hardware, for years, with nobody able to walk up and fix it. This episode: what radiation actually does to a chip in orbit, and a real technique that cut the damage from it by more than twenty-fold. Modern spacecraft sensors generate far more data than can be sent back to Earth — the download link is slow and precious, and most of what a sensor captures isn't interesting. The answer is to process data onboard: let the AI sort the routine from the remarkable, and only send home what actually matters. That means running real AI inference in orbit, on the spacecraft itself, unattended. Which raises an obvious question: what happens to that chip when it's hit by radiation. Here's the mechanism. Charged particles from space radiation can strike a chip's memory and flip a single bit — a stored zero becomes a one, or the other way round — with no warning and no physical damage you could ever see. One flipped bit sounds small. But if that bit was holding part of an AI model's weights, or a critical calculation mid-flight, the chip can produce a wrong answer with total confidence, and nothing tells you it happened. The higher the orbit, generally, the worse this problem gets. The technique the research tested is refreshingly low-tech in concept: instead of doing a calculation once, do it three times, in three separate parts of the chip, and compare. If all three agree, you trust the answer. If one disagrees with the other two — because radiation flipped a bit in exactly that one — you trust the majority and move on, without the system ever producing a wrong answer or even needing to notice something went wrong. It costs extra chip resources to run the same thing three times. What it buys is an answer you can actually trust, unattended, for years. Our research found this tested directly: researchers deliberately simulated radiation-style bit-flip errors against real deployed AI models on this class of chip, with and without the triple-redundancy technique applied at different points in the hardware. Result: chips with the redundancy technique applied showed, on average, a twenty-four-and-a-half-times reduction in the number of critical bits vulnerable to radiation-induced error, compared with the same chip unprotected. Not a marginal improvement. A genuine order-of-magnitude jump in how much radiation the system can shrug off before it matters. The mistake teams make deploying AI hardware into harsh environments: assuming that because a chip is fast and capable in a lab, it's ready for deployment somewhere nobody can service it. A chip built for a data centre floor and a chip built to survive years of radiation exposure can be the exact same silicon — the difference is entirely in how it's configured and protected, not in the raw part number. Skipping that step doesn't save time; it just moves the failure from the design phase to the in-service phase, where it's far more expensive to fix. For any unattended, harsh-environment deployment: dependability has to be engineered in, not assumed. Three things worth remembering from this episode, and from the course. One: embedded AI hardware built for extreme speed and embedded AI hardware built for extreme reliability can be the same underlying chip — deployed differently. Two: a technique as simple as computing something three times and voting on the answer can turn a radiation-vulnerable system into a dependable one, by more than twenty-fold. Three, across all three episodes: the right embedded AI chip is the one that fits your actual constraint — a deadline, a certification, or an environment — not the one with the biggest headline number. That's embedded AI, from three angles: what the hardware actually is, a real system racing a hundred-microsecond clock, and a real system outlasting radiation in orbit. Same underlying idea running through all three — put the compute where the deadline or the environment actually demands it, and engineer for the worst case, not the average one. Want to try the real workflow yourself? A downloadable project — the real quantize, compile, and deploy steps from this course, working code you can run — is linked below. If this course was useful, subscribe — one short analysis every week, no noise.