TN-17 · 2026-09-12 · XiL Domain Series · Part 3

HIL Real-Time: A Missed Cycle Isn't Slow, It's Wrong

A line in a HIL rig’s spec sheet is often misread: “Real-time: 1 ms step, jitter ≤ xx µs.” The first reaction is usually “isn’t 1 ms fast enough?” — and that is exactly the misreading. “Real-time” in HIL never means “fast”; it means on time, every cycle. And when a cycle is missed, the consequence is not “a bit slower” — the entire test’s evidence is void.

This article has two halves. The first makes the semantics of HIL “real-time” precise: the three parts of the hard real-time contract, why jitter rather than latency is the core metric, and what 1 ms of jitter means at different step sizes. The second half answers the question that naturally surfaces — when a general-purpose CPU cannot hold a microsecond deadline, what does the rig fall back on? The answer is the FPGA, a chip “wired in code.”

1. What “Real-Time” Means in HIL: Locked to the Real World’s Clock

Not “computes fast” — locked to the real world’s clock: the plant models running on the rig (vehicle dynamics, battery, motor) advance at a fixed step size (say 1 ms per step), and every step must finish computing and output within 1 ms of real time. At the other end of the closed loop sits a real ECU, controlling against the wall clock; if the world model falls one cycle behind, the ECU reads a stale world and the whole loop loses its meaning.

This hard real-time contract has three parts:

1. Deterministic compute: each step’s model solving plus IO handling must fit within the step even in the worst case;
2. Deterministic IO: CAN frames and analog/digital signals are sent and received with hardware timestamps, aligned to the simulation beat — not “sent around this beat,” but traceable to “sent at microsecond N of this beat”;
3. A single overrun vetoes the whole run: overrun cycles are counted throughout, and one occurrence voids the test result — not a performance discount, but invalid evidence. In dSPACE/NI reports, overrun is the top health indicator.

The third part hides the worldview of real-time systems: a missed cycle is not “slow” — it is “wrong.”

2. Why Jitter Is the Core Metric, Not Latency

A fixed latency (every cycle consistently 100 µs late) is a constant you can calibrate away; jitter is variance — unpredictable, and impossible to compensate. That is why real-time spec sheets state the worst case and never the average: averages have no standing in the real-time world; whether the contract holds is judged by the worst cycle.

3. What 1 ms of Jitter Means: It Depends on the Step Size

Physical intuition: in an AEB scenario, 50 kph = 13.9 m/s, so 1 ms of time uncertainty is 1.4 cm of position uncertainty. Once, that looks trivial — but inside a closed loop, jitter injects phase lag, which can make a controller that is stable in the real world oscillate on the rig (a false fail), or mask a real problem (a false pass — the scariest outcome, because it ships bugs into production).

4. How Commercial Rigs Do It

An RTOS (or an in-house real-time kernel) + FPGA (µs-level loops) + hardware-timestamped IO. The spec level: at a 1 ms step, jitter sits in the µs range (0.1%~1% of the step).

5. How to Measure a Machine’s “Real-Time Worthiness”

“Real-time enough” is measurable. The classic tool is cyclictest: wake the system at a fixed period and record the maximum deviation of each actual wake-up from its expected time. Read its Max column against this scale:

Two handy reference points. On a general desktop OS — and even more so in a VM — worst-case scheduling jitter reaches a dozen-plus milliseconds; even the loosest 10 ms loop cannot be held, which is why a VM can never serve as a HIL real-time environment. Bare-metal Linux with the PREEMPT_RT patch, plus chrt pinning the real-time thread to top priority, aims to push the maximum down to tens of µs — reach that, and you are at the threshold of “entry-level HIL at 1 ms steps.”

6. FPGA: A Chip “Wired in Code”

The “FPGA (µs-level loops)” from section 4 deserves an expansion. An FPGA (field-programmable gate array) is a chip you can rewire by “writing code” — what you write is not a program; it is a circuit.

