Aldec Verification Tools Implement the ASIC Verification Flow

Aldec has, over the last 30 years, established itself as the preferred provider of high-performance, cost-effective verification tools for use in proving out complex FPGA designs. As the logic capacity and capability of FPGAs have increased, however, the distinction between FPGA and ASIC design has narrowed. A modern FPGA verification flow looks very much like an ASIC verification flow.

Small and large fabless companies alike need a reliable verification partner that suits their budgets while still providing a high level of support. To answer the call, we at Aldec have extended our spectrum of verification tools for use in digital ASIC designs.

A Basic ASIC Verification Flow

Managing verification for ASICs requires a well-defined verification plan.  Efficient verification planning starts with functional and design requirements in which requirements are mapped to verification methods, scenarios, goals and metrics, coverage groups, and results. Mapping entails traceability throughout the project that must be well maintained so that changes in the requirements will seamlessly reflect potential changes downstream to the elements of the verification plan.

While traceability can benefit any design, it is mandatory for safety-critical designs regulated by standards such as ISO-26262 for automotive, IEC-61508 for industrial and DO-254 for avionics.

ASIC design is done almost exclusively at the RTL level. Before functionality is verified, the coding style and structure of the RTL code must be vetted to ensure good code maintainability, to provide for safe synthesis, and to catch potential bugs at the earliest possible stage.

This is the role of linting tools. Such tools use both static and dynamic analysis to ensure that as-written code is of good quality. Certain classes of design – in particular, those intended for safety-critical applications – must adhere to specific coding rules. Such standards include:

• DO-254, a hardware design assurance process for avionics applications;
• The Semiconductor Technology Academic Research Center (STARC), a consortium of 11 major Japanese companies, which has established a well-attested set of rules for coding; and
• The Reuse Methodology Manual (RMM), which contains rules that make code easier to reuse in new designs.

For such designs, linting tools must have access to specific rules libraries against which the design can be verified.

An additional challenge in larger ASIC designs is the prevalence of multiple clock domains. Extra care must be taken to ensure that signals crossing those domains are properly handled. Failure to do so can result in functional and timing failures, or, worse yet, in unreproducible internal metastability. Clock-domain crossing (CDC) tools ensure that signals are properly buffered as they cross from one domain to another.

Once analysis has demonstrated clean code and clocking, then simulation verifies basic functional behaviors across a set of test scenarios. This starts at the unit or module level, where a large number of tests can be run with short simulation run times.

When the individual modules have been integrated into an overall chip design, simulation opportunities may become more limited due to the time it takes to simulate very large circuits across a large number of tests. This is where acceleration can help.

All of the verification acceleration modes involve hardware emulation. An emulator allows the design under test (DUT), as well as synthesizable portions of the testbench, to be implemented in hardware, speeding up execution by hundreds or thousands of times.

The simplest acceleration involves execution at the bit level, but greater speed can be achieved using a SCE-MI interface between the host and emulator. A SCE-MI interface communicates transaction-level, rather than bit-level transactions between the host and emulator. The SCE-MI interface can be used in a number of different verification scenarios, including UVM acceleration and hybrid emulation (or co-verification) using simulation and emulation together.

When timing is critical, at-speed testing of complex design modules can build confidence that the slower-speed simulation and emulation verification haven’t overlooked timing-related bugs. This testing is done once all other bugs have been eliminated, providing greater confidence when the module is integrated into the overall design.

Programmers creating low-level drivers and other code that touches the hardware directly will want to get started coding as early as possible. A virtual platform in conjunction with an emulator is ideal for testing code and SoC level verification in the early stages of hardware design. Once the RTL stabilizes, hardware prototypes enable higher-speed hardware and software testing.

For the rest of this article, visit the Aldec Design and Verification Blog.

Tags: acceleration, asic, Emulation, linting, prototyping, simulation, SoC and ASIC Prototyping, verification

Categories: Emulation/Acceleration, FPGA Design, Functional Verification, Requirements Management, SoC Design and Validation

This entry was posted on Tuesday, May 10th, 2016 at 4:07 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.