Verifying Large FPGAs Isn’t Easy

FPGA designers using VHDL have three choices: Stick with VHDL, switch to SystemVerilog, or.. use the best of both. This guest blog from Doug Perry, Senior Member Technical Staff at Doulos, outlines the pros and cons of each.

The latest crop of FPGA devices are enormous when compared to ASICs that were built not that long ago. Verifying these ASICs required detailed plans, multiple tools, and sometimes special languages. Verification was key because the cost of a respin was prohibitive.  FPGA designers using VHDL have three choices: Stick with VHDL, switch to SystemVerilog, or.. use the best of both. This guest blog from Doug Perry, Senior Member Technical Staff at Doulos, outlines the pros and cons of each.

The same is not necessarily true of FPGAs because they can simply be re-programmed when an error is found. However the cost of finding the error in the lab can still be very expensive. This is related to the fact that the number of LUTs available in the device has skyrocketed, but the number of IO pins has not. Therefore getting visibility into the inner workings of the device from outside becomes much more difficult. Finding the source of an error therefore also becomes increasingly difficult. To counteract this problem, designers need to find errors before the device gets into the lab. To do this they need to adopt ASIC-like verification methodologies.

A large number of FPGA designs are still developed using VHDL. Part of this is historical, other reasons are because a lot of the Intellectual Property blocks used in an FPGA may only be available in VHDL. If these designers want to use ASIC-like verification methodologies like UVM, how can this be accomplished?

So what are your options?

Not every design lends itself to using a UVM constrained random methodology. It also may not make sense for smaller teams to spend the resources required to learn SystemVerilog, learn UVM, and build a UVM infrastructure for use in their company. However other projects may have complex control verification requirements that can be ideal candidates for constrained random, and the project may be large enough to justify UVM adoption.

Usually FPGA designers have three choices: they can stay with VHDL by using the advanced features of VHDL 2008 for both the design and the testbench, they can switch the entire design and testbench to SystemVerilog, or they can use a mixed language approach.

1) Stick with VHDL

The easiest and most straightforward approach would be to use the advanced features within VHDL 2008 to create better testbenches. VHDL 2008 has a number of features that allow quicker and easier design and also facilitate much better testbench capability. Combined with OSVVM, large FPGA verification can become quite sophisticated. This approach has the advantage that existing VHDL designs and VHDL IP can be leveraged. The bad news is that this approach does not quite have the same level of functionality of a UVM approach.

2) Switch to SystemVerilog

The second approach involves switching entirely to SystemVerilog. The FPGA verification engineer can now use constrained random, coverage-driven verification and/or assertion-based verification, but converting a design to SystemVerilog can be a huge project on its own. Additionally there is a learning curve when converting from VHDL to SystemVerilog that can be quite challenging because SystemVerilog does not have strong type checking. VHDL designers often rely on strong type checking to keep them out of trouble, and when that capability no longer exists in SystemVerilog, these designers can spend a lot of time tracking down errors related to type conversions that happen automatically in SystemVerilog. These are errors in VHDL, but SystemVerilog silently does the conversions with no indication that there was an error.

3) Use the best of both

The third approach would be to leave the design in VHDL, but write the testbench in SystemVerilog. This approach provides the best of both languages. Strong type checking in VHDL prevents design errors, while SystemVerilog testbenches can take advantage of the capabilities of UVM. The design code does not need to be translated, only the testbench. The only disadvantage is that the simulation tools would be required to support multiple language capability. This is usually a licensing issue, and one that the user probably has already had to deal with with respect to IP compatibility.

The approach chosen will depend on how much of the power of SystemVerilog and UVM are required, how much of the previous design is to be reused, and how much time is available to learn SystemVerilog and UVM. SystemVerilog is not a magic language that will solve all verification problems, but it is a very powerful tool in the verification toolbox that if wielded properly can create very capable designs and testbenches.

Find out more to help you make up your mind…

To help you decide what might work best for you, why not attend 2 free webinars presented by Doug Perry, Senior Member Technical Staff at Doulos.

Fri Dec 18 2015: Getting in SystemVerilog from VHDL – Register Now »

Fri Jan 15 2016: Learn how VHDL 2008 is ready for the Big Time (at last!) – Register Now »

These one hour webinars are broadcast twice for a world-wide audience and include live Q&A with Doulos technical experts. They are a great opportunity to help you get a clearer picture of the options and answer some of your questions.

The webinars include code examples running in Aldec Riviera-PRO™ on EDA Playground.

Tags: doug perry, doulos, FPGA, resources, systemverilog, uvm, verification, VHDL, Webinar

Category: Functional Verification

This entry was posted on Tuesday, December 15th, 2015 at 3:16 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.