cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
408 Views
Registered: ‎03-07-2018

Vhdl verification roadmap recommendation

I have a task to verify a fairly complex vhdl project in my work and I don't know where to start.

I am newly graduate fpga engineer and the complexity gap between university project and real project is so big. I realized that the university approach of testing each file and move to the next is not gonna work so I start looking on better way

I have been doing some research to increase my verification skills in vhdl and found 3 main tools that is used.
1. OSVVM.
2. UVVM.
3. VUnit.

So I wonder if there is anyone with good experience in vhdl verification to give me a guide, road map, resources, or advice in the strategy of building and designing a testbench.

0 Kudos
4 Replies
Highlighted
Xilinx Employee
Xilinx Employee
371 Views
Registered: ‎05-22-2018

Re: Vhdl verification roadmap recommendation

Hi @ahmad.zaklouta ,

Check apendix C if you are using Vivado 2019.2 for UVM support:

https://china.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug900-vivado-logic-simulation.pdf

Thanks,

Raj

0 Kudos
Highlighted
Scholar
Scholar
356 Views
Registered: ‎08-01-2012

Re: Vhdl verification roadmap recommendation

@rshekhawThe OP asked about UVVM , Universal VHDL Verification methodology, and open source VHDL testbench framework, not SystemVerilog UVM.

@ahmad.zaklouta

I highly recommend you stick with VHDL to start, and learn the techniques used in verification in any of the packages you suggest. These techniques will apply to any verification you do in any language.

As for the packages you suggest, you really need to separate VUnit from OSVVM and UVM.  Also note, none of them will work in Vivado due to its poor VHDL support in the simulator. You will need a 3rd party simulator to get them to work, and VUnit requires a Python environment. GHDL is a FOSS vhdl simulator (you'll need something like gtkwave to view any waveforms) that will support OSVVM and UVVM, otherwise you can get Modelsim for free from the Intel webpack, otherwise ActiveHDL is very good (and the developers actively develop for and support OSVVM and UVVM). VUnit should work with any tools, as it uses python to fire up the simulator.

1. OSVVM is probably the easiest to learn, and possibly the most flexible of the three. It is a set of packages that you add to your own testbenches as you need them. Usuaully you'll start with the random package and then add in the logging, scoreboards and coverage. It does have a transaction package which provides a method to perform transactions via custom resolution functions. Because it is so flexible, you may need to apply more thought if you want to create re-usable code.

2. UVVM is more like an entire framework rather than a flexible set of tools. It tries to replicate the architecture of traditional UVM using VHDL. You need to architect your testbench in the "UVVM way", but if you do this then you get some very powerful test capabilites and modules that are more compatible and re-useible. You can also use OSVVM within your UVVM testbenches/verification modules.

Btw, here is the Cynical viewpoint: both OSVVM and UVVM were created and maintained by VHDL training companies. OSVVM by Synthworks and UVVM by Bitvis AS . Synthworks is run by the Chairman of the VHDL working group (who write and maintain the VHDL standard).

3. VUnit is more of a CI environment. It is mostly written in python and allows tests to be defined within the envirment, so multiple tests can be completed in a single run. It can run SV or VHDL tests. Think of this as an alternative to Jenkins or Gitlab CI.

 

Personally I am fully bought into OSVVM. I have an entire custom AXI verification IP setup in VHDL that uses a lot of OSVVM and it is extremly powerful. We then use Gitlab for our CI. Both UVVM and OSVVM provide AXIs and AXI4L BFMs.

Whatever you chose, be prepared to use new techniques. Alot of verification uses software style coding, so you'll need to get out of a hardware mentality for your testbenches. As a start, I suggest learning about protected types and how they work, as both OSVVM and UVVM use them extensively.

Feel free to post for support for OSVVM here (as I can help).

Good luck

Highlighted
Teacher
Teacher
322 Views
Registered: ‎07-09-2009

Re: Vhdl verification roadmap recommendation

Why do you say the classic test bench method wont work ?
You can test bench at any level, from the top module to individual functions,

As with all verification, it sup to you as to what level of verification you want.
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Visitor
Visitor
212 Views
Registered: ‎08-25-2017

Re: Vhdl verification roadmap recommendation

@richardhead @ahmad.zaklouta @rshekhaw 

Some clarifications and corrections on VUnit and its relation to UVVM, OSVVM and UVM

VUnit have two main layers of functionality. It's a

  • Framework for full testbench automation = the ability to fin, compile and run all, or parts of your testbenches, with a single command and get a test report in return that catches any type of error (asserts, compilation issues, simulator crashes etc)
  • Set of VHDL/SystemVerilog utility packages

It's the first part that @richardhead  refers to as the "CI environment" that is mostly written in Python. This is what goes on outside of your simulator when doing full automation and nothing that can be developed in VHDL or (System)Verilog. It's independent of how your HDL testbenches are written, i.e. you can use it with utility packages from VUnit, OSVVM, UVVM, UVM or none of them. It enables integration with Jenkins or Gitlab CI, it's not a replacement for these CIs. The single command I described is something you routinely run on your machine with the tests you're working on but the same command can also be executed by Jenkins, Gitlab and all the other CIs out there, for example when doing nightly test runs of your code. VUnit provides the report formats used by these tools for smooth integration. The full framework automation is unique to VUnit and since it works with the others you should really try it out regardless of what solution you have for your HDL.

VUnit provides a set of utility packages land this is where there is a functional overlap as VUnit also provides more advanced logging and assertions, transaction support and BFMs (including AXI) like the others. It doesn't provide randomization features but includes OSVVM for that reason so when you download VUnit you get both. I really recommend that you make up your own mind by trying out examples provided with the frameworks but there are a number of mindsets behind VUnit which I think is visible in its solutions.

  • VUnit targets verification on all levels, from SW style unit testing performed by the developer to system level testing (potentially performed by an independent team of verification engineers). OSVVM, UVVM and UVM have more of a system verification background. Designers working with VHDL prefer that as their verification language and that's why VUnit also promotes VHDL testbenches for VHDL code. A not so uncommon misconception is that VUnit promotes Python for verification just because it's used (by necessity) for the top-level verification management. This is not the case. This is more the way of the cocotb framework. Unit testing also requires a much much quicker turnaround time than system testing which means that adding, removing and updating tests must be very simple. I think that's visible.
  • Writing verification code is more of a software task and VUnit packages are to a large extent clones of established SW design patters. Logging and message passing used for transactions are good examples of this.
  • OSVVM, UVVM and UVM are maintained by companies providing commercial tools and training services while VUnit is a more traditional open source project. That openness is very visible if you look at the activies in their Github pages and it reflects in the open source popularity of the tools


It should also be noted that there is a VUnit fork supporting Vivado.

Disclaimer: I'm one of the VUnit authors