ASIC Technology

ASIC Library Performance

A method for evaluating ASIC standard cell libraries for deep submicron designs.

by Jamil Kawa and Pat Hom

A decade ago, the majority of companies in the IC industry developed their own libraries internally. Such an effort was logical since most IC houses also owned their own fabrication facilities, and those internal libraries were developed around the IC house's specific processes and design rules. Today, there is a large and increasing number of fabless semiconductor companies that are not attached to a specific fabrication facility. In many cases, the fabless semiconductor companies prefer to purchase the libraries externally in an effort to concentrate on their core business and to save money in the process.

The past few years have seen the emergence of several library companies that offer a wide variety of cost-effective library solutions. The short life cycle of any particular technology and the heavy penalty you pay for being late to market puts a lot of pressure on schedules. Thus, buying a library from a vendor whose only business is building libraries is a sound alternative to internally developing such a library. Of course, the library vendor must be able to provide the library early in the process technology life cycle.

However, the availability of off-the-shelf libraries brought with it several risks, starting with performance and ending with lack of quality control over such acquired libraries. Thus, a need emerged for a thorough and methodical evaluation of various available libraries. A cell library must be evaluated on several fronts: efficiency, robustness, portability, usability, quality, timeliness, custom support, and cost (see Figure 1).

Efficiency A library is efficient if the resulting routed, synthesized designs are fast, small, and low-power. Since speed, area, and power are interrelated, we are looking for a library with appropriate speed, area, and power tradeoffs. One quick measure of a speed-area balance is to select ten to 20 frequently used elements. For each element, compute its delay for a specific capacitance load, and multiply the delay by the element's area. Finally, sum up all of the elements' delay-area values. By comparing this sum across libraries of a particular technology, the one with the smallest sum is the one with the best balance of speed-area. However, we must warn that this measure is only a first order gauge because the library must also be router-friendly.

A library that has a very tightly compacted set of elements that makes it look very area efficient on a cell by cell comparison is of little use if the routed designs are larger. The cell library must be designed with different routers in mind. Of course, a library cannot be optimal for all available routers. It is important, however, that routability does not suffer dramatically when you move from one router to another. The library's porosity and cell height strongly affect the routability of a library. A library has low porosity if the cells' layouts block over-the-cell routing. Low porosity leads to lowered routing utilization because routers need to add a high number of between-cell feed-throughs. The cell height must be carefully chosen. If the cell height is too short, the router will run out of routing area over the cells; thus, it needs to add routing channels between rows. At the same time, if the cell height is too tall, then there will be wasted routing resources over the cells. In this case, the cell area determines the minimum chip area.

At geometries of greater than 0.5 µm, there were several design practices that sometimes enhanced routability at the expense of performance: poor strapping (strapping is a method of reducing the source/drain resistance of individual devices by using multiple contacts to a metal rail) and the extensive use of long poly routes. Many source and drain areas had only one contact. The poor strapping resulted in high contact resistance that caused a slight deterioration of performance. Long poly routes could cause significant RC delays in signal propagation. However, with fully salicided processes, the issue of having long poly routes has become less significant.

The next portion of the efficiency test is "synthesis suitability." Some library vendors have separate libraries geared specifically towards high performance or high density. The idea is that one must be willing to pay an area penalty for high performance. However, as we start looking at 0.35-µm technology and below, such a choice rapidly loses significance and viability. As the gate count increases due to reductions in IC feature size, synthesis enters the picture. Synthesized designs tend to buffer nets for the purpose of design robustness. Typically, this makes a design synthesized with a high-density library too slow, and a design synthesized with a high performance library too big. Thus, a unified library suitable for synthesis as well as non-synthesis is needed. The library needs to balance the drive of various library elements as a function of the typical parasitic and dynamic mix of a typical net load. A library that addresses area, or speed, or synthesizability as a single factor is doomed to fail. All three must be balanced. A factor tightly associated with synthesizability is drive granularity. A synthesis engine has no choice but to go to the next drive level of an element once the fanout of that element exceeds a certain number. Too coarse a granularity in a library can have a domino effect in typical net load and in total area.

Figure 1. Early identification and elimination of unsuitable library vendors is very important because verifying a library's robustness, efficiency, and usability requires a significant resource commitment on your part.

For applications that are battery operated, power consumption becomes a highly important issue. Library elements must have no static power consumption (for a CMOS library). Also, crow-bar current (the current that is used for the initial surge in charging internal and external capacitances) during I/O switching must be minimized for both lower noise and lower power consumption.

Robustness A cell library that yields a good area and performance balance is of no use if it is not reliable. Issues related to ESD tolerance (for I/O cells), metal migration (current density in VDD and VSS rails for a standard cell row, for example), and noise sensitivity have to be analyzed carefully. A vendor must supply clear guidelines indicating the maximum length of a row of cells as a function of switching frequency allowed without violating metal migration considerations. Also, noise (due to L x di/dt) and I x R drop in a power bus have a significatnt impact on speed. Power rails and proper strapping are important in determining the robustness of a library.

Figure 2. In the tool flow above, each CAE tool has a different delay calculator. In the tool flow below, a central delay calculator, which sources all CAE tools, will save you from debugging delay calculator differences.

