A hardware-in-the-loop alternative before the board exists
Prev. Bloomberg · Gyfted. Systems and simulation infrastructure — the engine that runs your firmware against the circuit.
Hardware-in-the-loop is still the right tool once you have fixtures and articles. The expensive window is earlier: when the schematic is frozen, firmware is compiling, and nobody can put a probe on a bus that hasn’t been fabbed. HardLabs is built for that window.
What HIL teams actually need from a pre-hardware stand-in
They need the same binary that will ship, failure modes that look like the lab (NACK, stretch, wrong CS), and tests that can gate CI. Idealized register files that always ACK do not qualify — they train drivers on lies. A useful alternative keeps MCU execution honest and makes peripherals disagree when the board wiring or timing would.
Where HardLabs sits relative to a bench HIL rig
Bench HIL wins on sensor truth, RF, and compliance. HardLabs wins on calendar: pinmux mistakes, address collisions, and protocol contracts show up while copper is still editable. Most design-partner programs use both — simulation to clear integration noise, then HIL for physics.
A minimal loop you can run headless
Netlist + BOM in, platform description out, your unmodified firmware image running on the simulated board, assertions on bus timing. The same suite should still pass when the first articles arrive; only the transport changes from simulated I²C to a real analyzer.
# t_HIGH on SCL must stay above the peripheral minimum
assert scl_thigh_us >= 0.60, (
f"SCL t_HIGH {scl_thigh_us:.2f}µs < 0.60µs — "
"clock stretch / timing contract broken"
)FAQ
- Is this a replacement for HIL?
- No. It replaces waiting for HIL. Use simulation to clear firmware/board disagreements; use the rig for the physics HIL is good at.
- Do we need on-prem for export-controlled work?
- Often yes. Talk to us — self-hosted and air-gapped options exist. We do not train on customer designs.
HardLabs
Send us your design. We'll send you a simulator.
We build a board simulator from your netlist, schematic, and BOM, run your real firmware against it, and fail CI when pinmux, buses, or timing contracts break.
- A working simulator of your board, built from netlist, schematic, and BOM.
- Peripheral models attached so your firmware can talk to the board.
- A setup that runs your real firmware binary — no rewrite required.
Related
- 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.
- Simulate firmware without hardware
Simulate firmware without a board: where QEMU’s idealized peripherals fall short, and how board-level models catch pinmux and bus bugs before fab.
- What is HIL testing?
HIL testing explained: how a hardware-in-the-loop test system works, HIL vs SIL testing, HIL in automotive, and testing before the hardware exists.
- The I²C Timing Bug We Caught Four Weeks Before Fab
- HardLabs vs HIL rigs
HardLabsAll topics