The Syndicated

Successfully Verifying Complex ASICs In FPGA-based Prototypes

Editor's note: Ashok Kulkarni, Sr. Technical Marketing Manager for Verification Products, is guest writing this article for Ken McElvain.

To achieve a high level of confidence in ASIC/ASSP verification using FPGA-based prototyping, a number of criteria have to be met. From a software perspective, the tools must:

be capable of understanding ASIC design styles
make appropriate RTL code changes suitable for FPGA implementation
be able to partition and map the design over multiple FPGAs
offer easy to use, yet powerful, debug capabilities in a familiar design environment

Likewise the hardware prototyping board must be designed to offer flexibility, functionality, and performance. Specifically, prototyping boards must:

ensure high signal integrity, low skew
run designs with high performance
be easy to expand logic capacity and interface to daughter cards with little or no modifications to the prototype board
support multiple on-board programmable clock sources

When software and hardware tools are procured from different vendors, one of the biggest challenges is to ensure that these tools work together smoothly. This requires that the tools be tightly integrated into the ASIC prototyping flow without causing any inter-operability issues.

ASIC Design Styles And FPGA Implementation

An ASIC prototyping flow commences from RTL code and has two major steps.

Mapping the design to FPGA prototype board.
Debugging the design, fixing the error, and verifying the fix.

Mapping the design to the FPGA-based prototype consists of, (i) Converting (ASIC) RTL to FPGA gates for a given prototype board using a synthesis tool, (ii) Partitioning the design into smaller design blocks suitable for mapping over multiple FPGAs. Often the ASIC RTL consists of constructs and design styles, such as usage of DesignWare^® library components (provided by Synopsys), gated clocks, and memory instantiations from an ASIC vendor library which are unsuitable for FPGA implementation. The tools must be capable of automatically extracting these implementations from the ASIC RTL code and making appropriate changes suitable for the FPGA implementation without modifying the design functionality. For designs that are too large to fit into a single FPGA, the tool must be capable of partitioning the design into multiple FPGAs either automatically or optionally, through user guidance. Often when the design is partitioned over multiple FPGAs, the number of signals between FPGAs exceeds the number of pins available on the FPGAs thus requiring pin-multiplexing. Once again the tools must be capable of implementing pin-multiplexing logic on the required set of signals automatically or optionally, through user intervention.

Debug Must Be Easy and Intuitive

The next step after the design has been mapped to the prototyping board is debugging. Debugging a live running FPGA is always a challenging task. It stems from the fact that visibility inside an FPGA is poor because it is hard to co-relate the design state, which is a gate level representation of the design, to the RTL representation, which is familiar to the designer. The tools must have the ability to co-relate the design errors discovered in the FPGA with the RTL source code by analyzing the data captured out of a live running FPGA. The tools must also allow the designer to debug and to fix the error in a familiar design environment. In other words, the debug process must be quick, easy, and intuitive so that the user can run a large number of test-suites, aiding in comprehensive test coverage.

Prototype Boards Must Be Flexible With Multiple Functionality

Likewise, the prototyping board must be designed to offer flexibility, functionality, and performance. Design changes can occur at any time during the design cycle, for variety of reasons, including changing market requirements or to overcome a design flaw. These changes often imply adding more functionality to the design or adding/modifying the bus interfaces. This requires that the prototype boards must be easy to expand the logic or memory capacity and accommodate internal or external IPs implemented on daughter boards without requiring any hardware modification of the prototype board itself. Designs intended to run in the 100 to 200 MHz range require that the signal traces are laid out on the PCB carefully with appropriate impedance and length matching to avoid signal reflection and noise. Likewise the clock skews must be minimal, especially for high frequency clock signals. Other important considerations that are critical to a high quality board are evenly distributed power planes; multiple programmable voltages on the board; several low skew clock sources on the board which must be easily programmable to tap any desired frequency; built-in self-tests to guarantee that the prototype boards are free from manufacturing defects, such as open or short-circuit among FPGA pins or connector pins and to ensure that the voltages are within board tolerances and report temperature to avoid over-heating on the boards; ready to use peripherals and daughter cards which enable designers to select pre-designed and tested daughter cards.

Conclusion

The success of ASIC prototyping depends on the quality, flexibility, and functionality of both software and hardware, more importantly how well the tools are integrated resulting in minimal tool interoperability issues. Synplicity’s Confirma platform is a step towards that direction. Confirma offers a complete suite of tools, software and hardware, needed within a single platform. These tools work seamlessly and meet all requirements that are essential to achieve a high level of confidence in verification with highest user productivity. For details go to http://www.synplicity.com/products/prototyping_solutions.html.