Subscribe to EDN

Magma Tekton: rethinking static timing analysis

March 10, 2010

Static timing analysis (STA) was nearly an instant success at timing closure 15 years ago. But except for creating partitioning/scheduling algorithms to parallelize the algorithms for multicore CPUs, nothing much has changed since, if you will grant that statistical timing analysis is a separate subject.

This languishing has allowed the number of instances in a design, the number of modes in which a design must be analyzed, and the number of process corners each to grow enormously, while the speed of STA remained tied to the comparatively much slower growth in computing power. Consequently, run-times for full designs across modes and corners have become enormous—days, in some cases. That has turned STA from an elegant, fast tool into a powerful, trusted, but ponderous necessity, consuming licenses and days of precious schedule with abandon. If there were a way to speed up STA dramatically, users would need fewer licenses, could save the real-estate and power costs for huge server collections, and they could employ the tool in situations where it has become impractical today, such as checking timing constraints or evaluating ECOs.

There are several alternatives to accelerate STA. To begin with, the task is embarrassingly parallelizable. Most nets are independent with regard to delay, so you can organize the nets into independent sets and dispatch them to independent threads. That makes STA inherently friendly to multicore computing, and in principle also to cloud computing—should we ever figure out what that is—and more practically to execution on graphics processors. But according to Magma technical marketing manager Dan Blong, it’s been 15 years since anyone looked at the underlying algorithms and the code to see if there were other ways to accelerate the analysis.

That is what a team headed by Pathmill pioneer Jacob Avidan set out to do two years ago. The result, according to Blong, is a new STA/extraction/SPICE environment: Tekton. Magma claims that as a timing analyzer, Tekton runs significantly faster on a single CPU, and dramatically faster in a multi-mode/multi-corner analysis on a multi-core machine. The company summarizes these claims with the presumably somewhat hyperbolic slogan "any design, one machine, in under an hour." They support this claim with stated speed of one million nets per minute, and near-linear scaling for up to 24 CPUs.

The greater performance comes primarily, Blong says, from careful organization of the work to avoid having to repeat calculations. This presumably means recognizing tasks that are unnecessary as well as saving intermediate results for use in future calculations, especially across modes and corners. It does not mean compromising timing accuracy: Blong says Tekton correlates very well to PrimeTime delay results, and approximates PrimeTime crosstalk results, an area on which the team is still working.

Tekton is designed to drop into existing flows, accepting PrimeTime tcl and Perl scripts. As a complete environment, Tekton includes the Tekton QCP extraction tool—which correlates to QuickCap—as well as crosstalk analysis, on-chip variation analysis, and an integrated SPICE engine. In addition to being able to time an entire design in under an hour, the package includes an incremental mode that lets you work on particular blocks of IP or on ECOs diretctly.

Faster STA appears to be the only alternative left after the industry has seemingly rejected statistical timing analysis, preferring instead to let the number of PVT corners go through the roof. Magma says Tekton is designed to accommodate 15 or more PVT corners in a multi-mode analysis, with up to 54 total cases. Whether that is going to be sufficient to handle the increasing dominance of process variations without falling back on massive guard-banding remains to be seen.

Posted by Ron Wilson on March 10, 2010 | Comments (6)

March 18, 2010
In response to: Magma Tekton: rethinking static timing analysis
Jim McCanny, Altos commented:

The biggest innovation in STA in recent years has been SSTA. However I would argue that most of the innovation in SSTA is actually in the efficient characterization of the library models and the creation of statistical SPICE models that feeds SSTA characterization. Designers have been slow to adopt SSTA I think for two main reasons: 1) It's new, so there is only limited proof that it really works in silicon; 2) The IP vendors are not supplying the libraries as this is an additional burden for them. I believe 1) will be solved in due time; for 2) customers will search for tools and services from vendors who can provide SSTA libraries for ALL commercial SSTA tools. We are certainly one of just several vendors and, in my mind, the most comprehensive vendor to provide SSTA tools and services.


