Why QEMU’s idealized peripherals hide respin bugs
Prev. Bloomberg · Gyfted. Systems and simulation infrastructure — the engine that runs your firmware against the circuit.
We like QEMU. We also ship product into the gap it leaves: board-aware behavior under real firmware. Here is the boundary in plain language.
What QEMU optimizes for
Fast iteration on OS and application logic. Flexible machine models. A huge ecosystem. If your question is “does my RTOS schedule correctly,” stay there.
What board bring-up actually fails on
Wrong alternate functions, shared addresses, CS on the wrong GPIO, stretch and timing contracts, power order relative to firmware init. Those facts live in the schematic and BOM — not in a generic SVM.
A useful division of labor
Use QEMU (or another emulator) for instruction-accurate execution. Attach peripherals that can fail like the parts on your netlist. HardLabs is opinionated about the second half.
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
HardLabsAll blog