Designing Top-Down ASICs and FPGAs with Cadence Tools

Purpose This document demonstrates how to design ASICs and FPGAs using a topdown design methodology. The document also illustrates design steps using Cadence tools.

Audience This document is geared toward project managers and engineers who are considering moving from a gate-level design methodology to top-down design methodology using VHDL.

March 1995

Designing Top-Down ASICs and FPGAs with Cadence Tools

Introduction

Introduction
This document provides an overview of ASIC and FPGA design processes in a top-down design methodology using VHDL. Cadence tools are used to illustrate how the design can be achieved.

Designing Top-Down ASICs and FPGAs with Cadence Tools

March 1995

Top-Down Design Methodology

Top-Down Design Methodology

A top-down design methodology lets designers express their ASIC/FPGA design specifications at a higher level of abstraction before implementation. Here are some major benefits:
s

High-level designs let you debug and make design changes easily. With HDLs, one line of code can produce tens or hundreds of gates. The same errors that would cause you to throw away days or weeks of schematic work can instead be caught in the HDL code, before you implement the design. You can change the HDL code more easily and more efficiently at a higher level of abstraction. HDLs make it easier to handle complex ASICs and FPGAs. Designs at a higher level of abstraction are easier to understand. Building hierarchically helps you manage larger and more complex designs. HDL designs support technology-independent implementation. You can make architecture trade-offs during simulation and synthesis in order to choose the best implementations for your designs. You can defer choosing an implementation until later in the design process. A top-down methodology lets you retarget your designs easily, letting you second source your target libraries. If you design at the gate-level, you cannot migrate to new technologies without difficulty.

There are five major iterative steps involved in top-down ASIC/FPGA designs. They are design creation, functional verification, design implementation, gate-level verification, sign-off for ASICs, and physical implementation for FPGAs. This document concentrates on the first four steps.

March 1995

Designing Top-Down ASICs and FPGAs with Cadence Tools

Cadence ASIC Design Solution

Cadence ASIC Design Solution

Cadence supports top-down ASIC and FPGA designs with a suite of tools and associated libraries. This document uses the following tools to illustrate the design process:
s s s s

Concept Design System (block and schematic graphical capture tool) Cadence LSE (Language Sensitive Editor) Leapfrog (VHDL simulator) Synergy (synthesis tool)

All these tools share a common front-end graphical window, the HDL Desktop, shown in Figure 1. The HDL Desktop serves as design data manager and tool launcher. The Desktop design manager organizes VHDL design units on one side and UNIX files on another so that you can operate from both perspectives. All command buttons are object sensitive; when a design unit/file is selected, only legitimate actions can be applied to the unit to prevent user errors.
Figure 1 Library list box Menu bar HDL Desktop startup directory Command buttons Setup files The HDL Desktop Window

Directory list box

HDL Desktop command region

Designing Top-Down ASICs and FPGAs with Cadence Tools

March 1995

A Design Session

A Design Session
Common design tasks for ASIC and FPGA design sessions are design creation, functional verification, design implementation, and gate-level verification. The following sections explain these processes.

Design Creation

This section explains how to

s s s s

Plan your design Partition your design Create block diagram and VHDL blocks for your design Develop a test bench for your design

Planning Your Design

To efficiently generate a design, it is important to take the time up front to plan your design thoroughly. A great deal of the time spent on an ASIC/ FPGA project occurs during the planning stages. Spending this percentage of time up front in the process is beneficial. Problems discovered early in the design process are much less costly to fix than those found near the end of the design cycle. The following methods can help you understand your design requirements before you start thinking about implementation details.
s

Develop a high-level HDL representation. One method of planning a design is to represent the design in HDL at a very high levela behavioral or specification level. You need not worry about detailed functionality, synthesizability, or any of the considerations you think about while designing. Instead, you can concentrate on capturing the functionality and verifying that your design works at an algorithmic and design interconnect level. Without this method, you might not find these types of problems until much later in the design process when you might have to discard your implementation and start anew. If you design at this very high level, concentrate on the interactions between large pieces of functionality. For example, you might have high-level models of the CPU, caches, memory, and I/O subsystems. It is not important to capture the details of each of these subsystems. Instead, capture the interaction between them. Then, you can simulate the design faster because simulating at this high level is much faster than at the gate-level or even the

March 1995

