In early-access with several RF teams, the first thing we noticed was where verification stalled. Skycore's first several months showed that simulation itself was rarely the issue. Once a run starts, the time sink is usually behind it: preparation before launch and investigation after completion.
Three recurring patterns appeared across teams with different products and EDA stacks. Each one has a distinct problem and fix; using the wrong fix wastes effort.
Bottleneck 1: Fresh Testbench Setup Every Time
Most often, engineers spent two to four days building a testbench for a new IP block after its specification was ready. Speed was not the issue. Starting with a blank file, a well-written SystemVerilog testbench for a moderately complex RF behavioral block takes that long: UVM agents, interface definitions, stimulus sequencing, checker assertions, coverage, and simulation management are simple pieces, but there are many of them.
The result was predictable: verification got squeezed as a tapeout milestone neared. When block RTL arrived three days late, the RTL engineer worked the weekend, hiding the two days lost. Verification could not begin until the RTL interface settled, so its two-day assignment began two days late and was compressed at the window's end.
The answer is not faster testbench coding. Generate its boilerplate from the block spec, letting the verification engineer begin with test logic instead of infrastructure. Across blocks, the skeleton, instantiation, clock generation, reset sequence, and summary reporting follow the same pattern and need no engineering judgment. Scenario design and assertion thresholds do need that judgment, so an experienced verification engineer should spend time there.
Teams using generated testbench scaffolding cut effective start-to-first-simulation time from two to four days to roughly one day. That day went to reviewing generated stimulus parameters and adding test cases missing from the spec. Total work stayed similar, but boilerplate no longer blocked the substantive work.
Bottleneck 2: PVT Sweep Script Upkeep
The second bottleneck was PVT corner sweep management. A complete RF block sweep coordinates the simulator, process-corner parameter files, supply voltage, temperature, and result collection. Teams used shell scripts or Makefiles. They worked reliably at first, then gathered technical debt as block parameters and EDA tool versions changed, while new corner combinations were added without matching documentation.
As a result, teams ran PVT sweeps less often than needed. Execution meant reading and debugging scripts preserved through institutional knowledge, not documentation. Teams checked nominal plus two stress corners, planning the full sweep later. That "later" drifted toward tapeout, when running it and discovering a failure cost the most.
This is mainly a process-discipline issue, though tooling contributes. Generate the corner sweep script from the same spec description as the block, keeping it aligned with block parameters and project-configured process corners. If supply tolerance moves from plus-or-minus 5% to plus-or-minus 10%, the script changes automatically. The spec is the documentation, so no separate script needs maintenance.
The process change is to make the full PVT sweep a required gate before marking a block verified, rather than an optional depth check. Tooling helps by making that sweep as simple to run as the nominal case, removing the practical reason to skip it.
Bottleneck 3: Failure Triage
The third bottleneck was the interval from simulation failure to confirmed root cause. Engineers typically read the message, inspect the waveform, guess which RTL block is responsible, add RTL debug output, rerun, and test the hypothesis. Depending on the failure and the engineer's familiarity with the block, this takes anywhere from an hour to a day.
In RF behavioral blocks, the fault often sits at the boundary, not inside the block. The stimulus may be wrong, since NF measurement needs a specific noise floor stimulus rather than only a sine wave input. Or the measurement may use the wrong domain, such as linear output power when the spec constraint is in dB. Such cases resemble design faults but are testbench faults, and separating them requires careful reading of both testbench and RTL.
The remedy is not quicker debugging, but clearer generated failure reports. On an assertion failure, report the measured value, expected range, source spec, and operating condition, including frequency, temperature, and supply. "NF_CHECK FAIL: measured 3.12 dB, spec max 2.5 dB, at 2.48 GHz 85C SS corner" can be acted on immediately. "assertion failed at time 3500" forces a rerun with extra debug output.
// Assertion with informative failure reporting
assert_nf_spec: assert (nf_actual_db <= NF_TYP_DB + NF_MARGIN_DB)
else begin
$error("FAIL assert_nf_spec: nf=%.2f dB exceeds (%.2f + %.2f) dB limit | f=%.3f GHz T=%.0f C Vdd=%.2f V",
nf_actual_db, NF_TYP_DB, NF_MARGIN_DB,
freq_ghz, temp_c, vdd_v);
fail_count++;
endUseful failure messages move the bottleneck from identifying the failure to deciding how to fix it. The first is mechanical; the second needs engineering judgment. Shortening the path to that judgment improves cycle time.
What These Three Bottlenecks Share
All three occur before or after simulation, rather than within it. The simulator is not the constraint. In the teams we observed, testbench writing and corner sweep scripting before launch, plus failure triage afterward, consumed most verification cycle time.
Improving simulation throughput, with a faster simulator or more compute, does not help one of these three bottlenecks. A faster simulator means the four-day testbench-writing cycle ends in a two-minute run rather than a ten-minute one. The saved time is two minutes out of four days; the bottleneck remains.
For RF IC teams, worthwhile verification productivity work sits before and after simulation: generated testbench infrastructure, scripts linked to the block spec, and assertions that yield actionable failure messages. These changes reduce the actual duration of a verification cycle.