How accurate are the simulations?

HardLabs combines SPICE-grade behavioral models for analog blocks with cycle-aware digital models for buses and MCUs. They're tuned to expose integration and timing bugs — not to replace final sign-off characterization.

Which MCUs and peripherals are supported?

At launch we cover common Arm Cortex-M families and the I²C, SPI, UART, GPIO, timer, and interrupt subsystems firmware leans on most. Peripheral and sensor model coverage expands every release.

How is this different from plain SPICE?

SPICE simulates the circuit — it doesn't run your firmware. HardLabs executes your actual firmware image in the loop with the simulated circuit, so you test the hardware and the code together.

How is this different from a hardware-in-the-loop (HIL) rig?

A HIL rig needs physical hardware and bench instruments that don't exist until late in the program. HardLabs is a hardware-in-the-loop alternative that runs entirely in software, before any board is fabbed.

Do I need any physical hardware?

No. The whole point is to start before a prototype exists. When real hardware arrives, the same firmware and test suite carry straight over to the bench.

Yes. The loop runs headless, so you can gate every firmware commit on the same circuit-level tests you'd otherwise only run by hand at bring-up.

Can we run this on-prem or air-gapped?

Yes — talk to us. Self-hosted and on-prem deployment is available for export-controlled and IP-sensitive teams. Your netlists and firmware stay yours; we don't train on customer designs.

Which EDA tools do you support?

Cadence, Altium, and KiCad at launch — plus SPICE netlists and BOM/CSV imports. Allegro and Xpedition direct import is on the roadmap. Send us your netlist, schematic PDF, and BOM to get started.

What do I provide to get started?

Your netlist, schematic PDF, and BOM — plus your firmware (image or source). HardLabs builds the simulation and runs your code against it; you write no models.

The I²C clock-stretch bug we caught four weeks before fab

Adam Szefer · Co-founder & CTOJuly 23, 2026

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

On the homepage we tease a design-partner catch: SCL t_HIGH measured at 0.42µs against a 0.60µs floor. This is the longer version — what broke, why idealized peripherals would have missed it, and how the assertion looks in CI.

The symptom we were aiming to prevent

The board mixed a Cortex-M master with a sensor that stretches SCL under load. Firmware timeouts and timing assumptions were tuned against a friendly evaluation module — not against the stretch behavior called out in the production part’s datasheet. On a physical spin that mismatch shows up as intermittent NACKs and “works if I lower the bus speed.” On a calendar it shows up as a respin.

Why the eval kit lied politely

Eval kits and register-level stubs often never stretch. Drivers ship with timeouts that only fire on real silicon. If your simulation always ACKs on time, you are training the stack for a board you are not building.

What the failing check looked like

We ran unmodified firmware against a netlist-derived platform. The assertion watched SCL high time during the transfer that stressed the slave. When t_HIGH dropped below the datasheet floor, the run failed with a traceable message — the same class of signal you would chase on a scope, available before copper.

Failure summary (simplified from the partner run)

FAIL  i2c1  t_HIGH
  measured  0.42 µs
  required  ≥ 0.60 µs
  context   sensor stretch during burst read
  firmware  payload.elf @ bring-up suite
  delta     4 weeks before scheduled fab

What we changed before tape-out

Firmware timing and retry policy were fixed against the real contract. The assertion stayed in CI so a later pinmux or clock-tree change could not revive the bug silently. The first articles still needed bench time — for sensor truth, not for rediscovering stretch.

Takeaway for embedded teams

If your risk is HW/FW integration, demand that pre-silicon simulation can disagree with you. Green bars from always-polite peripherals are not safety. Encode the datasheet limits you already fear as tests, and run them on the topology in your netlist.

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

All blog