Designing Top-Down ASICs and FPGAs with Cadence Tools

A Design Session

RTL-level. You can use this high-level description as a specification for further refinements.
s

Plan design considerations. At the beginning of the design process, the team, possibly lead by one of the designers, must decide on the following design considerations:
u

The clock frequency required to meet the timing specifications of the design The technology to be used to implement the design The functional and timing verification methodology to be used The data types and associated functions to be used

u u u
s

Decompose the design into hierarchical blocks. One method of planning the design is to use hierarchical block entry to break the functionality down into manageable blocks.

Partitioning Your Design

After you develop an initial top-level specification for the design, you partition the design into sub-blocks. After partitioning the design, you allocate resources to design the sub-blocks. Keep the following hints in mind when you partition your design:
s

Separate the design into portions you want to synthesize and portions you want to implement by hand or by using other tools. If you are synthesizing parts of the design, you must separate out those portions and write them in synthesizable VHDL code during your design refinement. The coding style you use is dependent upon the synthesis tool you are using. For synthesis, all blocks must be synchronous. For some portions of your design, you might be able to implement a smaller or faster design by designing the portion by hand or by using a module generator. For data paths, you might want to use a data path compiler. For macro blocks such as RAM, ROM, and multipliers, you might want to design the blocks by hand or use a module generator. Synthesize the less critical portions of your design where you will benefit from the synthesis tools ability to generate large amounts of logic efficiently.

Keep blocks to a reasonable size. For blocks intended for synthesis, keep to a reasonable gate count. A reasonable gate count for synthesis blocks varies according to the complexity of the design and the target library. If your design is simple and your target library is small, your blocks can be larger and still synthesize in a reasonable amount of time. If, on the other hand, your

Designing Top-Down ASICs and FPGAs with Cadence Tools

March 1995

A Design Session

target library and your design are complex, keep the blocks smaller for a reasonable synthesis run time. Limiting your blocks to a reasonable size has other benefits besides synthesis run time. Limiting your block sizes helps you to debug your design. You can create test benches for separate blocks and isolate problems effectively. During gate-level debugging, you can also match portions of your RTL to the post-synthesis gate-level description more easily if you create separate blocks and synthesize them separately. Finally, smaller blocks are easier to understand and maintain.
s

Keep critical paths within a hierarchical boundary for synthesis. When you partition the design into sub-blocks, you will focus on meeting the timing requirements of the critical paths. If you are synthesizing, try to keep the critical paths within a hierarchical boundary. If the critical paths span a number of blocks, you must manually determine the boundary constraints to set during synthesis. If the critical paths are within a single block, the synthesis tool can help you meet your constraints without extra work on your part. If you try to isolate the critical path in a single block and the block is unmanageably large, you can break the block up into sub-blocks for simulation. Then, during synthesis, you can flatten those blocks so that the critical path is within one hierarchical boundary for synthesis.

Perform timing and area budgeting. Partitioning is an iterative process. The designers on a project obtain the timing and area specifications for their functional blocks and let the project leader know if they can meet the requirements. If not, the project leader adjusts the specifications on other blocks to meet the overall timing and area specifications. The timing and area negotiations between the project leader and the designers continue until the team agrees on a feasible design specification.

Parameterize blocks so you can use them in other designs. For some of the blocks, it might be possible to reuse HDL blocks from past design projects. By parameterizing blocks whenever possible using VHDL generics for data path sizes, delay timing values, and looping iterations, you can build yourself a reuse library. By reusing blocks, you allow yourself more development time for subsequent projects.

Creating Design in Block Diagrams and VHDL codes

After careful planning, you can start designing the ASIC or FPGA with design tools. First, you launch the HDL Desktop to create your design working library. All design units created will be complied into the library.

March 1995

Designing Top-Down ASICs and FPGAs with Cadence Tools

A Design Session

The Desktop will help you manage all the design units and associated design files. By naming convention, the Desktop can invoke appropriate editor tool for high level capture. Therefore, you can configure the Desktop to bring up Concept Design System for block diagram capture or LSE for VHDL coding. When the Desktop brings up Concept, you can use many high-level commands to aid block diagram capture, such as creating blocks and interconnecting them with wires or buses. You can also name each part, pin and wire to complete the block diagram. Figure 2 shows how a block diagram looks for a simple arithmetic unit.
Figure 2 Block Diagram for an Arithmetic Unit

