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, firmware image under Renode-class execution, 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
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.
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.
- Renode board platforms
Generate Renode board platforms from KiCad or Allegro netlists. Attach peripheral models, surface coverage gaps, and load a .repl without hand-maintaining every CS line.
- The I²C Clock-Stretch Bug We Caught Four Weeks Before Fab
- HardLabs vs HIL rigs
