Second Silicon: Accelerating Post-Fab PCB Bring-Up

Problem

Once a PCB has been fabricated and assembled, teams need to find any issues with it and spin out new versions of the board before it is shipped to production. This project hypothesized that it cut the amount of time it takes to perform this post-initial-fabrication "bringup" down by 50% or more, with initial conversations putting estimated current times to a few weeks to a few months.

A board may power on while a peripheral refuses to enumerate. A power rail may be present while an MCU remains in reset. A sensor, camera, or communication bus may fail for reasons that are difficult to distinguish from firmware or configuration mistakes. Board bring-up spans hardware inspection, power, clocks, reset, interfaces, and firmware, so the evidence is spread across schematics, PCB files, firmware, logs, bench instruments, and engineer notes.

The result is a slow investigative loop: form a hypothesis, switch tools, take a measurement, reconstruct the relevant design context, and decide what to try next. This is especially painful for small hardware teams working with inherited designs, contractor output, or a new board revision.

The General Idea

The tagline for Second Silicon was a “Cursor for post-fab PCB bring-up”: a context-aware assistant for the work that begins after a board exists.

The idea was to start from a real KiCad or Altium project, let an engineer describe a symptom in plain language, connect that symptom to the relevant components and nets, incorporate measurements from tools like oscilloscopes, and preserve the investigation as a working thread.

_The intended workspace keeps the schematic, measurements, and debugging reasoning in view together._

A Bring-Up Loop

Second Silicon was meant to support a simple, repeatable loop:

1. Describe the observed symptom, such as “the board powers on but USB does not enumerate.”
2. Relate the symptom to the design: relevant sheets, nets, components, and firmware behavior.
3. Identify the next measurement that would distinguish between likely causes.
4. Feed the result back into the investigation and refine the hypothesis.
5. Keep the conclusion and next action attached to the board’s context.

For example, power being present does not prove that a USB interface is wired, configured, and communicating correctly. A useful assistant should help an engineer work through those possibilities without losing the connection between the bench result and the original design.

Collaboration

This project was co-developed with Vijay George, who is an excellent designer. We built this project in Spring-Summer 2026.