The Mode Dynamic Transponder and Haifuraiya flight-build teams have started work with the VCK190 (https://www.amd.com/en/products/adaptive-socs-and-fpgas/evaluation-boards/vck190.html). This is a Versal AI Core series evaluation kit. Volunteers are learning how radiation mitigation interacts with the FPGA resource budget on the flight target. The FPGA on the VCK190, the XQR Versal AI Core XQRVC1902, has a radiation tolerant part, so porting to this development board allows us to port to the same architecture as the space-qualified part.
One of the questions that came up was “we never allocated fabric for XilSEM, could it bust our budget?” Short answer: no, but read on, because the part of the design that *can* cost fabric is a different thing.
What changed from the older parts? Why this is not like UltraScale+?
XilSEM (Xilinx Soft Error Mitigation) scrubs configuration memory (CRAM) to keep single-event upsets from accumulating in the bits that define your routing and logic.
**UltraScale+ / 7-series:** XilSEM was a SOFT IP core. It synthesized into the programmable logic and cost real fabric (LUTs, flip-flops, BRAM). On those parts you had to budget for it.
**Versal (our flight part):** XilSEM MOVED into the hardened Platform Management Controller (PMC). It is firmware running on the PMC’s MicroBlaze (PPU), using dedicated config-frame scan hardware and the PMC’s own RAM. It does NOT synthesize into the programmable logic.
What does this mean for us? Enabling XilSEM consumes PMC processor cycles and PMC RAM, not the DSP / LUT / BRAM that the channelizer, demod cores, and DVB-S2 encoder compete for. It does not move the current ~1,495 DSP utilization (76%) number at all. This is good!
On Versal, XilSEM costs you no programmable-logic fabric. It is PMC firmware, not a soft IP core. So, it does not threaten the DSP/LUT/BRAM budget. The fabric cost of radiation mitigation lives in selective triple modular redundancy (TMR) of critical logic. The 16:1 multiplexed design baseline was chosen partly to leave headroom for exactly that.
Scrubbing is not the same as protection
XilSEM keeps configuration memory clean, but it corrects on a scan cycle with millisecond-scale latency. During that window an upset can still cause wrong behavior. Scrubbing prevents accumulation of upsets. But, it does not, by itself, protect against the immediate functional effect of one, and it is not sufficient on its own for a high-radiation space environment.
So a real flight design combines at least two mechanisms:
1. **XilSEM (config-memory hygiene):** Use this fabric-free option on Versal. Prevents fault accumulation in CRAM and NPI registers. Essentially free in our budget.
2. **Selective TMR (functional protection):** triple-modular redundancy on the logic that cannot tolerate a transient upset. This is where fabric goes: up to 3x plus voters on whatever we choose to triplicate.
TMR is a deliberate, selective decision that we make, applied to the most upset-critical logic, not a blanket tax on the whole design. But it is the real fabric-cost lever, and it is the thing to size against our headroom.
Why the 16:1 baseline already accounts for this
We chose 16:1 (76% DSP on the flight part) over 8:1 (~91%).
– 16:1 leaves ~24% of the DSP free on the XQRVC1902, plus we reclaimed ~450 DSP by sharing the power detector. That headroom is the budget selective TMR draws against when the radiation work item is executed. At 8:1 (~91%) there would be almost no room to triplicate anything. The 16:1 margin is not slack. It is reserved space for functional redundancy. So radiation mitigation is not unbudgeted. XilSEM is fabric-free, and the TMR headroom was deliberately preserved by the baseline decision.
Where do XilSEM’s costs actually show up?
**Power:** the background scan adds power draw and affects the flight power/thermal budget.
**PMC RAM:** XilSEM firmware and state live in PMC RAM and affects the PMC memory budget.
**Latency / reliability:** millisecond scrub-and-correct latency affects reliability and FDIR (fault detection, isolation, recovery) analysis, including SEFI handling. None of these touch DSP / LUT / BRAM. We record them in the radiation work item, not the fabric utilization.
What XilSEM does and does not handle
**Covers:** configuration memory (CRAM) upsets, and NPI (NoC peripheral interface) register corruption. It detects and corrects. AMD reports 100% correctable SEUs and ultra-low SEFI on the XQRVC1902, and the PMC itself is triple-redundant so the scrubber is protected.
**Does not cover:** user flip-flop or datapath states (that needs TMR), and user BRAM/URAM data contents. Contents use the block-RAM hardware ECC, enabled separately, at small-to-no fabric cost. We need to plan these explicitly. We cannot assume XilSEM catches them.
What do we actually need to harden?
We use the state-classification model. The reflex that busts the budget is “triplicate everything.” It is the wrong model for a streaming communications payload. The right model for a streaming communications payload is a domain model of state. We classify every register and RAM not by what it is, but by what a single bit-flip does to it and how long the damage lasts. If we do this analysis then the mitigation falls out mechanically. And, it’s cheaper than it seems, because only one class is expensive and it is the smallest.
The Three Buckets
**Bucket 1 is self-healing transient-tolerant streaming state** A flip corrupts one sample, which flushes out of the pipeline in a handful of clocks and is gone. It is indistinguishable from an RF noise hit, and we already fly a machine whose whole job is absorbing those exact type of corruptions. We have the FEC (the Viterbi decoder, and the ground receiver’s LDPC). No TMR. This is the DSP-heavy majority of the design, and it stays single.
**Bucket 2 is self-recovering and includes loops and adaptive states** A flip can knock a loop out of lock or perturb an average, but the loop’s job is to re-converge, so it heals itself. No TMR here either. We add a cheap watchdog that notices “unlocked too long” and triggers re-acquire, which matches how the loop already behaves.
**Bucket 3 is persistent control states that do not self-heal** Control FSMs, sequencers, counters, and set-once config registers are what we are talking about here. A flip here does not flush and does not re-converge. It hangs or mis-sequences the block until reset, and on a 16:1 core a stuck sequencer corrupts all sixteen channels at once. This is what earns TMR. It is a few percent of the fabric, so tripling should fit.
D&D Analogy
You knew it was coming! We are not plate-armoring every hit point. That is full TMR and we believe we do not need this. We run layered defenses matched to the threat.
**XilSEM scrubbing** is the cleric re-consecrating the ground every round, keeping the rules of reality (the configuration that defines the circuit) from corrupting. A separate hardened NPC. It costs the party no resources other than the material components for the buff.
**The datapath has regeneration.** A hit is an injury that heals next turn. The FEC is the regeneration spell.
**Heavy armor goes on the one caster who, if confused, wipes the party** The control-flow logic. Only it gets a triple-vote on “what do we do next.”
**Memories get a ward that auto-corrects a smudged rune** – BRAM/URAM ECC.
**The DM keeps a “reset the scene if it all glitches” rule** The SEFI watchdog.
Haifuraiya Draft Classification
| Haifuraiya Block or State | Class | Effect of Single Upset | Mitigation (Fabric Cost) |
| Polyphase filterbanks, FFT, halfband, channel EQ | Self-healing | One corrupted sample, flushes in a few clocks | None. Flush and FEC (no cost) |
| FIR, square, mixer | Self-healing | one bad angle, flushes in 16 clocks | None (no cost) |
| CORDIC (16 stages) | Self-healing | one bad angle, flushes in 16 clocks | None (no cost) |
| Power-detector squaring (I^2 + Q^2) by the EMA | Self-healing | one bad power sample, absorbed by the EMA | None (no cost) |
| DVB-S2 encode datapath (BCH, LDPC, map, shape) | Self-healing | one bad TX symbol, absorbed by ground LDPC | None (no cost) |
| F1/F2 NCO phase and loop accumulators | Self-recovering | possible loss of lock and the loop re-acquires | lock watchdog + re-acquire (should be minimal) |
| Lock detect accumulators and counters | Self-recovering | false lock/unlock, re-evaluated continuously | watchdog + hysteresis (minimal) |
| Power detector EMA feedback (51-bit mult_sum) | Self-recovering | transient wrong gain, decays over ~1/alpha, saturation bounds it | ECC on the state RAM with existing SAT clamp (minimal) |
| Symbol-timing recovery state | Self-recovering | timing slips, re-locks | watchdog (minimal) |
| 16:1 interleave sequencer, channel counter | TMR-critical | wrong channel addressing which corrupts all 16 channels and persists | TMR triplicate and vote (small, a few FF plus voter) |
| WP2 power-detector channel counter | TMR-critical | wrong-channel addressing, persists | TMR (small) |
| Frame-sync state machine (sync detect, boundaries) | TMR-critical | loss of frame alignment, wrong TLAST/TDEST, persists | TMR core finite state machine plus robust re-sync (small) |
| AXI-stream handshake and control finite state machines | TMR-critical | protocol violation or deadlock, persists | TMR (small) |
| DVB-S2 physical layer frame header and sequencer | TMR-critical | malformed frames, ground loses lock, persists | TMR control finite state machine (small) |
| Config registers (alpha, shifts, modes, thresholds) | TMR-critical (persistent) | silently wrong config for the rest of the mission | TMR the bits, or periodic refresh from a PMC golden copy (small) |
| All state RAMs (QP1 interleave state, WP2 EMA table, FIR windows) | Memory content corrupted stored value until read | BRAM/URAM hardware | ECC (no fabric) |
| CRAM + NPI config bits (defines the circuit itself) | Config memory | routing/logic corruption anywhere until scrubbed on millisecond time scales | XilSEM (PMC firmware, no fabric) |
What changes in the RTL
**TMR of an FSM:** three copies of that FSM’s registers plus a majority voter on its outputs. A local edit to a small module, not a datapath rewrite. Paired with XilSEM we can usually avoid the heavy physically-isolated TMR flow because the triplication catches the transient flop upset and the scrubber repairs the underlying config before a second copy can accumulate an upset.
**BRAM/URAM ECC:** a primitive mode or attribute on the RAM, plus handling the corrected and uncorrectable flags. Not fabric.
**Watchdogs:** mostly PS/PMC firmware plus a small amount of logic.
None of this touches the DSP columns.
Budget impact
The DSP number that binds us barely moves, because the DSP-heavy datapath is Bucket 1 and stays single. The cost lands in LUTs for triplicated control. The ~76% DSP picture survives essentially intact, and the 24% headroom is more than what selective control-TMR should need. Full TMR of the datapath (the “triplicate everything” reflex) would be ~3x and would not fit – which is exactly why we classify first and triplicate only Bucket 3.
The real deliverable of the radiation work item is a verified classification pass itself. The above table is a draft. For every state element, decide self-healing / self-recovering / persistent-critical. The risk is misclassifying a couple of elements, not the fabric.
Major Takeaways and Summary
1. Do not triplicate everything. Classify state first by fault behavior. Self-healing, self-recovering, persistent-critical. TMR only the last bucket.
2. The DSP-heavy datapath is self-healing (flush + FEC), so it stays single. The DSP budget barely moves and the ~76% picture survives.
3. TMR goes on control only: sequencers, FSMs, config registers. That is a few percent of fabric.
4. Loops get watchdogs, not triplication. They re-acquire on their own.
5. All state and constant RAMs get hardware ECC (no fabric). XilSEM covers config memory (PMC firmware, no fabric). Neither threatens the budget.
6. Do not budget fabric for XilSEM on Versal. It is PMC firmware, not soft IP. Its real costs are power, PMC RAM, and scrub latency. Put those in the power/reliability analyses.
7. Scrubbing plus selective TMR is the flight combination. XilSEM stops accumulation, TMR handles the immediate transient on the logic that cannot self-heal.
8. The deliverable is the classification pass. The risk is misclassifying an element, not the fabric. Do the pass for real.
Sources
Based on AMD/Xilinx primary sources and peer-reviewed literature: XilSEM migrated from soft IP to PMC firmware on 7nm Versal (IEEE/NSREC proton-test paper; AMD Versal PLM documentation), the UltraScale+ vs Versal soft-IP-vs-PMC distinction and the scrubbing-latency / not-sufficient-alone caveats (ScienceDirect fault-tolerance survey), and the XQRVC1902 SEE results (AMD SEFUW 2023/2025 presentations: NO SEL, 100% correctable SEUs, ultra-low SEFI). Confirm specifics against the current DS946 data sheet and the XilSEM chapter of UG1304 before freezing the flight radiation plan.