September 12, 2026

Silicon-Verified Edge AI: Why Simulation Results Don't Match Your Chip

Your edge AI model passes simulation. Then it hits the actual chip and fails. This is the gap between simulation and silicon - what causes it, how silicon-verified measurement fixes it, and what MLPerf Tiny and EnergyRunner actually measure.

Your edge AI model passed every simulation test. Then it hit the actual chip and failed.

Inference latency ran 3x longer than projected. Peak SRAM usage exceeded the chip's physical limit by 18%. Battery life dropped below spec before the first field trial. This is the gap between simulation and silicon. It is common, it is expensive, and it is entirely avoidable.

WHY SIMULATION RESULTS LIE

Simulators model compute. They count multiply-accumulate operations, estimate cycles on an idealized core, and return a latency figure that looks precise. What they do not model: the memory subsystem.

On a real MCU or NPU, your model spends 40 to 70 percent of its active time moving data. Weights load from flash into SRAM. Activations fill and drain the scratchpad. The bus stalls. The DMA controller queues transfers. None of this appears in a simulation trace. The latency figure the simulator printed was the arithmetic, not the system.

Energy measurement is worse. A reference board runs your model under laboratory conditions: stable supply voltage, no competing peripherals, no duty-cycle interruptions. Your customer's hardware is none of those things. The energy number you quoted came from a different chip in a different state.

This is not a simulator defect. Simulation is useful for architecture search and operator validation. It is not a substitute for measurement on the target device.

WHAT SILICON-VERIFIED MEASUREMENT MEANS

Silicon verification measures three quantities on the customer's actual chip, not a reference board:

Accuracy. The model running on-device, with fixed-point quantization fully applied, on representative test data. Not floating-point accuracy on a GPU. The real number, from the real inference path.

Latency. End-to-end wall-clock time from input frame to output classification, captured by hardware timers on the chip. This includes data-movement costs, memory management overhead, and any RTOS scheduling jitter that the actual deployment will encounter.

Energy. Current draw at the actual supply voltage, integrated over a real inference sequence, measured with precision analog instrumentation. Peak current matters as much as average: a spike that exceeds the regulator's transient budget will reset the device mid-inference in production.

The Chrysalis rig instruments your silicon directly. You send the chip. We flash the model, wire the measurement harness, and run the evaluation loop. The scorecard you receive reports what the chip actually does, not what a simulator predicted.

THE METHODOLOGY: MLPerf TINY AND ENERGYRUNNER

Two open benchmarking standards anchor the measurement methodology.

MLPerf Tiny, published by MLCommons, defines the evaluation tasks, the data sets, the accuracy metrics, and the submission format for embedded inference. Using MLPerf Tiny as the outer harness means the latency and accuracy figures are comparable across chips and across vendors. A number reported under MLPerf Tiny carries an externally auditable methodology; a number reported without it carries only the vendor's word.

EnergyRunner, developed at ETH Zurich and now maintained as an open tool, provides the energy measurement framework. It defines how to trigger inferences, how to gate the measurement window, and how to report peak and average current in a reproducible way. EnergyRunner measurements have been validated against precision bench instruments; the protocol eliminates the systematic errors that plague hand-rolled energy tests.

Chrysalis uses both. Every scorecard reports MLPerf Tiny accuracy and latency, plus EnergyRunner energy, measured on the customer's submitted hardware.

<blockquote> A scorecard produced under an audited methodology is a technical record, not a marketing claim. </blockquote>

THE EU AI ACT COMPLIANCE ANGLE

The EU AI Act's conformity assessment requirements for high-risk AI systems include documented performance evidence measured under defined conditions. A scorecard that cites MLPerf Tiny and EnergyRunner satisfies this evidentiary standard: it names the methodology, the hardware, the data set, and the observed metrics.

A simulation result does not. A result from a reference board does not. The conformity artifact the AI Act envisions is a measurement report tied to the actual deployment hardware, produced under an auditable protocol. That is what silicon verification produces.

For companies selling edge AI systems into the EU market, this is not optional. The Chrysalis scorecard is designed from the ground up to function as a conformity artifact.

FREQUENTLY ASKED QUESTIONS

What chips does the rig support? The rig is chip-agnostic. You send the silicon; the rig instruments it into the hardware-in-the-loop loop. Any MCU or NPU with a standard flash interface qualifies. Unusual packages require a short pre-qualification call.

How long does a Feasibility Gate take? The standard Feasibility Gate runs within five business days of hardware receipt. It produces a full silicon-verified scorecard: accuracy, latency, and energy on your submitted chip.

Do you need the model weights or just the binary? Either works. The rig can flash a compiled binary directly. If you supply weights and a target SDK, Chrysalis can compile and quantize before measurement. Both paths produce the same scorecard output.

Is the scorecard data shared with other customers? No. Scorecard data is customer-confidential. The methodology is public; the results belong to you.

START WITH THE FEASIBILITY GATE

A Feasibility Gate is a fixed-scope engagement: one chip, one model, one scorecard. No retainer, no open-ended statement of work. You receive a silicon-verified measurement report and a clear picture of whether your model is ready for production at the metrics your product requires.

If the model passes, you have the conformity evidence you need. If it does not, you have a precise diagnosis: which metric failed, by how much, and at which layer the budget overrun occurred.

Start the Feasibility Gate

Built with