Another example of robust design is requiring balanced rise and fall times. One might argue that across a path, imbalance between rise and fall times of individual cells will be a wash. That is not always true, especially with heavily loaded nets. Also, the imbalance in rise and fall times in such cells could be exacerbated if the core is used at a lower voltage than originally targeted, or if the threshold voltage for P-channel and N-channel devices varies significantly from one foundry to another.

Portability Another aspect of increasing importance in evaluating libraries is a library's adaptability of use with multiple foundries. This adaptability can range from the library being built around a common set of rules that accommodates the design rules of a handful of silicon vendors, to rules that are not as accommodating but result in cells that are easy to modify to other design rules using industry-available retargeting tools.

Is a foundry-specific library better than one that is multi-foundry tolerant? A foundry-specific library will always result in a smaller die. However, let us not forget the time, cost, and risk involved in retargeting a library. When all these factors are weighed, it is easy to see that the inefficiencies associated with a multi-foundry library are a small price to pay compared to the overall cost associated with retargeting libraries. However, your time-to-market requirements may drive you to select a foundry-specific library because an on-time product in a foundry-specific library is better than a late product in a multi-foundry library.

Usability A great physical library is useless without design kits. Unless you will be using the library supplier's complete suite of CAE tools, you'll need design kits for third-party tools. Depending on your design methodology, you'll need the following types of design kits: schematic entry, synthesis, simulation, static timing verification, and ATPG. Your specific tool set determines the exact design kits needed. You may need multiple simulation design kits: schematic-based simulation models, Verilog or VHDL (VITAL or non-VITAL) models, and hardware accelerator models. The library supplier must be able to generate design kits using the same version of CAE tools that your company is running. This requirement is very important for CAE tools that use compiled binary files.

If some of your tools are not supported, is the library supplier willing to work with the tool vendors to create the models? If yes, what is the lead time, and what is the development cost? If no, do you have the resources and ability to develop the models internally?

If multiple simulators and static timing analysis are used, then a common delay calculator that interfaces with all of your CAE tools is ideal (see Figure 2). Multiple delay calculators will introduce potential timing variations. A delay calculator capable of writing SDF will cover most tools if it can read all of the different tools' databases and respect the different tools' naming conventions. Note that some tools use a proprietary format. The delay calculator must support custom standard cells, custom blocks (RAMs), pre-routed blocks, and "black boxes" (analog blocks). The same delay calculator should be capable of generating pre-route and post-route delays. Since pre-route delays are based on a wireload model, confirm how the wireload model was generated: which router, how many designs, etc. The accuracy of the wireload model will influence early synthesis results; thus, it will affect architectural decisions. Custom wireload models must also be supported.

The delay calculator should also support any combination (within the characterization region) of voltage and temperature conditions. Fixed operating conditions--for example, worst case is 3.0-V with 70 degrees Celsius junction--is unrealistic if the design will be operating in a laptop environment (where worst case ambient is 70 degrees Celsius).

All the design kits must also be compatible with each other. This requirement sounds strange but is necessary to ensure that design data can be transferred between the different CAE tools. For example, if the design flow requires that schematics be transferred from Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys to Viewlogic , then the Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys symbols must match the Viewlogic symbols.

Quality One issue that we cannot put enough emphasis on is quality. Quality is a criteria that every vendor claims to have and every end-user expects and takes for granted; unfortunately, it is becoming a misused word. When we talk about quality in a library, we start at the very basic correctness of every cell, proper characterization, correct models, correct documentation, correct and detailed derating curves, cross-correlation between third-party models; and last but not least, the level of response of the library vendor when an error is detected.

There is an abundance of tools created for the purpose of quality control--for checking and re-checking the correctness of library development. However, such tools are no substitute for human diligence. After all, even QA tools are driven and monitored by engineers who have the final say over the quality issue. Equally important is the developer's attitude, readiness, and preparedness to deal with a customer's complaint.

Timeliness and customization The library must be available early in the technology life cycle. Custom standard cells are often required for timing, area, or legacy-design-compatibility. The library vendor must be flexible and ready to support special needs (custom cells). The response time is very important since a library is complete only when all its support functions--including models, design kits, and physicals--are available. A library vendor who quotes a turn-around time of one month for a custom cell is essentially saying that the library will be available a month from now.

Also, the fact that custom cells are not part of the main flow of a library vendor's offering is not an excuse for lower quality. The quality of the custom cells must be equal to the quality of every element of the original library.

Cost The cost of a library (and that of developing custom cells) is a delicate issue. The cost of library development (both development tools and time) is high. However, there is a reservation price for every customer that determines whether to buy a library, develop it internally, or think of other solutions within the framework of available internal libraries and tools (shrinking, re-mapping, etc.). After all, buying an off-the-shelf library always includes a compromise between what a customer ideally likes to see in a library and what is available. There must be a clear economic advantage for buying a library over developing one.

There are several issues to consider when choosing a library. Efficiency, robustness, portability, usability, quality, timeliness, custom support, and cost all must be accounted for.

Jamil Kawa is the manager of circuit design at Chips and Technologies (San Jose, CA).

Pat Hom is the manager of CAE/design methodology at Chips and Technologies (San Jose, CA).

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@isdmag.com.

integrated system design  November 1996