Addressing DV Professionals’ Need to Reduce Verification Errors in Complex Designs

 

There is no doubt that design verification (DV) is an engineering specialty quite distinct from hardware design. Designers write register-transfer-level (RTL) code in SystemVerilog, Verilog, VHDL, or SystemC and use logic synthesis to turn their descriptions into actual chips. DV engineers are responsible for ensuring that these designs meet the chip specification. Their goal is to enable the fabrication of bug-free silicon that will work when it arrives from the foundry. This post discusses some of the needs of DV professionals and how we help meet them.

What Is the DV Role?

Being a verification engineer is tough. Chips today are verified with two main techniques: static checks and simulation using constrained-random testbenches. Static analysis start with simple “lint” checks of the RTL code, followed by specialized checks for issues with clock domain crossings (CDCs), reset domain crossings (RDCs), testability, and more. These checks often use formal verification engines, which can be even more valuable if your designers or DV team write assertions about design intent. Formal tools either prove the assertion correct or find a way to violate it.

Static techniques are increasingly important, but simulation remains the primary method for design verification. Your DV engineers develop testbenches containing drivers, sequencers, scoreboards, protocol monitors, results checkers, coverage objects, and more. They must also write constraints that steer automatically generated pseudo-random stimulus toward the parts of the design not yet verified. For both static and simulation-based verification, the DV team uses coverage metrics to assess how well the design has been exercised.

Finally, whenever any verification check or test fails, the DV engineers must work with the designers to find the bug in the design that caused the failure, fix it, and to verify the fix. That’s a lot to know: static, formal, simulation, tests, constraints, assertions, and debug. DV professionals write not just in SystemVerilog, Verilog, VHDL, and SystemC, but also in Tcl, Perl, C/C++, Java, and more. Of course there are specialists for many tasks and languages, but the average DV engineer has broad knowledge of the complete chip verification process.

What Is a Verification Error?

So far I’ve focused on the core of the DV process: finding bugs in the hardware design. Such bugs are inevitable; designers are human and humans make mistakes. The point of DV is to find and fix bugs before you spend millions of dollars to fabricate chips. But there’s another source of pain for the DV team: errors in verification code. After all, DV engineers are human too, and they also make mistakes. Many times a test failure is traced back not to a hardware bug, but to an error in a testbench component, an incorrect assertion, or incomplete constraints that allow illegal stimulus to be generated.

Having a separate DV team is partly motivated by the fact that it is such a different role than design, with all the specialized knowledge I discussed previously. In addition, having split teams has the advantage of enabling two independent viewpoints. The designers and the DV engineers develop their code independently from the chip specification, a much safer approach than having a single engineer write both the RTL design and the tests to verify that design. As noted ealier, both teams can make mistakes. Test failure can be due to design bugs, verification errors, or both in the same test. 

The best way to avoid both design bugs and verification errors is to follow a correct-by-construction methodology. This starts with reusing proven design and verification code whenever possible. A design (or part of a design) that has been successful in silicon and the testbench (or piece thereof) that verified that design are much less likely to have issues than fresh code. In addition to reusing parts of your previous projects, an entire industry of commercial design and verification has arisen. We actively participate in this industry ourselves with our Silicon IP Portfolio.

Correct-by-Construction Verification

The other way to avoid errors is to use proven tools to generate design and verification code. Most people probably know Agnisys first and foremost for our generation of RTL code for registers, memories, and inter-block connections during chip assembly. Our IDesignSpec™ (IDS) Suite includes several products that save designers time by automatically generating parts of their design and ensure a smooth DV process since tests won’t fail due to design bugs. However, hand-written verification environments can still fail due to internal errors, requiring debug time and effort.

We automatically generate proven verification code as well as RTL code. When you use IDesignSpec to generate your registers and memories, our IDS-Verify™ solution generates a testbench and tests compliant with the Universal Verification Methodology (UVM). We also use AI techniques to generate tests with our AI2 solution. We tailor these tests for the many different register types we support, ensuring high coverage. We also allow you to use PSS or natural language to specify custom sequences for register access that we can leverage in our generated tests. We even generate SystemVerilog Assertions (SVA) for use in both simulation and formal verification.

We do even more by enabling hardware-software co-verification, also called pre-silicon validation. IDS-Validate™ generates C/C++ code to access and test your registers as well as a pre-silicon validation environment that supports both the UVM testbench and your embedded processors running the C/C++ tests we generate. Our users find that this code is highly valuable since it also runs on the actual chips during post-silicon validation in the bring-up lab. You can leverage our application programming interface (API) when writing your production drivers and other low-level software.

Conclusion

Your DV engineers have a tough job, involving knowing a lot about a lot of tools and languages. Finding and fixing bugs in the hardware design is the main goal, but along the way they will encounter errors in their hand-written verification code as well. We help by automatically generating parts of your design, testbench, and validation environment directly from the golden chip specification. We’d love to do what we can to make your DV process faster and smoother. Please contact us to learn more.