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?• 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?
• 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?
• 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!