Vectorless vs VCD-based dynamic IR: what does each assume?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
Vectorless analysis has no simulation vectors: RedHawk builds a realistic worst-case switching scenario from toggle rates, timing windows and the known average power, so it covers cases you never simulated but rests on those settings. VCD-based analysis replays switching from a gate-level simulation with timing, so it is exact for that activity and blind to activity the testbench missed. Standalone RedHawk runs them with perform analysis -vectorless (RH) and perform analysis -vcd (RH); in ICC2 the modes are analyze_rail -voltage_drop dynamic_vectorless (ICC2) and analyze_rail -voltage_drop dynamic_vcd (ICC2).
Technical Explanation
- Vectorless inputs are the timing file from STA (clock frequencies, timing windows and slews) and toggle rates set through GSR keywords. Clock buffers toggle twice every cycle. The scenario is derived statistically, weighted by structural weak spots, timing windows and toggle rates, and constrained to the total average power in the GSR.
- Its switching assumptions: an instance that switches in the first cycle switches the opposite way in the next, and a memory in write mode in cycle one is in read mode in cycle two. The result is a plausible worst case, not a measured one.
- VCD-driven vectorless sits in between. An RTL or gate-level VCD supplies toggle rates and locates the peak power cycle, but the scenario is still built vectorlessly; it runs with
perform analysis -vectorless(RH) and the VCD_FILE keyword set in the GSR. - Event-driven VCD analysis uses gate-level VCD with timing back-annotation, scans the whole VCD for peak power cycles, and replays the switching events and delays of the chosen cycle. The manual uses it when the VCD represents the worst case and for measurement and correlation.
- The trade: vectorless can be pessimistic where logic can never all switch together and optimistic where toggle rates are set too low. VCD is exact for its window and says nothing about modes the testbench did not exercise, such as scan shift or a burst mode.
- In ICC2,
-switching_activity(ICC2) supplies the VCD for the VCD mode, with an optional start and end time window, and the vector-free mode needs no activity file. Voltage drop analysis runs in both RedHawk Fusion and RedHawk-SC Fusion. - Neither mode fixes anything by itself. The dynamic drop map and the design's .dvd report in adsRpt/Dynamic tell you where decap, clock buffer spreading or grid changes are needed.
What To Check
- Toggle rates and frequencies in the GSR match the real design, clock domains included.
- For VCD, the time window really contains the peak power cycle and name mapping covers the instances, which the uncovered-flop reports in adsRpt show.
- Total power of the dynamic scenario against the power team's number.
- Worst drop and its location for both modes, and whether the hotspots agree.
Command Checks & Actions
perform analysis -vectorlessStandalone vectorless dynamic run built from toggle rates, timing windows and GSR power.
perform analysis -vcdStandalone VCD-based dynamic run for the chosen cycle.
analyze_rail -voltage_drop dynamic_vectorless -nets {VDD VSS}Fusion dynamic run with no VCD input.
analyze_rail -voltage_drop dynamic_vcd -switching_activity {VCD top.vcd} -nets {VDD VSS}Fusion dynamic run driven by a gate-level VCD.
report_rail_result -type voltage_drop_or_rise -supply_nets {VDD} -limit 50 dvd.rptWrites the 50 worst dynamic voltage values for VDD.
Healthy, Suspicious & Hard-stop Results
- Healthy (illustrative): Vectorless worst dynamic drop 84 mV and the stress VCD 79 mV, both under the 90 mV limit at 0.75 V, with hotspots in the same region.
- Suspicious (illustrative): Vectorless and VCD hotspots in different places, or VCD coverage reports listing many uncovered flops.
- Hard stop: Either mode over the limit on a clock-tree or high-activity region at signoff, or a VCD run whose window missed the peak power cycle.
Common Mistake
The Trap: Signing off on one VCD from a functional test that exercises a fifth of the design and calling it the worst case. The VCD is exact for that window, but the block's worst dynamic drop happens in a different mode where a large datapath switches at once, and that mode was never simulated or covered by a vectorless run.
What The Interviewer Is Testing
- Knowing what each mode takes as input and what it assumes.
- Knowing VCD-driven vectorless is a third option.
- Explaining why a sound flow runs both and compares hotspots.
Follow-up Question & Model Response
"Which do you trust more at signoff?"
Candidate Model Response: Neither on its own. Vectorless covers switching I never simulated, bounded by total power, so I use it as the main screen. VCD gives real, timing-accurate activity for the modes that matter most, so I use it to confirm hotspots and to correlate. If vectorless shows a hotspot the VCD does not, I check whether that activity can really happen before I spend area on decap.
Practical Example
Tapeout Scenario: A 0.75 V compute cluster with a 90 mV dynamic limit (illustrative). Vectorless with a 0.2 toggle rate on data reports worst drop 84 mV in the shader array. The functional VCD, scanned for its peak power cycle, gives 61 mV in the same region, and power in that cycle is 72% of the vectorless scenario's power. A second VCD from a stress test reaches 79 mV. Signoff uses vectorless as the limit check, the stress VCD confirms the hotspot is real, and decap goes into that region first.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
Continue practising