The bottleneck in most SoC verification projects is not the sims. It is the testbench. A block goes from RTL-clean to first UVM run over weeks, not days. Environment scaffolding, VIP hookup, sequences, config knobs, coverage. All of it has to be written before a single directed test lands.
We built the Silverchips DV CLI to compress that gap. Feed it a YAML spec. Point it at our VIP library. In under a minute, it emits a compilable UVM environment.
This is a walk through what happens between silverchips gen-tb and the 42 files that land on disk. And why the YAML spec matters more than the model behind it.
The spec, first
The CLI takes a YAML file that describes your SoC at the interface level. Not the RTL. Not the microarchitecture. Just what the block looks like to the outside world.
# soc.yaml
top: my_soc
interfaces:
- name: cfg_bus
kind: axi4-lite
role: slave
width: 32
- name: mem_bus
kind: axi4
role: master
width: 128
outstanding: 16
- name: pcie_x4
kind: pcie
role: root
gen: 4
lanes: 4
- name: irq_out
kind: signal
direction: output
clocks:
- name: cfg_clk
freq: 200e6
- name: mem_clk
freq: 800e6
- name: pcie_ref
freq: 100e6
resets:
- name: por_rstn
active: low
sync: async
That is roughly forty lines of spec for a real SoC block. Everything downstream is generated from it.
VIP selection
The CLI matches interface descriptions to our VIP library. AXI4-lite maps to a config-transaction VIP. AXI4 pulls in a full transactor with burst, outstanding, and coherency modes configured. PCIe pulls in our Gen4 root complex model with configuration space, TLP generation, and completion handling.
VIP selection is not a lookup. The CLI reads parameters (width, outstanding depth, coherency mode) from the YAML and configures each VIP accordingly. Where the spec is ambiguous, it asks. It does not guess.
Environment scaffolding
Every UVM environment has the same skeleton. Agents, driver, monitor, sequencer, sequence library, scoreboard, config object, coverage collector. The generator writes all of it. Concretely, the output looks like this:
tb_top.sv simulation top
my_soc_env.sv UVM environment class
my_soc_config.sv configuration object
agents/
cfg_bus_agent.sv AXI4-lite agent
mem_bus_agent.sv AXI4 agent
pcie_agent.sv PCIe agent
sequences/
reset_seq.sv standard reset flow
cfg_smoke_seq.sv basic register access
mem_walk_seq.sv memory stress pattern
pcie_enum_seq.sv PCIe enumeration
scoreboards/
cfg_scoreboard.sv register readback check
mem_scoreboard.sv memory transaction check
coverage/
cfg_cov.sv config bus coverage
mem_cov.sv memory bus coverage
tests/
base_test.sv
smoke_test.sv
Makefile
Forty-two files, all compilable. Your verification engineers extend the sequences, tune the coverage bins, and go.
What the agent model actually does
The model is the smallest interesting part of this. It reads the YAML. It selects VIPs. It fills in a set of well-tested templates. It resolves the dozen or so small decisions a human would otherwise make. Does this AXI need REGION signals? Should the interrupt be level or pulse? What is the default outstanding depth? Which clock is the config bus running against?
The model is not writing your verification plan. It is scaffolding the environment your plan runs inside.
Why the spec matters more than the model
You can put a big model behind a bad spec. The output is still bad.
The reason the CLI produces useful testbenches is that the YAML forces the design engineer to describe the block properly. What the interfaces are. How they clock. Whether they need coherency. What resets look like. If you cannot write that spec, you cannot verify the block, regardless of whether an agent scaffolds the TB or a human does.
The spec is doing the work. The model is just fluent enough to translate it into UVM.
What it does not do
The generated TB is a starting point. It does not:
- Write your test scenarios. It generates smoke sequences and standard stimulus. The tricky corner cases that catch real bugs are still human work.
- Bind formal properties. Assertions are yours to write against the microarchitecture you know.
- Verify performance. The generated scoreboards check functional correctness, not throughput or latency.
What the CLI removes is the weeks of environment plumbing that has to happen before any of that harder work can start. From spec to first run_test is usually the same evening. Design engineer plugs in the DUT, verification engineer plugs in a directed sequence, by end of day a smoke test runs against real RTL.
The next note covers the second flow, silverchips verify --flow full, which runs the entire verification pipeline (RTL sim through GDS-parasitic boardsim) from a single invocation.