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 <n> -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 <n> 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
 http://www.fishtail-da.com/
 http://www.realintent.com/
 http://www.atrenta.com/solutions/product
s/spyglass_constraints.htm
 http://www.bluepearlsoftware.com/produc
ts/cobalt.html
 http://www.chipdesignmag.com/display.p
hp?articleId=1136&issueId=21