After you complete the block diagram, you save the drawings in the system. In the saving process, Concept calls HDL Direct (a VHDL netlister) to check for rule violations. If everything works, HDL Direct launches Leapfrogs code analyzer to compile the netlist produced. After analysis, the new design units display in the Desktops library list box. From the Desktop, you can create another unit to capture its block diagram. You can also launch LSE to type in VHDL code to describe the units logic. LSE provides VHDL templates to help you write VHDL in correct syntax. You can save your VHDL description and analyze the code within

Designing Top-Down ASICs and FPGAs with Cadence Tools

March 1995

A Design Session

LSE. LSE displays illegal code in red. You can also ask for error explanations. If the description is correct, the new design unit displays in the Desktops library list box as well. If you plan to synthesize this module, you should run synthesizability checker from the Desktop to ensure that the code can be synthesized by Synergy. You should perform a synthesizability check before spending time running hours of simulation. You can repeat this block creation process until you define all the blocks and their leaf nodes. At this point, you can use test benches to run functional simulations.

Developing Test Benches

You use test benches to instantiate your design so that you can verify it by applying stimuli patterns to it. The HDL Desktop includes a test bench utility which generates a test bench entity and architecture so that you can instantiate the design to be tested. You must then edit the test bench to add your own test stimuli. The following strategies will help you to develop effective test benches for your designs:
s

Keep the test bench separate from the design. If you create a separate module for your test bench, you can use the test bench for RTL and gate-level verification. For gate-level verification, change the name of the architecture in the test bench or in the configuration of the test bench to the new gate-level version of the architecture or use default bindings to automatically bind to the most recently updated architecture.

Create self-testing test benches whenever possible. A self-testing test bench iterates through possible inputs and tests the results, printing a violation if the results are not correct. This method helps you to perform regression tests easily. Additionally, you can use many of the tests later on the actual hardware.

Compare the gate-level simulation results with the RTL simulation results. Use the same test bench to verify that the two versions are functionally equivalent. Use the IEEE std_logic data types in your models and your test benches rather than using integer types. In this way, your synthesized gate-level design will not require conversion functions to map pre- and post-synthesis ports.

Perform unit testing and solution testing of designs. The safest way to verify the overall design is for individual designers to create test benches and perform unit testing on their blocks before submitting the blocks for integration. The project leader creates a test

March 1995

Designing Top-Down ASICs and FPGAs with Cadence Tools

A Design Session

bench for the overall design. After the designers submit their blocks, the project leader uses the overall design test bench to perform solution testing of the integration. It is important to coordinate your test plans across the entire design project so that you target your simulation effort appropriately. Solution testing is not the same as rerunning all of the unit tests. Solution testing should test the interactions of the components and the interesting input cases that apply to the entire system. For example, what happens to the system when an interrupt occurs? What happens when the multiplier design overflows?

Functional Verification

After you have completed and compiled all the design units, you can run elaboration on the test bench to obtain a simulation snapshot for Leapfrog. Leapfrogs elaborator warns you of any unbound components. Running elaboration with the update option brings the complete design up-to-date by compiling all necessary dependent files. You can then start Leapfrog from the Desktop with a selected snapshot. Figure 3 shows the Leapfrog VHDL simulator window.
Figure 3 The Leapfrog VHDL Simulator Window

command buttons source area

Leapfrog command

10

Designing Top-Down ASICs and FPGAs with Cadence Tools

March 1995

A Design Session

The primary objective of running simulation is to obtain stimulus-response data. This data can be represented in both graphical and text forms. To ease iterative debugging, it is sometimes easier to view the data in a graphical form; in regression testing, it is easier to store the data in a text format. If your design is complex, you can revisit the design hierarchy by invoking DesignView from Leapfrog. DesignView graphically displays the design hierarchy information, including process blocks. This allows you to easily traverse the design hierarchy; when you double click on any block, its source code displays in Leapfrogs debug window. You can also use Leapfrogs Navigator to traverse the design. The next major step is to select a group of signals for simulation tracing. Since tracing signals slows down simulation run time, you should be very selective. When you select a design module, all signals from that module are displayed in the Navigator. You can select signals from the Navigator and add them to the tracing list. You can also select the signals from the source window. As you add signals for tracing, these signals appear in the cWaves window. cWaves is the simulation results graphical display tool. After you have selected all the signals, you can save the simulation commands into a replay file so that you do not have to select these signals every time you run Leapfrog. You may set the simulator to break on reset signal changes and start running the simulation. Leapfrog stops simulation when it encounters a reset signal change. You can observe the signal tracing from cWaves and make sure all the reset states are correct. You can then continue to simulate until completion. Leapfrog has a very rich set of commands that let you control the simulation session in many different ways. You can start and stop at any time; you can set a break point at any line, on signal changes or when signals are equal to certain values; you can step through the simulation, monitoring multiple processes via process views, monitoring delta cycle via cycle views, and forcing signals to different values. At any time, you can update cWaves to display the latest simulation results, as shown in Figure 4.

