Timing Override Verification (TOV) Erik Seligman CS 510, Lecture 18, March 2009

Agenda  What is Timing Override Verification (TOV)?  Multicycle Paths  False Paths  Deploying TOV Methods

Agenda  What is Timing Override Verification (TOV)?  Multicycle Paths  False Paths  Deploying TOV Methods

Review: Timing Closure  Check delays of all paths Signals must be fast enough for frequency Flag paths that miss, make circuit changes

Do We Care About All Paths?  Timing overrides: relax checking of path Multicycle Path: May take >1 clk cycle –Often due to crossing to slower clk domain –May be consequence of logic False Path: Infinite time allowed –Path never matters logically  Usually specify in ‘SDC’ format set multicycle path -from … -to … set false path –from … -to …

Dangers of Timing Overrides  What if false or multicycle path is wrong? i.e., logically not really false / multicycle  Chip will not meet frequency Long path operates incorrectly Must slow down clock for proper function  Important to verify!

Verifying Timing Overrides  Often ad hoc: designer inspect manually  Better: create assertions Since SDCs manual, designer can create –Introduce as requirement on design team! Can automate to some extent with scripts Generally hard to FPV –Cross top-level blocks, specified at netlist  CAD tools Fishtail, RealIntent, Atrenta, BluePearl Some claim specialized FPV engines –Optimized to be able to prove SDCs

Agenda  What is Timing Override Verification (TOV)?  Multicycle Paths  False Paths  Deploying TOV Methods

Multicycle Path set_multicycle_path 3 –from f2 –to f3  What assertions might help verify?

Multicycle Path set_multicycle_path 3 –from f2 –to f3  What assertions might help verify? Value at f2 is always held 3 cycles (or 4)? And… ?

Multicycle Path set_multicycle_path 3 –from f2 –to f3  What is needed for this to be valid? Value at f2 is always held 3 cycles f2 transition  stable 3 cycles before some ck2 capture edge

Be careful about capture edge! set_multicycle_path 3 –from f2 – to f3  Bad data is stable for a long time But never stable 3 cycles before capture edge

Sensitization Issue set_multicycle_path 3 –from f2 –to f3  OR rather than XOR: change situation?

Sensitization Issue set_multicycle_path 3 –from f2 –to f3  OR rather than XOR: change situation? Path may not be sensitized In general case, may need to check this condition

General Multicycle Assertion  Important conditions: Input flop to path transitions Path sensitized –not masked by mux or ORed with 1, for example Destination flop samples  Key assertion: (Dest samples & sensitized)  (!Transition for last cycles)

Agenda  What is Timing Override Verification (TOV)?  Multicycle Paths  False Paths  Deploying TOV Methods

False Path Example set_false_path –from f2 –to f3  What assertions would be useful here?

False Path Example set_false_path –from f2 –to f3  What assertions would be useful here? Path never sensitized: !(s1==0 && s2==1) Any others?

False Path Example set_false_path –from f2 –to f3  What assertions would be useful here? Path never sensitized: !(s1==0 && s2==1) Sensitization condition correct: (!(s1==0 && s2==1))[*2] ##0 $stable(d2) |-> $stable(n1) (if not sensitized && other inputs stable  output stable)

False Path Example set_false_path –from f2 –to f3  What assertions would be useful here? Path never sensitized: !(s1==0 && s2==1) Sensitization condition correct: (!(s1==0 && s2==1))[*2] ##0 $stable(d2) |-> $stable(n1) (if not sensitized && other inputs stable  output stable) Or just “$stable(d2) |-> $stable(n1)”?

Agenda  What is Timing Override Verification (TOV)?  Multicycle Paths  False Paths  Deploying TOV Methods

Generating TOV Asserts  Simple method: Designers write + Designers write SDCs, so know design + Low overhead to introduce - May not be accurate, complete  CAD tools + Automatic - Additional tool in flow– is output saved? - May be noisy

Checking TOV Asserts  Simulation + Automatic if asserts added to RTL - Depends on test suite  FPV + High confidence, fuller coverage - Hard to prove - often specified at top level of large blocks - (vendors claim specialized engines)

One more wrinkle  Designers generate SDCs on netlists Not on RTL Assertions involve non-rtl signals  Solutions? DEs can manually convert to RTL asserts –Should be late in project, FEV mapping available Tool solutions: Fishtail “refocus” Generate & check asserts on netlist –Gate-level simulation

Other Complications  “-through” exceptions? Make asserts more complex: ensure that ‘through’ node is controlling transition when checking  Multicycle path at asynchronous CDC Bad luck: might hit metastability window Be careful to hold value an extra cycle

A Further Opportunity  Auto-identify false/multicycle paths? Capability in some tools (Fishtail, RealIntent) Both identify and prove the paths Lots of TOVs  easier to close timing  But is this too risky? Tools get thousands of these paths DEs nervous if unreviewed paths in design Low impact on timing closure –Small set of critical paths are what matter  Few design teams adopt auto-TOV methods

Conclusions  Multicycle / False paths are risky But needed for timing closure  Can generate asserts for safety  Several choices in strategy Manual asserts or CAD tool Simulation or formal RTL or netlist level  Plenty of reasonable sets of choices give much increased level of TOV confidence!

References / Further Reading    s/spyglass_constraints.htm s/spyglass_constraints.htm  ts/cobalt.html ts/cobalt.html  hp?articleId=1136&issueId=21 hp?articleId=1136&issueId=21