News and New Products

Statistical timing analysis moves from interesting to necessary

TSMC's inclusion of SSTA in its new reference flow signals the mainstream arrival of the technology.

By Ron Wilson, Executive Editor -- EDN, 6/6/2008

Statistical static timing analysis (SSTA)—theory, thesis project, IBM proprietary technology—is about to add one more stage to its evolution: mainstream member of the design flow. For some time now IBM has required the use of its statistical tool, EinsTimer, in the signoff process for its ASIC customers. But other members of the Common Platform Alliance, despite sharing processes, have not done the same. So despite the emergence of tools from startups, statistical timing has remained a peripheral issue in the design flow.

Now, in its announcement of Reference Flow 9.0 this week, TSMC has included two different SSTA tools, both from small EDA companies. If the industry needed a signal that the day of statistical timing has arrived, there it is.

"We have been working on statistical timing analysis for quite a while now," reports Ana Hunter, vice president of technology in the Systems LSI Foundry group at Samsung. "We have concluded that it's just about a must at 45 nm, and definitely necessary at 32 nm."

Rather than importing EinsTimer, which is well regarded for its accuracy but has a reputation for an inscrutable user interface, Samsung has decided to stay within what Hunter describes as "the Common Platform's philosophy of commitment to commercially available tools." She says that the company has been working with Extreme DA on the issue.

TSMC, in contrast, came down firmly in support of two competing products: Extreme DA's GoldTime SSTA, and startup CLK Design Automation's just-announced Amber FX. The tools aim at the same goal: more accurate representation of the distribution of timing slack across a population of dice. But they approach the problem in somewhat different ways.

Conceptually, SSTA is not that hard to grasp. Traditionally, we have represented timing slack on a net as a single worst-case number. Lumped into that phrase "worst-case" are all the uncertainties of PVT (process, voltage, and temperature) variations. So timing closure meant slowing the chip down until the worst acceptable die, working at worst-case voltage and temperature, still had positive timing slack.

When process variations were relatively small compared to voltage and temperature variations, working with PVT corners produced an acceptable outcome. But what to do when the combination of process variations—and some fabs track dozens of sources of variation—becomes very large? Designing for worst-case can mean reducing the performance of the chip to previous-generation levels—literally. "TSMC began investigating SSTA when they found that their worst-case corners at 40 nm were slower than they had been at 55 nm," according to Isadore Katz, president and CEO of the recently announced startup CLK Design Automation.

This is the problem SSTA addresses, with a couple of important observations. First, if process variations that impact propagation delay are random, they will tend to cancel each other on long paths. Stated more precisely, if you represent each of the delays not as a worst-case integer but as a statistical distribution, you can move along the path, composing the distribution functions as you go. You will—if the variations are statistically independent—end up with a delay distribution considerably narrower than you'd get by just adding up the individual distribution functions. So instead of the designer being forced to say "If I allow 3.5 nsec for this path I'm certain all the chips will work," she can say "if I allow 2.6 nsec for this path, over time 99.6% of my chips will work, and the tester will catch the rest" (see Figure).

The problems, as always, come in the details, all of which are hidden away in the data files and algorithms these new tools use. One problem is that SSTA requires vastly more data from the fab line than the timing files that accompany cell libraries. The SSTA tool must know not just worst-case corner values for delays through each cell, but also the statistical distribution of these delays across process variations. This requires that the cell library the design uses must be characterized to produce these delay-distribution functions.

And that is one primary difference between GoldTime and Amber FX, according to CLK's Katz. While GoldTime requires detailed characterizations of each cell library as its basic data source, Amber works at the transistor level. The key development, according to Katz, is a very fast-executing transistor model which CLK links directly into the foundry's detailed statistical transistor model. Amber FX then uses this fast transistor model to compose statistical models of the cells in whatever library the user is using, then applies these cell timing models to analysis of the design.

Another important problem for creators of SSTA tools is manipulating the distribution functions. Simple ways of doing this exist—basically, when a signal with one distribution passes through a delay with another distribution, you convolve the functions, assuming the delays are statistically independent. But that process would be crushingly slow to compute. So the tools must abstract the distribution functions with a small set of scalar values. More complex yet, the statistics coming from the fabs have, in the past, been distributions of manufacturing data—critical dimensions, diffusion depths, and the like. The transistor models have to convert those statistics into distributions on the electrical parameters of the transistor model—of which the TSMC BSIM model has eight, by the way—and then convert those electrical parameter distributions into delay distributions, and still end up with something that runs fast enough to be useful in composing timing distributions for cell libraries. CLK attacks this problem by developing a voltage response curve for the transistor, based on the BSIM model, and then computing sensitivity functions to each of the variables in the underlying model.

Finally, there is that question of statistical independence. Delays in the consecutive stages of a path may be independent if their variations are random—say, on-die variations. But if the variations are systematic, they may not be independent at all, and simple ways of manipulating the distributions functions inside the SSTA engines will give wrong answers. So it is necessary, Katz explains, to perform principle component analysis to extract a set of mathematically independent variations.

Getting all this done for a full library, with about 16 copies of SPICE running, takes a few hours for Amber FX, according to Katz. This allows users to work with custom or third-party libraries and percolate changes in the BSIM model from TSMC directly through to the SSTA tool every time changes arrive.

Extreme DA has not been standing still with its tool, either, according to Graham Bell, the company's director of marketing. The company is now promoting GoldTime as a signoff-quality SSTA tool. It can be used not just to perform cell-based analysis of designs, but also to characterize libraries. The tool can execute this process, according to Bell, either on the basis of foundry statistical data or, if those data are not available, on the basis of corner analysis of the libraries. In addition to modeling statistics of the transistors, GoldTime now includes statistical interconnect extraction—a vital issue, given that parasitics dominate delay on many paths. The company recently enhanced the tool to cover on-chip variations as well as between-chip variations, which, as mentioned, requires a different statistical treatment.

TSMC, which has been working with both tools, says it is too early to determine which tool will perform best in which circumstances. What is clear is that SSTA has become, in the eyes of foundry experts, a necessary part of the 45/40-nm flow. Also clear is that to succeed in SSTA a vendor must have an intimate link to the fabs it supports.

Finally, it is further becoming clear that execution time will be a huge issue. Both CLK and Extreme have addressed it explicitly. And both cite, as one of the reasons design teams are interested in execution time, the fact that the industry's de-facto standard, Synopsys' PrimeTime, is simply too slow to cope with today's designs, with their huge complexity, myriad of corners, and multiplicity of nodes.