ASIC Technology

Developing an EDA Vendor-Independent ASIC Design System for VHDL

Variations in tools drive the requirements for a reasonable interface to simulation results.

by Bob Holstine and Greg Haynes

During the past decade, many standards have emerged from the EDA world. These standards were developed to help design data flow easily from one tool or environment to another. Because the best point tools in the industry adhere to standards, they can be combined to form a world-class design development flow. Standards have also helped ASIC vendors. ASIC vendors can develop one set of proprietary tools and libraries to support multiple EDA environments adhering to these standards.

UTMC Microelectronic Systems (Colorado Springs, CO) supplies high-reliability VLSI integrated circuits to the aerospace and defense markets. UTMC has developed an EDA vendor-independent ASIC design system using VHDL and SDF. The UTMC VHDL design system supports many EDA vendors without integrating proprietary tools into each environment. Our customers can perform all activities from high-level design to manufacturing using industry standards (see Figure 1).

VHDL design-system considerations HDLs have become the basis for most circuit design systems. Circuit development can be enhanced by tools that create HDLs from graphical representations such as state-machine diagrams, but a standard HDL is critical to provide the framework for integration of all the tools used in the design flow. Verilog is widely used in commercial applications. We chose to support VHDL with our design system because of the military orientation of our customer base.

A major consideration in VHDL, ASIC-design system development is the method used to perform simulation vector analysis for compliance with hardware tester rules. It is important to be able to verify that simulation vectors are usable on a tester. A VHDL design system can be developed independent of any EDA-vendor-proprietary simulation databases. In some situations, this results in a less integrated system than could have been achieved otherwise. Most VHDL simulators write simulation results to proprietary databases used by waveform display tools. Some EDA vendors provide access to these databases, making it possible to use the databases for analysis of simulation results. The disadvantage of this approach is that to use these databases, it is necessary to write specific software for each EDA vendor.

Figure 1. These are the recommended steps a designer uses to create a design in VHDL for manufacturing.

To make VHDL simulation vector analysis EDA-vendor-independent across multiple simulators, we decided not to use any proprietary simulation database formats. Instead, we use the VHDL standard TEXTIO package to write simulation output to a text file in a print-on-change format. Writing this output is accomplished using a VHDL module that we call "a monitor." All of the primary ports of a design are input to the monitor, and their values are printed to a text file whenever the value of any port changes. For bi-directional ports, the monitor writes the input and output components of the signal, as required for test-program generation. This monitor is constructed automatically by the design-system software from the top-level entity of the circuit.

Writing a print-on-change file in text format is generally less efficient than using the native database capabilities of the simulator, but it has the advantage of being completely independent of an EDA vendor. This means a VHDL ASIC-design system can be developed without making modification for a wide range of VHDL simulators.

Another design-system development consideration is the method used to perform logic rule checks on a circuit, which look for inputs that are unconnected, non-three state outputs that are tied together, and other connectivity violations. Output loading and pre-layout delays are also calculated, based on estimated metal interconnect.

Some EDA vendor, VHDL environments provide integrated methods for implementing logic rule checks. However, the VHDL environments that are currently available on the market do not have a standard programming language interface like that available in Verilog. We could not rely on EDA vendor-specific logic rule checks to meet our requirements. We needed the ability to independently implement these checks for circuit descriptions in the VHDL environment. This was the most difficult requirement for us to meet.

We considered several sources for VHDL reader software. Off-the-shelf parsers were available, and some of these were designed to be customized to perform the logic rule checks required by ASIC vendors. We selected a VHDL reader from Duet Technologies Inc. (Santa Clara, CA). Their software was flexible and could be customized to meet our rule checking requirements.

Figure 2. Here is the flow for creating a VHDL design and refining it to a structural VHDL netlist.

We recognized some risks in developing custom software for logic rule checking. VHDL is very complex, and the Duet reader does not handle the semantics of the entire language. The main requirement of the reader is that it has the capability to process a subset of VHDL that includes structural or gate-level design constructs. This is the point in the ASIC development flow when it is possible to use the design netlist to check logic and connectivity rules. However, determining the exact VHDL subset required is not trivial and causes some of the more serious difficulties in developing the design system.

Our definition of a structural netlist is one that describes the structure of the circuit in terms of component instantiation statements and concurrent signal assignments. You can only instantiate technology library components or design sub-modules in your netlist. Most synthesis tools can create a structural VHDL netlist once the design is targeted to gates.

Creating a VHDL design After simulating your high-level VHDL design to ensure that it functions properly, you must create a gate-level implementation in the library of the ASIC vendor. Our VHDL design system includes synthesis libraries for Synopsys Inc.'s (Mountain View, CA) Design Compiler and Mentor Graphics Corp.'s (Wilsonville, OR) AutoLogicII.

You can also manually create or use schematic editing to build a structural netlist representation of your design. Our VHDL design flow does not impose constraints on what EDA tools you use to create your structural VHDL. We only require that you use a VITAL-compliant logic simulator (see Figure 2).

Figure 3. This is how to create a verified netlist from structural VHDL.

Once the design is in a structural VHDL netlist form, it is verified using gate-level VITAL simulation models. The VITAL standard imposes two levels of restrictions on the construction of a library. The level 0 VITAL standard specifies naming conventions that should be followed to ensure that delays can be backannotated by the VHDL simulator. Without backannotation, both pre-layout and post-layout simulations are very inaccurate, since all instances of a given cell will have the same delay (see Figure 3).

