design tools

Static Timing Analysis Increases ASIC Performance Given their ability to handle asynchronous clocks and incremental analysis, the new tools might just save you time and boost your design's performance. by Dean Bronnenberg

Owing to the complexity of the newest ASICs, static timing analysis is fast becoming a prerequisite to achieving a reliable working part. Using powerful, user-friendly, second-generation static timing analyzers that support incremental analysis capabilities, ASIC designers can uncover timing problems in minutes and quickly optimize them to achieve dramatic improvements in overall chip performance.

At Radix Technologies, we develop and manufacture telecommunications signal processing technology using digital adaptive beamforming and null-steering technology. As they are for many telecommunications and mainstream electronic equipment manufacturers, ASICs are a fundamental building block in our designs. We specifically rely on them to perform some of the complex algorithms used in our beamforming systems, as well as in other DSP and digital receiver/transmitter systems. These ASICs must work the first time; our schedules and budgets seldom allow the luxury of a second spin.

As can be expected, we take great pains to thoroughly examine and verify the designs before releasing them to our ASIC vendor. Their size and complexity, though, have placed a serious burden on both functional testing and timing verification. Exploding test vector sets, massive hardware requirements, and long simulation times all delay the delivery of our products. Traditional simulation-based timing verification methodology consumes far more time and engineering resources than we can afford.

Figure 1	FFT clock domains
The RACE FFT includes the JTAG clock domain (blue) and the system clock domain. The system clock domain consists of two distinct components, a balanced clock feeding the FFT core (red), and a second section feeding the output registers (green).

Our newest ASICs are teaching us that static timing analysis is a prerequisite to achieving a reliable working part--and that the static timing analyzer gives us a fast, efficient way to thoroughly examine an ASIC's timing. Analysis uncovers subtle timing issues that can make the difference between a viable part and one that malfunctions, typically out in the field. Not only is its throughput orders of magnitude faster than functional test, but it doesn't require test vectors that can be very time consuming to create.

Despite the benefits of static timing analysis tools, designers have shied away from them because they were once so difficult to learn and cumbersome to use. However, major improvements in the user interface and capabilities in second-generation tools have made the approach much more attractive. In our latest RACE FFT ASIC design, we used one such tool (Mentor Graphics SST Velocity) to verify and enhance the performance of the ASIC and were extremely pleased with the results. Using the tool to analyze the entire chip helped us identify and optimize critical timing paths to achieve an impressive 35 percent increase in the chip's timing performance. The speed increase allowed the RACE FFT ASIC to fulfill the needs of our next system without a respin to a smaller geometry.

Demands of the design
The RACE FFT ASIC is a fundamental building block used in a wide range of commercial telecom, signal analysis, and military systems. The chip performs real-time analysis and generation of signals for applications that include continuous real-time spectral analysis, support for test equipment, and spread spectrum signal reception and transmission for such technologies as ADSL and emerging high-definition television. At the core of the RACE FFT is a proprietary implementation of a cascadable fast Fourier transform (FFT) processor for real or complex data. Programming options directly support forward and inverse FFTs, as well as discrete cosine and sine transforms (DCT and DST), for spectral analysis or frequency-based signal generation.

Two cascaded chips incorporate sufficient on-chip resources to perform up to a 2048-point complex FFT without any additional components. The requirements, along with the sheer size of the device (this ASIC contained 300,000 gates, 386,048 bits of RAM, and 78,753 nets), made verification of the ASIC extremely challenging. With smaller, less complex designs, extensive functional simulation can sometimes provide adequate verification. But with larger designs like ours, functional simulation can't guarantee timing performance--a single timing case for our functional vectors took over 220 hours to run on a 300-MHz Ultrasparc II computer. Obviously, using functional test to verify timing for the entire ASIC was simply untenable. Moreover, to support the JTAG interface, the design required two asynchronous clock domains--a system clock and a JTAG clock--that further complicated the verification process. Functional simulation, which consumes so much time, verified less than 25 percent of the timing paths through the chip.

We opted instead for limited functional testing in conjunction with static timing analysis, using the latter to guarantee that all the paths throughout the ASIC met the required clock rate. We reasoned that static timing analysis, used in parallel with formal verification, would enable us to fully verify our devices while keeping design cycle times to a minimum. In fact, static timing analysis runs orders of magnitude faster than functional test; examining just the timing performance of our design took a matter of minutes.

Static timing analysis offers several other benefits. Unlike a fault-grading test that merely toggles individual nodes to see if they function and are observable, it uses up-and-down edges to check all the possible paths in a chip. Furthermore, signal integrity analysis uncovers a whole set of problems that simulation easily overlooks. It automatically determines the worst-case input combination and then analyzes how those conditions affect the timing performance of the designs--crucial information for ever-faster and more complex ASICs.

