Types of RTL Design
Back to top

There are four categories of RTL designs used for ASIC development.

1. RTL Conversion

   A specific type of RTL handoff is an RTL conversion. The red arrows in Figure 2 signify a typical FPGA conversion to an ASIC (using a retargeting methodology), and the yellow arrows show the flow for an RTL conversion (using a remapping methodology). This is when RTL synthesis is used to design the ASIC instead of converting the FPGA netlist data to an ASIC.

   

   Figure 2 - RTL Conversion

   If the FPGA was synthesized using Synplify Pro from Synplicity, then Synplify ASIC, also from Synplicity, should be used for ASIC synthesis. Alternatively, if FPGA Express from Synopsys was used, then Design Compiler from Synopsys should be used for ASIC synthesis. Synthesis tools from other vendors can be used in a similar manner. In this way the same RTL code compiler is used for both FPGA and ASIC synthesis, but an ASIC library is targeted instead of an FPGA library. This reduces the potential problem of various synthesizers interpreting the RTL code differently and the necessity of rewriting compiler directives.

   Using an RTL handoff flow to retarget usually results in higher design performance because the synthesis tools can optimize the design based on the components and timing characteristics of the ASIC library, and can optimize the architecture of high-level functions such as multipliers based on the ASIC library. Because of these advantages, RTL handoff is usually necessary for complex designs with higher clock frequencies and higher gate counts.

   Using RTL code and retargeting is also preferred when converting two or more FPGAs into a single ASIC because the signals between FPGAs are optimized as part of the flow. AMI's new XpressArray technology is designed to take advantage of RTL code that has been written with FPGA architecture in mind.

2. Multiple FPGAs to a Single ASIC

   For cost reduction or to save board space, it is often desirable to convert several FPGAs into a single ASIC. These FPGAs may be represented in a mixture of RTL and structural code, and be from different vendors.

3. Prime ASIC

   A prime ASIC is written in RTL code that is targeted directly towards an ASIC. The architecture may vary somewhat from an FPGA because of the underlying hardware technology. An example is the heavy use of pipelining to meet FPGA timing requirements that may not be necessary in a standard cell ASIC.

4. Structural RTL

   Many companies have legacy designs that were originally developed with schematic-capture software, and are now available in a structural-netlist format referencing a particular ASIC vendor's library. Modifying the design to a structural RTL format enables it to become technology-independent and more easily implemented as part of a larger ASIC. This is accomplished by replacing the technology-dependent library with a new library defined in RTL code. The technology dependent definitions of the cells are removed and replaced with technology-independent synthesizable definitions.

Handoff vs. Signoff
Back to top

RTL handoff is not RTL signoff. The word signoff implies the existence of a well-defined set of formal procedures and tools with the guarantee to turn a design into silicon without any significant interaction between the factory and the customer. This kind of interaction between the factory and customer exists for mature technologies like netlist signoff, but it is not there yet for RTL handoff. RTL designs require the factory and the system designer to work closely together during the synthesis phase of the design.

Key RTL Handoff Steps
Back to top

1. RTL Code Checking

   The quality of the RTL code is the single most important element to a successful RTL to ASIC design. An RTL code checker will ensure that code is ready to be synthesized into either an ASIC or an FPGA, and will help avoid many pitfalls. For example, AMI Semiconductor uses a widely available RTL checker, but has augmented the standard rule set with custom rules. Together these rule sets verify that the RTL code is compatible with the tools used throughout the ASIC design process. These rule sets include checks for general code quality, synthesis, RTL-to-gates equivalence checking, and design for testability. Over 500 rules are currently being used.

2. Synthesis

   The process of converting RTL code into a gate-level netlist in a particular technology is known as synthesis. Traditionally, synthesis has been done without regard to the physical placement of the cells on silicon; this works well when gate counts and clock speeds are not too high.

   In designs with large gate counts and high clock speeds, physical synthesis is useful for meeting chip-level timing requirements. Physical synthesis is of two types—the first is gates to placed-gates synthesis, and the second is RTL to placed-gates synthesis. During gates to placed-gates synthesis, a gate-level design is re-optimized as the gates are placed in a previously floor-planned layout. In RTL to placed-gates synthesis gates are physically placed and synthesized together.

   Before synthesis can take place, a synthesis script must be developed. This script sets constraints (timing, power, size, etc.), defines technologies, and breaks down a large design into smaller, manageable blocks. Span times will be shortened if any already developed synthesis scripts are made available to the ASIC supplier to use as a starting point.

   Of course, functional equivalence between the RTL code and the synthesized netlist is a requirement. This is ensured by verifying that the RTL is compatible with synthesis using an RTL checker and by using RTL to gates logical equivalence checking.

3. Verifying Netlist Functionality

   Simulation and formal verification represent two ways of proving the logical equivalence of the RTL code to the synthesized netlist. Simulation can work well if the test bench is comprehensive. Formal verification or logical equivalence checking (LEC) is more comprehensive. However, it can be challenging to complete because synthesis tools can prune registers and nets, modify hierarchy, and encode state machines in unexpected ways. If a test bench is available, using both is often the best solution.

   If several FPGAs are being consolidated onto a single ASIC, a test bench that verifies the connections between designs is required. Because of these challenges, this is typically the most time-consuming task in an RTL handoff.

FPGA Fabric and Design-for-Test (DFT) Insertion
Back to top

If the ASIC is replacing an FPGA, then certain functionality inherent to the FPGA may need to be replicated on the ASIC. If this is the case, then it is best not to rely on these functions on the FPGA. Of course, it saves time and die cost if this functionality is not required on the ASIC.

The FPGA fabric and DFT functions may include configuration logic. This logic is added to the ASIC if emulation of the configuration function is required because the ASIC is to be "daisy chained" with an FPGA. It will enable the ASIC to read the programming bitstream and pass it on to the downstream FPGA at the right moment. The ASIC can also emulate power-on reset and power-on tri-state as part of this function.

Rather than relying on the FPGA power-on initialisation, it is safer to code-reset all registers into the RTL code. For this reason, a power-on initialization of the registers and memory function is often provided.

A further function is the instantiation of either ASIC/IO cells or functional placeholders at the top level of the RTL code. This facilitates the addition of JTAG functions and checking of the design. Other functions such as DLLs, PLLs that are included in the original FPGA, will need to be replaced with ASIC functional and electrical equivalents. Typical DFT tools often included in the design are scan insertion, Built-In Self-Test (BIST), and various structures for the testing of I/O pads.

Home    Product of the Week    App Notes    Tech Notes    Newsletters