How accurate are the simulations?

HardLabs combines SPICE-grade behavioral models for analog blocks with cycle-aware digital models for buses and MCUs. They're tuned to expose integration and timing bugs — not to replace final sign-off characterization.

Which MCUs and peripherals are supported?

At launch we cover common Arm Cortex-M families and the I²C, SPI, UART, GPIO, timer, and interrupt subsystems firmware leans on most. Peripheral and sensor model coverage expands every release.

How is this different from plain SPICE?

SPICE simulates the circuit — it doesn't run your firmware. HardLabs executes your actual firmware image in the loop with the simulated circuit, so you test the hardware and the code together.

How is this different from a hardware-in-the-loop (HIL) rig?

A HIL rig needs physical hardware and bench instruments that don't exist until late in the program. HardLabs is a hardware-in-the-loop alternative that runs entirely in software, before any board is fabbed.

Do I need any physical hardware?

No. The whole point is to start before a prototype exists. When real hardware arrives, the same firmware and test suite carry straight over to the bench.

Yes. The loop runs headless, so you can gate every firmware commit on the same circuit-level tests you'd otherwise only run by hand at bring-up.

Can we run this on-prem or air-gapped?

Yes — talk to us. Self-hosted and on-prem deployment is available for export-controlled and IP-sensitive teams. Your netlists and firmware stay yours; we don't train on customer designs.

Which EDA tools do you support?

Cadence, Altium, and KiCad at launch — plus SPICE netlists and BOM/CSV imports. Allegro and Xpedition direct import is on the roadmap. Send us your netlist, schematic PDF, and BOM to get started.

What do I provide to get started?

Your netlist, schematic PDF, and BOM — plus your firmware (image or source). HardLabs builds the simulation and runs your code against it; you write no models.

Does this replace writing Renode peripherals?

For catalog parts, yes — we compile behavioral models from datasheets. Custom ASICs still need model work; the generator will flag them.

Renode board simulation from your netlist

Adam Szefer · Co-founder & CTOJuly 18, 2026Updated July 23, 2026

Prev. Bloomberg · Gyfted. Systems and simulation infrastructure — the engine that runs your firmware against the circuit.

Renode is excellent at running Cortex-M firmware. The painful part is keeping a board description synchronized with the schematic. HardLabs generates that description from the design of record and refuses to silently drop chips it cannot model.

Why hand-written .repl files drift

Every ECO reshuffles buses and chip-selects. A platform file maintained by hand becomes fan fiction of last quarter’s schematic. Generating from the netlist + BOM keeps attachments tied to the files you already review in PRs.

What generation emits

A board .repl with the MCU platform include, peripheral attachments for I²C/SPI devices that have catalog models, and an honest gap list for everything else. Missing models are actionable (datasheet extract), not invisible holes.

Example attachment lines (generated)

using "platforms/cpus/stm32f4.repl"

u4_bmp280: HIP.BMP280 @ spi3
    Cs => gpioPortA@15

// Gaps (not attached):
// U3 W25N01GVZEIG — matched catalog model W25N01GV after MPN stem resolve

Loading in Renode

Include the compiled peripheral classes, create the machine, load the platform description. If a model is missing, fix the gap first — a green load with silent omissions is worse than a failed generate.

Monitor sketch

(monitor) include @compiled/BMP280.cs
(monitor) mach create
(monitor) machine LoadPlatformDescription @board.repl
(monitor) sysbus LoadELF @firmware.elf
(monitor) start

FAQ

Does this replace writing Renode peripherals?: For catalog parts, yes — we compile behavioral models from datasheets. Custom ASICs still need model work; the generator will flag them.

HardLabs

What HardLabs does — join the design-partner pilot

We build a digital twin from your netlist, schematic, and BOM, run your real firmware against it, and fail CI when pinmux, buses, or timing contracts break — weeks before bring-up on hardware.

A digital twin of your hardware, built from your netlist, schematic, and BOM.
A virtual lab: scopes, logic analyzers, and firmware debuggers in simulation.
Auto-flagging of power-sequence errors, output contention, and race conditions.

Pilot details · App

Firmware-in-the-loop
Firmware-in-the-loop against your netlist — not stubs. Run unmodified .elf images on MCU simulation with board-aware I²C/SPI models and CI assertions.
KiCad → simulation
Take a KiCad netlist into firmware-in-the-loop simulation. Overlay the BOM, generate a Renode-oriented board platform, and test drivers before fab.
Altium → simulation
Simulate firmware against Altium-designed connectivity before fab. Use design-of-record exports — not a hand-maintained virtual shield.
HardLabs vs Renode
INA219 model

All topics

Renode board simulation from your netlist

Why hand-written .repl files drift

What generation emits

Loading in Renode

FAQ

What HardLabs does — join the design-partner pilot

Related