The new wave
If static timing analysis is so effective at uncovering crucial timing-related problems without consuming large amounts of the design schedule, why didn't we embrace this methodology and make it a part of our standard design flow long ago? Like most new ideas, the initial implementation left much to be desired. First-generation static timing analysis tools were expensive, difficult to master, complicated to use, and hard to understand. As a result, very few designers anywhere could effectively use the approach. We had used first-generation tools before, but found them tough to learn and were reluctant to try again.

Multiple clocking domains--almost a standard in our ASICs--made the original tools especially cumbersome. Forced to run the analysis for only one clock domain at a time, the user had to mask off the others to analyze the first, repeating the process for as many clock domains as the design contained. Performing the analysis on a large design was extremely awkward.

Reluctant to invest in something that few could use, we--like most electronic manufacturers--either ignored it or turned to outside services for static timing analysis. But farming out this type of analysis, not surprisingly, was very costly. Worse yet, it took literally weeks to find out whether an ASIC performed as desired. If it didn't, we then would have to modify and resubmit the design to the service, waiting anxiously for the new results. Obviously, few companies can afford to do this too many times. As a result, most ASIC designers chose to contract out static timing analysis only once or twice in the process, if at all.

Despite the drawbacks, we couldn't afford to ignore static timing verification for long; designs, after all, must work right the first time to gain a reasonable customer base in the extremely competitive telecom marketplace. Thus some telecom ASIC vendors have now made static timing analysis part of their formal sign-off procedure. These vendors recognize the effectiveness of this type of analysis in determining up front if a device will actually perform to specification or not.

As market realities--and some foundries--pressured us to implement static timing analysis, we concluded that we had to adopt this methodology in-house, and the sooner the better. In early 1998 we took a long hard look at our alternatives, then chose the SST Velocity second-generation static timing analyzer from Mentor Graphics Corp. of Wilsonville, Ore. A simple interface allows users to identify problems quickly, creating schematics showing the location of the problem. Incremental masking of problems facilitates further analysis, permitting a user to identify multiple problems and then fix them all at once in the design database instead of exiting the tool, fixing the netlist, and rerunning the static timing analyzer. Consequently, the tool requires fewer static timing runs. Finally, the analyzer is specifically designed to handle multiple clock domains simultaneously.

The approach incorporates proprietary algorithms into a node-based architecture. Together, they power a static timing analysis tool equipped with incremental analysis--the key behind the tool's ability to reduce total verification time required for today's large deep-submicron ASICs. When performing multiple analyses, the tool reanalyzes only those design elements affected by the user's changes rather than addressing the entire design, saving time by streamlining the traditional iterative debugging cycles from hours to seconds.

SST Velocity supports standard netlist, library, and back-annotation formats, relying on files that are already generated within the normal design flow. It also fits into a Design Compiler flow through a direct reading of Synopsys constraint files and .lib support. The tool includes an interactive setup process, which automatically located the source of missing information and notified us.

We were pleasantly surprised by how quickly we were up and running with the new tool. In a matter of hours, we had loaded our designs and were obtaining meaningful results, with reporting features that walked us through the setup of the analysis. The tool's straightforward circuit discovery directed us to the missing constraints that could skew our results. Its reporting windows, linked to schematic and hierarchy views, quickly helped us identify and correct timing issues. Once we moved up the learning curve, we began analyzing the ASIC and found that the tool's asynchronous clocking and incremental analysis capability led directly to productive results.

Asynchronous clocks
Traditional static timing analysis environments couldn't handle the interactions among asynchronous clock domains. The user had to create by hand "false" paths on all those interfaces where the different clock domains overlapped--a difficult and time-consuming task. Moreover, such tools required separate runs for each clock domain, and when we went to tape-out, artificially separating the clocking domains created problems that required a lot of manual workarounds. The new tool, though, simplified the process: We defined the clocks and assigned them to independent domains. The tool identified the JTAG and system clock domains, generated a report about the interfaces between these domains, and then analyzed each piece independently.

Figure 2	Clock tree report
The clock tree report, shown here, lists the individual delays from the clock source to each of the clock destinations, allowing a thorough review of the clock skew between any two destinations. A separate single-line report identifies the maximum skew between any two nodes in the design.

The tool recognized our two different clock domains, reporting all of the crossover points between them. Since we used the JTAG interface to program the mode and options of the ASIC, several hundred nets crossed the boundary between the clock domains. Specifying all of the signals as false paths or constants to allow the individual analysis of each domain would have required a major effort. The tool instead used the crossover information to automatically remove the boundary from the analysis, allowing the static timing analysis to run and saving us considerable time.

While specifying two clock domains, we were also able to define the speed of each domain independently: a 60-MHz clock for the system domain and a 40-MHz clock for the JTAG clock domain. We also associated the inputs and outputs of the complex FFT ASIC with their appropriate clocks and specified the requirements on setup and hold times. The tool's Set Input Arrival Times menu command listed all of the input signals, enabling us to easily define the specifications. The tool handled outputs in a similar fashion.

