1. Continuing Challenges in Static Timing Analysis
Tom Spyrou
TAU 2013
3/2013

2. Goal of this talk Higher level than latest trends
Remind ourselves the trade-offs we have made as an industry to have a workable solution for STA
Signoff
Embedded in Design Synthesis and Optimization
Plenty of discussion on new effects, lets discuss core STA
Explain basis of industrial algorithms to academic community
Challenge ourselves to look at the issues again
Technology trends
Design
Compute

3. Why Static Timing Analysis
Dynamic simulation is impossible for even a small chip
Assume combination logic only
100 inputs implies 2^100 vectors needed to verify timing which is about 10^30 vectors
If a simulator could process 10^6 vectors per second this works out to a sim time of 10^19 days or about 10^15 years
Talk about a verification bottleneck!
Now add in state elements and the problem of making sure the critical path is actually in the vector set
STA can analyze such a design in 1 minute
There are some issues, but they can be mitigated
STA’s quality of result is not dependent on the quality of the vector set

4. What is the trade-off / core issues
What is the trade-off / core issues? These have been unchanged for a long time
A different kind of setup
Result is dependent on quality of constraints and exceptions
If all storage elements are clocked and i/o’s constrained generally safe
Less accurate delay analysis
Exact path is not really known as with event driven simulation
When STA was first introduced this was less of an issue, PBA now essential
Introduction of false paths due to topological not functional analysis
Users have to manually specify these
Multiple circuit modes take extra effort
Not just more vectors
Loops and level sensitive latches add complexity

5. Analysis
Every circuits looks the same to STA since it ignores the functions of the logic.

6. Topological analysis
Simplifies problem, possibility of reporting false paths

7. What do recent trends mean
Design
Hyper-optimization means accuracy is critical
When a chip is designed at a bleeding edge technology it will be pushed on all dimensions of power, performance and area
Simulation based delay calculation
Path based analysis
Design size means memory use is #1 problem
Largest chips are approaching 1TB of RAM needed for flat runs
Hierarchical / Parallel solutions must prioritize memory use on compute nodes
Runtime also needs to be faster but the first step is to run on machines with reasonable cost
Recent design uses 750+Gig of RAM for single mode/corner STA
Compute
CPU is cheap, data movement is expensive
Whenever you hear its an expensive calculation don’t avoid it
Parallel computing must not only improve performance but also accuracy and features.
Don’t just make the same problem go faster or just divide the data

8. If you ask a designer what doesn’t work well
Hierarchical timing in the final verification loop
SI calculations very conservative
SDC’s are large and hard to verify
Worst case timing is done and process variation is modeled very pessimistically
Block based analysis loses too much accuracy
True delay (looking at combinational logic to prove a path true) reporting is slow and can’t run during optimization
Libraries limit flexibility of analysis

9. STA Industry and Academia
STA technology has been innovated inside Industry much more than in Academia
The key approaches are not documented
There is no open source reference to build from
Industry protects the core concepts as trade secrets
Academia does not (rarely) publish on STA beyond single clock designs or delay calculation
We need a book on the core search algorithm

10. Example, Veritime from the 90’s
STA Engine that required vectors for the clock
Dynamic simulation of the clock
Period, multicycle paths, clock to clock false paths automatically determined
STA for data portion
Absorbed by Cadence and forgotten since at the time SDCs were a lot easier to hand inspect

11. Requirements of an STA Engine
I would like to begin by documenting the basics that everyone in Industry knows. There are no company specific trade secrets
Must run in linear memory and runtime with circuit size, number of clocks, exceptions, and number of storage element
Touch each vertex only once, maybe twice to simplify pre-processing, not once per clock or exception
Must support SDC timing constraints
Clocks, clock tree assumptions, multi-cycle paths, false paths, path delays, cases and modes
Must be nearly spice accurate in delays and support path based
Must be incremental enough
Netlist changes / full retrace on one extreme
Query based incremental with limited tracing on the other

12. The Basic Search The Graph
Startpoints are inputs to the circuit and clock inputs to storage elements
Endpoints are outputs of circuit and data inputs of storage elements
Propagate the Clocks
For each clock input BFS to all clock data pins
Offset startpoint arrival times and end point required times with information from the clock propagation and cycle accounting
Propagate the Data
Use a BFS from startpoints to end points
Use multiple timing totals at every pin to take into account multiple clocks and exceptions
Can optionally store back pointers to record K critical paths but this time/memory is wasted on optimization programs and should be left to a reporting phase

13. Multiple Timing Totals with Partial Path
Simplistic implementation is that each clock and each exception gets its own total
Simultaneously or via separate traces
Memory and/or runtime increase quickly
Occurrence pins are the most common netlist object
There can be thousands of exceptions
At Timing endpoints like totals can be combined and evaluated
At Timing endpoints point to point exceptions can be evaluated

14. Multiple Timing Totals

15. Multiple Timing Totals with path completion data
A BFS has no information about paths
However timing exceptions are specified in terms of from, through, and to paths with a boolean expression of pins
Mcp –from a –through {b c} –to d
From a through b or c and also through d
Each total can have a small state machine about what exception points it has seen
At timing endpoints like totals with like exception point data can be combined or if false not combined

16. Through exceptions

17. Framework can be used for Clock Pessimism
d1,d2
Arr 1
d1,d2,d3
Arr 2
d1,d2
Arr 1
d1,d2
Arr 1
d1,d2,d3
Arr 2
d1,d2
Arr 1
d1,d2,d3
Arr 2
d1,d2,d3
Arr 2 d3 d2 d1 17

18. Delay Calculation, Multiple Timing Totals
Worst case slew merging is pessimistic but allows Delay Calculation to be a pre-process step
If Delay Calculation is done in the BFS the critical slew merging can be done
It is also possible for each timing total to carry its own slew to improve accuracy
Loops can be auto detected and dynamically broken avoiding accidental critical path breaks

19. Incremental Timing Netlist edits, full retime
Netlist edits, fanout cone retime
Netlist edits, query based retime
The choice of how incremental to go depends on the optimization approach
More global cost functions require less incrementalness
More locally greedy approaches require more

20. STA needs innovation Increased sharing to Academia
Increased research on the problems that are still problems
Redirect solutions in light of the Design and Compute trends
There is a lot of interesting work to do!

21. Some ideas New constraint language that is more functional
Try to propagate the function with the delays
Some combination with cycle based simulation
Constraint language enhancements
Library-less delay models
New data model which is stage based
Focus on data locality
Hierarchical timing model which is truly context independent within acceptable limitations
Constraint improvements to help constraint blocks more accurately