March 1995

Designing Top-Down ASICs and FPGAs with Cadence Tools

11

A Design Session

Figure 4

The cWaves Window

When you find simulation errors, you can go back to the source and edit related design units. You can reload the simulation snapshot using the update command. Leapfrog compiles all design dependencies and reelaborates the design automatically. This greatly reduces the cycle time in your edit-debug loop. If your are not using a self-checking test bench, you may want to keep your current simulation results database so that you can compare future simulations against this database. In the Desktop, you can promote this simulation database to golden status.

Design Implementation

There are many methods you can use to implement your design, depending on the characteristics of the sub-blocks under construction. You can use data path compilers for data path components, mega cells for standard components, schematics for timing critical blocks and synthesis tools for random logic. This section focuses on how to use a synthesis tool to implement the design.

12

Designing Top-Down ASICs and FPGAs with Cadence Tools

March 1995

A Design Session

Reality of Synthesis

Synthesis is not a push-button technology and cannot replace an expert designer. Designs generated by a synthesis tool may not always be more efficient than hand synthesized designs, but a synthesis tool will complete a design much faster. A poorly written VHDL design will result in an inefficient gate implementation. It is important to master the modeling style supported by your synthesis tool. Sometimes, a simple change in the VHDL code may result in a completely different circuit implementation after synthesis. Synthesis is best for
s s s

edge-triggered random logic with a simple clocking scheme technology re-targeting logic/timing optimization

Synthesis tools like Synergy are composed of two parts. The front end of Synergy is called Synthesizer and the back end is Optimizer. Synthesizer takes the VHDL descriptions and translate them into a set of boolean equations, sequential elements, and high level complex components. Synthesizer handles complex operator mapping and FSM constructions. It also determines efficient allocations for expensive resources. Optimizer takes the database generated by Synthesizer and performs logic optimization based on timing and area goals through partition technology, independent optimization, canonical graph optimization, technology mapping to ASIC or FPGA library components, and electrical rule correction. After optimizing the design, it finally generates synthesis reports.

Running Synergy

This section does not illustrate the complete synthesis methodology supported by Synergy. Instead, this section shows how to synthesize one sub-block using Synergy. To do so, you select an architecture unit from the Desktop and launch Synergy. The Synergy window is shown in Figure 5. Since Synergy shares code analysis with Leapfrog, you dont need to analyze the design again. This shared analysis greatly enhances design productivity.

March 1995

Designing Top-Down ASICs and FPGAs with Cadence Tools

13

A Design Session

Figure 5

The Synergy Window

Select Synergy menu commands here.

Command buttons for fast access to Synergy commands

Synergy command region

Enter Synergy text commands here.

During a synthesis session, you might want to bound the design space as a first synthesis task. You bound the design space by running Synergy with minimal constraints, allowing it to optimize cost in one run and timing in the next. Next, you might want to make a trade-off curve run. A trade-off curve run generates a range of potential circuits, displaying the possible results as a curve on a graph. These three types of runs should give you enough information to determine whether the design will meet its timing and area requirements or whether it needs remodeling. One important concept to note is that refining constraints has little impact on timing and area results. To considerably alter timing and area results, you must remodel the design. This is why it is beneficial to use timing, cost, and trade-off curve runs to determine up front whether the design will meet its requirements. If, after you bound the design space, you determine that the design is close to its requirements, you can fine tune the design constraints to meet the design requirements. Before starting any synthesis job, you must first set the target library. It is either ASIC or FPGA Synergy library supported by your vendor. If there are finite state machines in the sub-block to be synthesized, you must also

14

Designing Top-Down ASICs and FPGAs with Cadence Tools

