AdvancedQuestion 45 of 63Source: Synopsys PrimeTime User Guide: Noise Modeling With CCS Noise Data

How do CCS timing and CCS noise models work together during signoff?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

A CCS timing model in the Liberty (LIB) library describes how a cell's output current drives its load, so PrimeTime can compute delay and slew accurately even when interconnect resistance rivals the driver's own resistance. A CCS noise model, a separate table in the same Liberty file, describes how well a cell resists or amplifies a glitch injected by a switching neighbor. Signoff loads both because a design can pass every delay check and still fail because a quiet net glitches past its receiver's noise-immunity threshold.

Two side-by-side Liberty table icons for one buffer cell -- a CCS timing current-vs-time curve feeding report_timing, and a CCS noise voltage-bump-vs-width immunity curve feeding report_noise, both reading the same SPEF-annotated coupling capacitance. — Technical Reference DiagramHow do CCS timing and CCS noise models work together during signoff?

Technical Explanation

Delay signoff and noise (glitch) signoff ask different questions: CCS timing answers how long an arc takes, CCS noise answers how big a bump an input can tolerate before it looks like a real edge.

The CCS timing table models the driver as a time-varying current source rather than a fixed resistor, which is what lets PrimeTime compute an accurate delay and output transition even when interconnect resistance is comparable to the driver's own resistance.
The CCS noise table adds a receiver noise-immunity curve -- how much voltage bump at a given width the input can absorb -- plus a driver holding-strength table describing how well a driver's output resists being pushed by a coupled aggressor.
report_noise (PT) uses the CCS noise tables together with the annotated coupling capacitance from the SPEF file to flag a net whose predicted glitch exceeds the receiver's tolerance.
A cell library missing CCS noise data can still run full delay signoff cleanly, because delay calculation only needs the CCS timing tables -- the noise check is silently skipped rather than flagged as an error unless the flow explicitly checks for missing data.
Because both tables live in the same .lib file per cell, a partial library update -- timing regenerated, noise tables left stale -- creates a signoff run where delay numbers are current but glitch predictions are not.

Common Mistake

The Trap: treating 'the library has CCS data' as one fact, when a cell can carry CCS timing tables without carrying CCS noise tables, or with noise tables from an older library revision.

Consequence: report_noise (PT) runs without error and produces a report, but every number in it reflects an outdated receiver tolerance, so a genuine crosstalk-glitch risk on a newly added net passes a check that looks complete.

Follow-up Question & Model Response

If report_noise runs without any error message, how would you confirm the noise tables it used are actually current, not stale?

Candidate Model Response: Silence from report_noise only means the command executed, not that the loaded library carries current noise data, so the check has to start at the library itself. The designer would confirm the .lib file's revision date and diff its noise-model section against the version used for the previous signoff pass rather than trusting the report alone. Checking one representative cell's noise-table values against the vendor's release notes for that revision catches a partial regeneration where timing tables were refreshed but noise tables were carried over unchanged. Because PrimeTime does not compare table vintages across a design's library set, this verification step sits outside the tool, in the library-qualification checklist, not the timing run itself.

Practical Example

A 5nm standard-cell library ships CCS timing tables for all 1,800 cells but CCS noise tables for only the buffer and inverter families in its first qualification drop -- the sequential cells' noise tables arrive two weeks later. A team running full-chip signoff during that gap gets a clean report_noise (PT) result because the flops it queries silently fall back to a default noise-immunity assumption instead of erroring, hiding a genuine 140 mV glitch on a scan-enable net that only shows up once the complete noise library lands.

Complete STA Handbook