• CPU: the circuit is fixed; code is an instruction sequence, executed one by one over time — trading time for space;
• FPGA: the chip holds a “sea of logic bricks” (lookup tables + flip-flops + programmable interconnect); the code (Verilog/VHDL) is compiled into how the bricks are wired, and once flashed, the chip “grows into” the circuit you designed — trading space for time.

The contrast is not “which is faster” but a fundamentally different way of working: a CPU is “one worker cooking from a recipe”; an FPGA is “building a dedicated kitchen outright.”

7. Three Key Properties — and the Price

1. True parallelism: ten thousand logic units really do work at the same time — there is no “scheduling”;
2. Hard determinism: however many clock cycles a result takes, it takes exactly that many — nanosecond-level, zero jitter; no OS, no cache misses, no interrupts;
3. Interface freedom: pins can become almost any protocol — CAN, SPI, custom sensor interfaces are all “wired out.”

The price is real too: hard to develop (hardware thinking; debugging means oscilloscopes and logic analyzers), expensive, slow to flash. So the industry practice is a CPU + FPGA combination:

┌────────────── Division of labor inside a HIL rig ──────────────┐
│  Real-time CPU: models + logic, 1 ms steps, µs-level jitter    │
│  FPGA: electrical I/O, backplane sync, raw injection, ns-level │
└────────────────────────────────────────────────────────────────┘

The CPU runs the models and logic; the FPGA handles nanosecond-level I/O.

8. The FPGA’s Three Ironclad Positions in a HIL Rig

1. The heart of the I/O boards: analog/PWM/resistor-simulation boards use FPGAs to generate and capture waveforms — the signal timing an ECU’s pins demand is nanosecond-level, which a CPU’s 1 ms beat simply cannot reach;
2. Backplane synchronization: timebase alignment across boards and cabinets (<1 µs) rides on FPGA hardware trigger lines — the “hardware synchronization” in rig specs is exactly this;
3. Raw sensor injection: radar-echo and video-stream injection boards — the data rates are so high that only an FPGA can hold them.

Set against the table in section 3, the same pattern shows: as the step size shrinks (10 ms → 1 ms → µs), the work shifts from CPU to FPGA — the millisecond world belongs to the real-time CPU, the microsecond world to the FPGA, with backplane sync aligning the timebases in between.

9. Four Compute Paradigms, One Sentence Each

• CPU: one worker cooking from a recipe (general-purpose, mostly serial);
• GPU: ten thousand workers cooking the same dish (parallel but homogeneous);
• FPGA: a kitchen that can be rebuilt anytime (changeable, fast enough, not cheap);
• ASIC: a kitchen that may never change once built (fastest in production, not programmable).

10. The Boundary of Division: The Interface Is Configuration, Not Design

A common misconception: to develop on a HIL test platform, do you have to write Verilog? No. In the CPU + FPGA combination, the electrical I/O has already been solved in FPGA by the rig vendor; the test-platform developer’s interface to it is configuration — pick the boards, map the channels, set the sample rates — not design. Understanding the FPGA’s role in the rig is enough; you don’t need to write a hardware description language.

A shortcut to understanding that role is to contrast two kinds of injection. Why can restbus simulation’s CAN traffic run on a CPU plus a CAN card, while radar-echo injection must use an FPGA? Two reasons — data rates several orders of magnitude apart (CAN frames are kbps~Mbps with millisecond deadlines; radar echo is a sustained high-speed stream), plus timing-determinism requirements (shift the echo phase by a few nanoseconds and you have injected a different world). The CPU can hold the former and cannot hold the latter — that is why the FPGA exists, and it is the physical boundary of the real-time contract this article opened with.

Back along the whole chain: HIL “real-time” is a contract locked to the wall clock — deterministic compute, deterministic IO, a single overrun vetoing the whole run; a missed cycle isn’t slow, it’s wrong, because from that cycle on, the evidence stops being trustworthy. That the contract can be signed at microsecond precision owes not to a faster CPU but to a division of labor: the CPU owns models and logic on the millisecond beat; the FPGA owns the nanosecond electrical world. See this boundary clearly, and you see the whole engineering story behind the spec-sheet line “jitter ≤ xx µs.”

Appendix: Glossary (in order of appearance)