The level-1 aspect of the VITAL standard imposes additional restrictions on the structure of the cell models. VITAL specifies procedures for delay determination and for setup, hold, and pulse-width violation checks. It also specifies how functionality should be defined. These restrictions allow EDA vendors to perform some optimizations to improve the gate-level performance of their simulators. Designers are normally not concerned with these VITAL issues; VITAL compliance is primarily a matter for an ASIC vendor to resolve.

We used Synopsys ' Library Compiler initially to create our VITAL models. We made manual modifications to these models to resolve functional problems. To ensure accuracy, we tested the models using VHDL simulators from Synopsys , Cadence, Mentor Graphics, and Viewlogic .

VITAL compliance does not by itself ensure that models are sign-off qualified. Using a proprietary tool, we automated VITAL testing to check that the models met UTMC sign-off requirements. Model tests apply all combinations of 0, 1, and X to cell inputs, exercise all delay paths, and violate timing restrictions to verify timing checks.

We generate pre-layout delay information in standard delay format (SDF) using a proprietary tool that reads a structural VHDL netlist and calculates delay for each path through all gate components of a design. The total delay for each path in the design is the sum of the intrinsic delay through a gate and the estimated wire delay driven by the gate. To accurately simulate a design for timing, you use the SDF file generated by this tool, VITAL libraries, and a structural VHDL netlist. If you find problems during timing simulations, you may need to repeat the synthesis optimization process.

Generating and verifying test vectors After production, the manufacturer must test an ASIC device to determine if it functions correctly. Test programs can be created directly from the results of VHDL logic simulation. The primary functional test consists of a set of fault-graded vectors that are intended to exercise all design functions to reveal manufacturing defects. Other small vector sets test DC drive levels and input leakage of input and bi-directional pins, as well as measure output voltage levels. A quiescent current vector set is required to measure standby or quiescent current of the ASIC design. Optional vector sets include those used for high-speed device testing, propagation delay testing, or average current determination.

To check whether the vector sets will operate on our tester, we developed two tools. The first is the Tester Rule Checker Preparation tool. The second tool is the Tester Rule Checker.

The Tester Rule Checker Preparation tool generates files used in conjunction with a structural VHDL design representation. The tool reads a structural VHDL netlist and creates two VHDL modules: a testbench module and a monitor module. The testbench module instantiates the structural VHDL netlist, test vector stimulus, and the monitor module. The monitor module captures primary input and output pin activity during simulation of vector sets and writes consistently formatted VHDL simulation output. Using the monitor, pin activity is captured during timing simulations.

The Tester Rule Checker analyzes the required vector sets for conformance with our tester rules. This tool reads simulation output created using the monitor module generated by running the Tester Rule Checker Preparation tool. Simulation output for each required vector set is checked to ensure that the vectors meet certain requirements imposed by tester capabilities, such as signal switching times and frequency. The Tester Rule Checker also verifies that input pins are set properly at the times when voltage and current measurements are taken for input drive level and quiescent current tests. All of these requirements are checked by this tool so that corrections can be made before the design is actually tested using the hardware tester (see Figure 4).

Transferring a design for manufacturing After successfully completing the VHDL design flow, the circuit description can be transferred to the ASIC vendor. To process the design, the ASIC vendor needs a structural VHDL netlist, test-vector stimulus files, Logic Rules and Tester Rule Checker's results, and information describing I/O buffer placement. These files are used to verify the design for manufacturing.

Placing and routing a design Placement and routing are performed at UTMC using Silicon Valley Research Inc.'s (San Jose, CA) GARDS software. Many third-party place and route tools, including GARDS, do not read the VHDL format. We recommend the use of a tool such as Synopsys ' Design Compiler to convert your VHDL netlist to an EDIF format that is readable by the place and route tools. EDIF will then used to perform layout activities.

Figure 4. This is the flow we use for generating test vectors.

Creating post-layout timing We create Synopsys set-load commands using actual metal lengths from our place and route system. These commands provide the capacitive load due to interconnect. Synopsys ' Design Compiler reads the design netlist, along with the file of set-load commands to calculate post-layout timing. Design Compiler can calculate delay based on fanout gate-load and actual metal lengths, and then write the delay to an SDF file. You use this SDF file to backannotate your design for timing simulation.

Many place and route systems can insert clock trees with balanced delays into a design to prevent excessive skew in large clock networks. After clock-tree insertion, the design contains nets and gates that were not present prior to layout, causing a problem for backannotation. Delay data, including these clock-tree nets, cannot be applied directly to the original design. We solve this problem by calculating the total delay across the clock tree, and use SDF port delays to apply this delay to the original design.

Final processing Final processing includes layout design-rule checks to ensure that the design does not violate technology size and spacing limits. LVS tests ensure that the logic extracted from the physical layout matches the original design. After these final steps, the design is ready for manufacturing.

What we learned The VHDL design system depends on EDA standard formats. Not all EDA vendors interpret standards identically, so early versions of tools such as SDF readers and writers and VITAL model-checking tools may be incompatible. Fortunately, EDA vendors are motivated to ensure that their tools operate with the products of other companies, so these differences are usually resolved in later releases after standards documents have stabilized.

VITAL models are complex and difficult to create without software tools, but they enable a single VHDL library to be used with many VHDL simulators. We saved time and effort by using the Synopsys Library Compiler to develop our VITAL library. The models created by the Synopsys Library Compiler were satisfactory, but they needed manual modifications to meet our sign-off requirements. To have more control over the format of the models, we will develop software to create future versions of the library.

The design system is just beginning to be used by UTMC customers. We expect that feedback from users will lead to modifications and enhancements to meet our customers' changing requirements.

Bob Holstine is the manager of computer aided design for UTMC Microelectronic Systems Inc. (Colorado Springs, CO).

Greg Haynes is a senior principal CAD engineer at UTMC.

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

integrated system design  June 1997