Firmware Before the Boards Arrive
Upload a PCB design after manufacturing begins to create virtual hardware that runs real firmware tests before the physical boards arrive.
Once a PCB has been sent to the factory but physical boards are still in transit, firmware teams often have to wait until the boards arrive before they can begin validation. Engineers add PCB layouts, netlists, BOMs, and key component documentation exported from KiCad or Altium to a project. The product reads chip pins, bus connections, and peripheral relationships, then generates a virtual hardware layer that firmware can call.
Developers can compile real firmware in CI while the simulator returns predefined responses for GPIO, I2C, SPI, sensor interrupts, and common peripherals. The interface links every simulated behavior back to the schematic and component documentation, distinguishing what came from the design files from what still needs engineering input. For the first power-on check, it generates runnable test sequences for power, communications, and critical pins.
When the boards arrive, the same tests can run through a debugger and instruments instead. The product separately flags cases that passed in simulation but failed on the physical board, helping teams determine whether the issue is a schematic assumption, soldering problem, or firmware timing error. The days saved in hardware shipping do not get lost again to hurried test-environment setup.
The first version prioritizes common microcontrollers and standard interfaces. It does not promise accurate simulation of complex analog circuits, RF effects, or every proprietary chip. Its purpose is to make firmware testable earlier and give teams a ready-made acceptance path for the first power-on of the physical board.
Why now
On August 6, ProvenMetal’s Hacker News post on delivering circuit boards in days rather than weeks drew discussion; at the August 7 observation, it had 183 points, 129 comments, and ranked ninth. S1 As lead times shrink, firmware teams are more likely to face a specific mismatch: the boards are not yet in hand, but the software schedule is already counting down.
Target user
Embedded teams with schematics in hand that have just sent a first-revision or revised PCB to fabrication. Hardware connectivity is largely frozen, but firmware interfaces have not yet been validated across the full board. Firmware leads need to surface pin, bus, and boot-order issues early. Hardware leads want tests to move to the physical board as soon as it arrives, rather than having to explain the entire schematic again.
Minimal entry point
Start with KiCad projects, plus netlists and BOMs exported from Altium. KiCad CLI can already export several netlist formats and an XML BOM, providing a stable entry point. S2 After parsing, build a graph of components, pins, nets, and buses, then have engineers confirm the main controller, power domains, and critical peripherals. Rather than building a full simulator, generate Renode platform descriptions and a small set of peripheral stubs. The first release covers only GPIO, UART, I2C, SPI, and timer interrupts. Tests use a common scenario format: the simulation side calls models, while the physical-board side connects to a debugger and serial proxy. Complex analog circuitry, RF, and unmodeled proprietary components are marked for physical testing only.
Punching above its weight
Acquire initial users through GitHub projects for embedded CI, KiCad automation, and Renode. Publish a runnable example repository showing the full commit history from netlist to CI test to rerun on a physical board. Create public templates for common development boards so engineers can validate the workflow on familiar designs first. The Hacker News audience discussing rapid PCB fabrication can also be reached with specific board-level case studies.
Competitors & gaps
- RenodeGoogle
- Renode can run unmodified embedded software and emulate processors, peripherals, and sensors. It integrates with Robot Framework for CI testing and lets users extend peripheral models in Python or C#. S3 For teams experienced in simulation, it is already a mature foundation. The gap is that engineers must still configure platform descriptions and peripheral behavior themselves. It does not turn the netlist, BOM, and component documentation for a PCB already in production directly into a project model. It also lacks a hardware-review-oriented interface that traces schematic connections, model assumptions, and test results. This product could use Renode behind the scenes while focusing on design-file import, prompts for missing information, and switching to physical-board testing.
- WokwiGoogle
- Wokwi offers simulation for microcontrollers and common components, along with a logic analyzer, virtual sensors, and custom-chip capabilities. Its CLI can run firmware locally or in CI and evaluate tests based on serial output. S4 That makes it quick to bring Arduino, ESP32, and similar projects into repeatable testing. Its workflow still centers on project configuration and virtual wiring diagrams, requiring users to prepare the hardware description needed for simulation. It does not treat manufacturing schematics, netlists, and BOMs as primary inputs, nor does it explain the basis for each model assumption. Teams must also build their own reuse path once physical boards arrive. The opening is a workflow for professional PCB projects that puts design-data conversion, assumption review, and before-and-after board comparison in one test chain.
How it makes money
Team subscriptions tiered by the number of active hardware projects and parallel CI usage. The base plan covers common microcontrollers and standard peripherals; higher tiers add private device models, physical-board test agents, and self-hosted execution environments.
The case against
Design files describe connectivity, not how components actually behave under every input. When datasheets are incomplete, generated models can hide incorrect assumptions about timing, resets, and electrical behavior. Each additional microcontroller or proprietary peripheral requires maintained models, examples, and regression tests. If teams mistake a passing simulation for a hardware guarantee, they may take greater risks during the first power-on. Physical-board execution can also be affected by differences in debuggers, instruments, and fixtures, making truly seamless test portability difficult. If early projects require extensive manual modeling, configuration costs may erase the time saved waiting for boards.