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.