Hardware–software co-simulation that sees the boundary
Prev. Stitch Fix · Amazon · Bain Capital Ventures. Built ML systems in production at scale; runs how we turn datasheets into models.
Co-simulation only helps if both sides are honest. Firmware that is not stubbed. Hardware that is not an always-ACK register file. The expensive bugs live on that boundary.
The boundary problem
Firmware teams emulate polite peripherals. Hardware teams SPICE fragments of the schematic. Neither run sees a stretch the sensor rejects or a GPIO that never became UART TX.
How HardLabs co-simulates
MCU execution plus datasheet-derived models on the buses your netlist wires. Decode traffic, assert on contracts, fail CI when the system misbehaves.
Ownership of the twin
Design partners keep the digital twin built from their files. Firmware stays yours; 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.
- Embedded system simulation
Embedded system simulation that includes your PCB buses and parts — not just the Cortex-M core — so drivers meet the real topology before hardware.
- Runnable PCB digital twin
A PCB digital twin built from netlist and BOM — runnable under real firmware, with honest coverage gaps when a part is not modeled yet.
- HardLabs vs QEMU
