Aldec Design and Verification
Dr. Stanley M. Hyduke
Aldec Founder/CEO - Born in Poland, Dr. Hyduke received his Master of Science in Telecommunications Degree in 1962 from Technical University of Wroclaw, Poland and obtained his Doctorate from Kharkov Technical University in Ukraine. Dr. Hyduke held positions at EDO Commercial Corporation, Control … More »
Aldec Verification Tools Implement the ASIC Verification Flow
May 10th, 2016 by Dr. Stanley M. Hyduke
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:
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.