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/products/cobalt.html

http://www.chipdesignmag.com/display.php?articleId=1136&issueId=21