March 1995

A Design Session

set the FSM constraints. Next, you set the designs boundary conditions, including maximum fanout, maximum load, arrival times at inputs, and required time at outputs. Finally, you must set clock constraints so that the synthesis tool can meet timing requirements. You can launch Leapfrogs DesignView and Navigator from Synergy to set constraints at different levels in the design hierarchy. After setting all the constraints, you can start the synthesis job to run in either area mode or timing mode. In area mode, Synergy tries to reduce the area of entire design with less emphasis on making critical paths. In timing mode, Synergy tries to reduce the delays on the most critical paths and for the rest of the design, Synergy tries to reduce the area. After synthesis, Synergy produces both VHDL and Verilog netlists, along with various reports to help you understand the synthesis results. The report lists ERC violations, constraint violations, timing check violations, longest and shortest critical paths of the design, the total cell count, the number of pins per net, the cell porosity distribution for indications of routability, a summary of clock statistics for state devices, and the status of max load, max fanout, and max transition for each net of the design. You can also view the schematics generated. You should carefully review the synthesis results; if there are violations, you must fine tune the appropriate constraints and re-run the synthesis job. If the results are satisfactory, you can proceed to gate-level verification to ensure that the implementation conforms to the functional specifications.

Gate-Level Verification

Running gate-level verification requires a gate-level simulation library. Although Leapfrog supports VITAL acceleration, most ASIC and FPGA libraries today are only available in Verilog. To solve the problem of a lack of VHDL libraries, Leapfrog provides a Verilog model import capability. Verilog model import supports cosimulation of both languages. This capability is different from a backplane technology; it is accomplished by putting Leapfrog and Verilog-XL engines together through a proprietary interlocking kernel. These two engines only communicate when there are signals passing across VHDL and Verilog processes. To ensure simulation efficiency, it is recommended to bring all Verilog blocks together instead of having Verilog blocks scattered within VHDL blocks. Synergy produces both VHDL and Verilog netlists. You are free to simulate in either language. To facilitate the process of using Verilog libraries, Synergy also generates VHDL shell for each synthesized unit. The VHDL shell instantiates the Verilog netlist so that Leapfrog can run a cosimulation.

March 1995

Designing Top-Down ASICs and FPGAs with Cadence Tools

15

A Design Session

After synthesis, you can invoke the Desktops Import form. Import lets you select whether you are using a VHDL or Verilog library. Then it brings in the right files and compiles all the necessary files for gate-level simulation. If you write the test bench properly, you should be able to reuse the same test bench and replace the functional model with the gate-level netlist. If you are using a VHDL library, both test bench and netlist are in VHDL and you simulate the entire design in VHDL. If you are using a Verilog library, the test bench and other functional blocks are in VHDL and the gate-level netlist is in Verilog; therefore, you will be running a cosimulation. To perform a gate-level simulation, you elaborate the new design configuration and launch Leapfrog with the new snapshot. Once Leapfrog is running, you can source the script that you saved during functional simulation. Sourcing the script retrieves the same set of signals from last functional simulation for waveform tracing. You can simply run the simulation until it finishes. This simulation produces another waveform database. If your test bench is not self-checking, you can compare this database against the golden database from your functional simulation. This waveform compare utility is available from the Desktop. You can view the resulting database from cWaves to find out if there are any discrepancies. You may have to resynthesize by tightening constraints. You may even have to return to the source and modify the functional models if the result is too far away from your target. After you are satisfied with the gate-level implementation, you can pass the netlist to your ASIC vendor for signoff. For FPGA designs, you can proceed to use PIC Designer to map the netlist into physical components. In either case, you might get a different netlist with SDF (standard delay format) files. Finally, you can re-run gate-level simulation with SDF files to catch any timing glitches.

16

Designing Top-Down ASICs and FPGAs with Cadence Tools

March 1995

Summary

Summary
This document discussed the major benefits of using a top-down design methodology to design ASICs and FPGAs. The document also walked through a generic flow detailing the steps and basic strategies to complete the design using Cadence tools. Transitioning from gate-level design to top-down design may seem overwhelming at first, but adequate training and the right partner can help you make the step; the result will be rewarding. Cadence can provide you with the technology and expertise to help you make such a transition.

March 1995

Designing Top-Down ASICs and FPGAs with Cadence Tools

17