Embedded system simulation beyond the MCU core
Prev. Stitch Fix · Amazon · Bain Capital Ventures. Built ML systems in production at scale; runs how we turn datasheets into models.
Simulating a Cortex-M alone is table stakes. Product firmware fails when the board topology disagrees with the driver. System simulation here means MCU + buses + the MPNs on your BOM.
System = MCU + buses + parts
Connectivity from the netlist, identity from the BOM, behavior from chip models. That is the minimum viable twin for driver bring-up.
Who uses it on a program
Firmware writes drivers early. Hardware validates assumptions before fab commits. Managers see bring-up risk while schedule is still soft.
Complement, don’t replace, your stack
Keep unit tests and static analysis. Add board-aware FITL for the boundary those tools never see.
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.
- HW/SW co-simulation
Hardware–software co-simulation that sees the boundary: real MCU firmware plus board-aware peripheral models from your netlist.
- 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.