In addition to defining two independent clock domains, we also split the clock tree to reduce the clock-to-output delays. Our choice meant that the timing analysis was critical in those areas where the normal system clock tree interfaced with the fast system clock. An easy-to-read report not only confirmed that the design was solid, but it also provided the delay from the clock input to each load in the design. A summary highlighting the total clock skew was useful in determining whether the final layout achieved the clock skew requirements.

Analyzing incrementally
Many older-generation tools use a path-based architecture, and thus lose momentum quickly as ASICs grow both in size and complexity. For every verification step, a path-based tool's timing engine traces every circuit path sequentially throughout the design, requiring the tool to visit the nodes multiple times. As a result, path-based static timing tools force analysis times to grow exponentially; they just can't return timing data quickly enough. Its node-based architecture, however, allows SST Velocity to rely on proprietary algorithms to power its timing analysis engine. It visits each node only twice, storing the timing data of the internal circuit nodes. When performing multiple analyses, it reanalyzes only the affected design elements, decreasing the verification cycles from hours to minutes. This approach thus scales linearly in analysis time as chip complexity grows, making a node-based static timing tool architecturally faster than path-based tools and allowing for incremental analysis as well.

Several of the outputs in our design operated in multiple modes; each had a different path from clock to output. Using the incremental analysis, we identified the delay for one mode, created a false path for that mode, and then analyzed the delay for the next mode--all without exiting the tool. In addition, the operational mode allowed us to tristate many of the outputs by different means. The incremental approach allowed us to analyze the delay for each mode of tristate enable without leaving the static timing analyzer.

Because incremental analysis significantly boosts the analysis throughput, we could also use static timing analysis to explore what-if scenarios--a task unthinkable with first-generation tools. What-if analysis allowed us to test alternative design ideas on the fly, helping us to achieve a competitive design advantage.

As any designer knows, it's common to have a few critical paths that limit a chip's potential--our FFT ASIC was no exception. The key lay in identifying and improving these performance-limiting paths, which is where incremental analysis gave our team a real design advantage. The results from the static timing analysis revealed the performance and detailed the critical paths. We then focused our attention on optimizing the long paths; within a few hours we realized a remarkable 35 percent performance boost. After optimizing only half a dozen paths, we raised the ASIC's throughput from a respectable 50 MHz to an optimal 84 MHz.

After improving the performance of the design, we needed only to run the analysis and examine the reports. The SST Velocity environment indicates not only which paths failed the timing specifications, but also the critical paths in the design. The last set of reports identified the setup and hold requirements for each input and the clock-to-output delay for each output--critical specifications for the eventual end users of the ASIC.

Second is better
Because we were adopting a new approach with a critical design, we decided to independently evaluate this second-generation tool's analysis capabilities. So during the release of the ASIC for fabrication, we contracted with an outside source to perform static timing analysis using an established--but first-generation--static timing analyzer against which we could compare our results.

Since the tool had already helped us to resolve all of the various timing issues, the comparison should have been a simple task. But the two clock domains and the inherent design of the JTAG TAP controller created serious problems for the first-generation tool. The contractor spent weeks trying to perform an analysis run, continually interrupting the process, looking at where the tool had hung up, and then creating false paths--an extremely painful process. After much hard work, the service finally provided a result for the system clock domain alone. Then they had to go back through the same process to generate a report of the results for the JTAG clock domain.

We also wanted a report of the input setup and hold requirements and the clock-to-output delays, which required another set of runs that dealt with the I/O instead of the ASIC core. The contractor had to create a failure by increasing the setup and hold times until the tool generated a hard-to-read report. For the outputs, we decided to settle for a subset of reports, since the time and cost of performing the additional runs for each mode would exceed the budget.

Our experience with the design service--both in the duration of the tests and the quality of the results--sealed our decision to purchase the SST Velocity static timing analyzer. The new tool generated equivalent or better results more easily than the old. Furthermore, the seemingly incessant problems the service encountered in getting the first-generation tool to run on a working, already-tested device highlighted other significant differences between the two sets of tools. The tool easily paid for itself by the end of the RACE FFT ASIC design. Moreover, realizing a 35 percent increase in the ASIC's speed through what-if analysis not only helped us to meet our current goals, but also enabled us to expand our offerings. We originally developed the RACE FFT for an in-house system, but are now making the chip available externally. Static timing analysis played a small but crucial role in the success of the project and the growth of our business model.

Dean Bronnenberg has served as ASIC engineering manager at Radix Technologies, Inc. in Mountain View, Calif., for the past three years. He has 19 years of engineering experience, including 16 years in ASIC design and management.

To voice an opinion on this or any Integrated System Design article, please email your message to jeff@isdmag.com.

integrated system design  June 1999