How does a receiver's noise immunity curve decide whether a crosstalk glitch becomes a functional failure?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
A crosstalk glitch on a quiet net is only a real problem if the receiving gate is weak enough to be fooled by it, and Liberty's CCS noise (composite current source noise, a table format capturing how a cell's output responds to a disturbance) tables define exactly how much glitch height and width a given receiver can absorb before it forwards a wrong value. PrimeTime compares the actual glitch it calculates on the victim net against that receiver-specific immunity curve, not against one flat voltage threshold.
Technical Explanation
- Crosstalk noise, as opposed to crosstalk delay, is a voltage bump on a net that should be holding a steady logic value, caused by a neighboring aggressor switching.
- A receiver's noise immunity curve, built from CCS noise (CCSN) data in the Liberty file (LIB), plots how large a glitch of a given width the gate can tolerate at its input before its output is disturbed enough to propagate.
- A short, narrow glitch needs more amplitude to cause trouble than a wide, slow one, because the receiving gate's internal switching threshold responds to both the height and the duration of the disturbance together.
- The tool compares the calculated glitch arriving at the receiver against that receiver's specific immunity curve, so the same glitch can be safe at one gate and unsafe at a weaker one downstream.
- Because the immunity curve is a property of the receiving cell in the library, swapping to a stronger-drive or different-threshold cell at that input can fix a noise violation without touching the aggressor net at all.
- This is a separate check from crosstalk delay: a design can pass every delay-based setup and hold check while still carrying a noise violation that could flip a value mid-cycle, independent of the clock edge.
- Because a glitch can propagate through several downstream gates before it reaches a storage element, noise analysis also has to track how the glitch's height and width change as it passes through each stage, not only the first receiver it touches.
- A net driven by a much stronger cell, or one held by a keeper or feedback structure, is naturally harder to disturb, so library choice and driver strength on the victim side are just as much a lever against noise as spacing on the aggressor side.
Common Mistake
The Trap: treating any measurable glitch on a quiet net as a violation, without checking it against the receiver's actual immunity curve for that glitch's width.
- A tall but very narrow glitch can be well within tolerance at a robust receiver, so flagging every visible bump wastes ECO effort on non-issues.
- Fixing a noise violation by resizing the aggressor's driver instead of checking the receiver's immunity curve can miss a much cheaper fix at the victim side.
Follow-up Question & Model Response
If a noise violation does not directly cause a timing failure, why does PrimeTime report it as a signoff issue at all?
Candidate Model Response: Because a noise glitch that crosses the receiver's immunity threshold can flip the logical value the gate forwards, independent of setup or hold timing entirely, meaning the chip can compute the wrong answer even with clean timing everywhere. PrimeTime reports it separately from delay-based checks because the failure mechanism is different: it is a functional corruption risk, not a race against the clock edge. Signoff treats an uncorrected noise violation as seriously as a timing violation, since either one can produce a chip that does not work in silicon even though it looks clean on paper.
Practical Example
A quiet reset-distribution net sits next to a fast address bus, and PrimeTime's noise analysis calculates a 180mV glitch with a 90ps width at the input of a weak-drive INVX1 receiver. That cell's CCS noise table shows its immunity threshold at 90ps width is only 150mV, so the glitch violates by 30mV. Swapping the receiver to an INVX4 cell, which has a higher immunity threshold at the same width because of its stronger internal drive, clears the violation without touching the aggressor bus or adding any spacing. Checking one stage further downstream confirms the glitch, already reduced by the stronger receiver, does not reappear at the next gate's input either, so the single cell swap resolves the noise path end to end rather than just moving the failure one stage later.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Continue practising