I²C and SPI simulation on your real topology

Adam Szefer · Co-founder & CTOUpdated July 23, 2026

Prev. Bloomberg · Gyfted. Systems and simulation infrastructure — the engine that runs your firmware against the circuit.

Bus bugs are rarely in the MCU reference manual. They are in which chip sits on which bus with which address and CS. Simulation only helps when those facts come from the schematic.

What you can see before probes exist

Enumeration failures, NACKs, wrong addresses, CS polarity/GPIO mistakes, stretch and t_HIGH contracts — with decode instead of a logic analyzer on a half-built board.

Tied to the netlist, not a virtual shield

Attachments come from discovered buses in your design. A hand-maintained “shield” that drifts from the schematic trains drivers on fiction.

When timing is the bug

Clock stretch and master timeouts deserve their own deep dive — see the I²C timing topic and the design-partner post-mortem for a concrete t_HIGH failure.

SPI attach sketch (generated)
u4_bmp280: HIP.BMP280 @ spi3
    Cs => gpioPortA@15

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.

Pilot details · App

Related

All topics