One CLI, five verification stages, one command.

Historically, silicon verification is five separate flows, run at five different points in the schedule, by three or four different teams. RTL simulation is a DV activity. Post-synthesis GLS lives with the synthesis team. Post-PnR GLS is a physical design signoff task. Board simulation lives with the board team. And final board simulation with GDS-extracted parasitics happens the week before tapeout, if it happens at all.

Every stage has its own scripts, its own toolchain, its own reporting format. Every handoff between stages loses information. And every handoff is a place where a real bug can escape.

The Silverchips DV CLI collapses those five stages into one command. This note is about what that means in practice, and why the annotation flow matters more than the tool consolidation.

The command

$ silverchips verify --flow full

That is the surface. Under it, five stages run in sequence.

Stage 1: RTL simulation

The design under test compiled from source RTL. VIP-driven stimulus. Functional coverage. If this fails, the flow stops here. Nothing else matters until RTL is correct.

Stage 2: Boardsim at the pin level

The DUT reconnected as it will sit on the board. Pin-level board models, discrete components, controlled-impedance traces. RTL-level DUT internally, physical models externally. Catches interface-level bugs that RTL-only sim never sees: pull-up conflicts, drive strength mismatches, board-level termination problems.

Stage 3: Post-synthesis GLS

The DUT is now the synthesized netlist. Gate-level timing back-annotated from synthesis. The same stimulus that ran at RTL now runs against gates. If synthesis introduced a subtle timing bug (usually around a clock-domain crossing the synthesis tool did not recognize as one), this is where it shows up.

Stage 4: Post-PnR GLS

The DUT is now the placed and routed netlist. SDF back-annotation from PnR. Real interconnect delays. This is where hold violations that the STA tool signed off on but the actual routing did not respect surface.

Stage 5: Final boardsim with GDS-extracted parasitics

The DUT is the same post-PnR netlist, but the board simulation now includes extracted parasitics from the actual GDS. Coupling capacitance, cross-talk paths, IR-drop effects. This is the last chance to catch signal integrity issues before tapeout.

Each stage produces its own report. The flow stops on first failure, or completes with a signoff summary. What the CLI actually looks like at runtime:

$ silverchips verify --flow full
  → rtl_sim              [pass]    2h 14m
  → boardsim (pin-level) [pass]    3h 42m
  → synth_netlist_gls    [pass]    4h 11m
  → pnr_netlist_gls      [pass]    5h 08m
  → boardsim (GDS parasitics) [running...]

Why the annotation flow matters more than the tool consolidation

Any competent team could write a script that runs five tools in sequence. That is not the interesting part.

The interesting part is what the CLI carries between stages. Parasitics extracted from the PnR database annotate back into the gate-level simulation. Thermal analysis from the physical signoff step annotates into the board simulation. Corner cases from RTL coverage flag targeted stress at gate level. Bugs surfaced at one stage feed hypotheses for the next.

Historically, that annotation is manual. An engineer looks at the SI report, decides which signals are risky, hand-writes a stress test, re-runs boardsim. If the engineer forgets, the bug ships.

The CLI does not forget. Every parasitic that exceeds a threshold triggers a targeted board sim. Every corner that fails STA sensitivity triggers a corner-annotated GLS. Every mismatch between RTL and GLS opens a formal check. The annotation propagates automatically.

The signoff summary

At the end of a successful --flow full, the CLI writes a single signoff summary. RTL coverage percentages. GLS mismatch counts (zero, ideally). SDF timing compliance. Board-level SI margins. Parasitic-annotated corner results. Every stage in one report.

For tapeout review, that summary is the artifact. Not five reports from five tools that a human then has to reconcile in a spreadsheet.

What this does not remove

The CLI does not remove the need for verification engineers, physical design engineers, or board designers. It removes the coordination overhead between them.

The DV engineer writes tests. The PD engineer signs off timing. The board engineer characterizes traces. All of them look at the same summary. All of them see the same annotation flow. When a bug appears, it is clear which stage caught it, and which stage did not.

The point

One command. Five stages. One artifact. Zero handoff loss.

Tapeout is stressful enough without five teams staring at five different reports trying to figure out whose bug it is.