AdvancedQuestion 10 of 63

Why must all libraries in the scaling groups have CCS noise data specifically, beyond CCS timing?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

Because SMVA (statistical multi-voltage analysis) is a full signoff feature covering noise across voltage combinations, and voltage-dependent noise response - crosstalk bumps and immunity - is captured only in a library's CCS noise models, not its CCS timing tables. A scaling group missing noise data on even one member library breaks the interpolation.

A voltage-scaling group with five library points from 0.6V to 1.0V, four showing complete CCS noise and timing tables and one showing timing data only with a gap in its noise interpolation curve — Technical Reference DiagramWhy must all libraries in the scaling groups have CCS noise data specifically, beyond CCS timing?

Technical Reference DiagramWhy must all libraries in the scaling groups have CCS noise data specifically, beyond CCS timing?

Technical Explanation

What each CCS model type contains. CCS timing describes delay behavior - how a cell drives a load. CCS noise describes something different: current-versus-disturbance waveform data showing how a cell responds to, and propagates, a noise event such as crosstalk.
Why noise is voltage-dependent. Crosstalk bumps and a cell's noise immunity both change with supply voltage, and that voltage dependence lives specifically in the CCS noise models - it is not present in the delay tables at all.
SMVA is not timing-only. It is a full signoff capability that includes noise and signal-integrity analysis across voltage combinations. update_noise and report_noise (PT) are scenario-aware precisely because noise has to be analyzed per DVFS (dynamic voltage and frequency scaling) scenario, not just once.
What that forces on the libraries. To evaluate a cell's noise response at every voltage it might operate at, the tool has to interpolate between library characterizations - and it can only interpolate data that exists. A library lacking CCS noise data has nothing to interpolate from for its portion of the voltage range.
Why the requirement lands on every library, not most of them. A scaling group's whole job is interpolating cell behavior across voltage using define_scaling_lib_group (PT). One missing member breaks the interpolation for the voltage range that member was supposed to cover, not just for that one library.
The distinction to hold onto. Having CCS libraries is not the same as having CCS noise libraries - the requirement here is specifically about the noise models, over and above whatever CCS timing data the library already has.

Common Mistake

Confirming every library in a scaling group has CCS timing data and assuming noise analysis is therefore covered, when noise needs its own, separate CCS noise characterization.
Adding a new voltage point to a scaling group without checking whether its library ships with CCS noise tables, since a vendor library update can add timing coverage without adding noise coverage.
Cost: SMVA noise analysis at the missing voltage point silently falling back to an uninterpolated or default value, understating real crosstalk risk at that operating point.

Follow-up Question & Model Response

A scaling group has five libraries spanning 0.6V to 1.0V, and the 0.7V library was just swapped for a newer vendor release. What would you check before trusting an SMVA noise report at 0.65V?

Candidate Model Response: I would first confirm the new 0.7V library still ships CCS noise tables, not just CCS timing tables, since a vendor refresh can silently drop or restructure noise characterization even when timing data looks equivalent. Then I would check that define_scaling_lib_group still lists it correctly and that update_noise runs without a missing-data warning for that voltage range. A report at 0.65V interpolates between the 0.6V and 0.7V libraries, so if the 0.7V library's noise data changed structure or went missing, the interpolated result for 0.65V would be wrong or unavailable even though the report might still print a number.

Practical Example

A DVFS design scales between 0.65V, 0.80V and 0.95V using a scaling group built from libraries at those three characterization points. The 0.65V library was delivered with full CCS timing tables but the vendor's noise characterization run was never completed for it. Running update_noise across the group logs a warning that the 0.65V member lacks CCS noise data, and report_noise at that scenario returns no crosstalk-bump result for any net - not an approximate one, none at all - until the missing noise library is delivered and the scaling group is rebuilt.

Complete STA Handbook