March 13, 2010
In response to: Magma Tekton: rethinking static timing analysis
8F5K5 commented:

Performance in STA had improved on single core. When you are comparing performance, you have to bear in mind that delay computation models have changes a lot requiring more computation and chip sizes have increased exponentially in those 15 years. Yes the compute power also improved but my and large STA have kept pace on performance. Your statement that every net can be computed in parallel is not completely true. Most rely on computation of fanin and adjacent nets.


March 12, 2010
In response to: Magma Tekton: rethinking static timing analysis
ron commented:

EdaGuy: Thanks for making a whole bunch of excellent points. I should have been more clear. All of the items you listed of course were significant changes in STA tools. But they addressed accuracy or new analysis needs, not performance. I think that was what Magma was saying. I would love to discuss further whether statistical timing is an evolution of STA, though. I see your point that it is a step to solve the same basic problem in a more complex environment. But I wonder if the low adoption rate outside of IBM is because SSTA is so unlike STA in the way people have to think about its results. In any case, as always thanks for reading closely and adding information to the post. ron


March 11, 2010
In response to: Magma Tekton: rethinking static timing analysis
EdaGuy commented:

That being said, if your point was "has the leader in STA aggressive kept up with user's needs or even gone far enough to more than exceed what they need and actually do their wishes too"... I would agree the answer is no. Unfortunately in the world of EDA, typically it takes a new entry in the market to cause someone to innovate their bread and butter. Most companies realize this after its too late. Dracula RIP.


March 11, 2010
In response to: Magma Tekton: rethinking static timing analysis
EdaGuy commented:

I will not grant you not much has changed in STA in 15 years. Let's see, off the top of my head: 15 years ago we used a very simple timing model, either a constant cell delay, or a delay as a function of output load. Then came CMOS4 models. Then came resistance and AWE, and now more complex algorithms for wire delay analysis. Then came SI impact on delay. Then came OCV. Then came CCS models for both delay and noise. Then came AOCV. Then came voltage scaling and multiple voltage domain analysis. And SSTA is not a separate subject, it is merely an evolutionary step in the design margining which started with the baby step of OCV. Ya, alot of people aren't using it yet, and its computationally very complex. But its not a separate subject. OK, so that's from the delay calc standpoint. 15 years ago, chips were small. Many were single clock systems, or maybe a few clocks. Today's larger chips have 50-100 clocks or more. That causes your number of timing exceptions to increase dramatically. Or maybe you can show me your "set_false/multicycle_path" file from your 15 year old chip. Oh ya, and generated clocks. And clock trees. (ya, remember, 15 years ago most clock trees were a "trunk" drawn with a fat wire and large clock buffer) And the multicore stuff... that's something the "big guys" haven't done until recently (and only when Extreme and CLKDA came up with it) Now maybe it took them 15 years to get multicore right. Or maybe they aren't incentivized to make their tool faster because that would mean I could buy less licenses... their only incentive is to make their tool just fast enough that I don't switch to their competition. So remind me again, how has "nothing much has changed since"? Please, when you talk to EDA vendors, don't just repeat their marketing catch phrases.


March 11, 2010
In response to: Magma Tekton: rethinking static timing analysis
Tom commented:

Designers need up front modeling in their design flows to prevent timing problems downstream. But what front end modeling tools are out there for designers to use?

POST A COMMENT
Display Name
captcha

Before submitting this form, please type the characters displayed above. Note the letters are case sensitive:

Advertisement
Advertisement
Advertisement
About EDN   |   Site Map   |   Contact Us   |   Subscription   |   RSS
© 2012 UBM Electronics. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy

Please visit these other UBM Canon sites

UBM Canon | Design News | Test & Measurement World | Packaging Digest | EDN | Qmed | Pharmalive | Appliance Magazine | Plastics Today | Powder Bulk Solids | Canon Trade Shows