Skip to main content

Second Silicon: Accelerating Post-Fab PCB Bring-Up

Archived project. Second Silicon is discontinued.

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. 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.

Second Silicon workspace combining a schematic, scope capture, and board debugging investigation_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 in Spring–Summer 2026. My work covered hardware-interfacing software, oscilloscope integration with the live data stream, and KiCad and Altium schematic parsing.