Question to the OSVVM community: how to approach the methodology, learning curve

[Andrea]

Hello all,

I am new with OSVVM and I’d have some questions about the learning curve time and other details to consider.
In my past experience I worked as VHDL developer, so the reason why I would like to use OSVVM is that I do not want to learn SystemVerilog (for UVM). Second, in my current company there are few people that work as FW engineer and there is not a distinction between developer and verification engineer. We are a small team and at the moment we have not any Simulator license for example.
During the last year we used Matlab/Simulink with HDL coder to develop VHDL IPCore to be integrated into a Vivado reference design which is developed by an third-party company (out-sourcing). We are not happy with MathWorks tools and so we are evaluating the other possibility of algorithm development and verification.
Ah, I have forgot, in my team we work with FPGA and mainly image processing algorithm.

I would have the following question to ask to the OSVVM community:

1. Amount of time needed to learn the methodology and to get familiar with the library?

2. Amount of time needed to develop a missing Verification IP (e.g. AXI4 Full)?

3. How to handle the DUT that is a DSP algorithm?
Basing on my back experience I always used input/output test-vector pre-generated using a reference model (in Matlab or C). This means in the VHDL tb, read the input test/vector and write VHDL result to file. Then (offline) post process the data to check if the VHDL result matches the reference one.

4. I watched some tutorials about OSVVM and, if I am not wrong, the Simulator Vendor which is pushing for OSVMM seems to be ALDEC. What about the others, Mentor?

In the past I mainly worked with Modelsim PE. I tried few times Vivado Simulator, Modelsim Intel (it has limitation in performance based on the number of code or something similar). My company cannot afford to an expensive Simulator license like Questa.
Could you please so nice to suggest me one that provide the good thread-off for the OSSVM and its powerful functional coverage?

Thank you everybody in advance
Andrea Foradori

[Jim Lewis]

To answer your questions:
1. How much time is needed?
In an instructor led class, you can learn OSVVM is 5 days. With our on-line classes, this translates to 10 on-line sessions – each session is approximately 2.5 hours of lecture (currently done via GoToMeeting) and 2.5 hours of lab (done on your own with support via email, phone, and GoToMeeting (as needed)).

2. Amount of time to develop missing Verification IP (eg. AXI4 Full)?
That will vary with the complexity of the interface. That said, the OSVVM AXI Lite model is well structured to be updated to AXI Full. Given time, I have plans to expand the model towards an AXI FULL model – in particular I intend to add burst capability. My opinion is that even simple transaction models should also handle burst type transactions – even if that means on the interface does not support it a burst can be broken down into individual address and data transactions. Hence, a burst is a convenient testbench programming method.

3. How to handle a DUT that is a DSP algorithm?
The more you intend to do in VHDL, the more OSVVM will help. In your case where test vectors are read from a file and then applied to the DUT, OSVVM will allow you to compare the results while the VHDL testbench is running. This would allow you to stop when an error occurs and debug from there.

4. What simulators are supported?
OSVVM is tested on a current release of Aldec RiveraPRO and Mentor QuestaSim. We also regularly run regressions against ActiveHDL. It is our current understanding that Synopsys VCS and Cadence Xcelium both support OSVVM as does the open source simulator GHDL. I have not run regressions on these though. However, I am planning to do this.

Even the ModelSim Altera edition (the free version) can run “class” sized examples of OSVVM.

If you are working with AXI I would start by watching our webinar (if you have not already done so) Creating an AXI4 Lite, Transaction Based VHDL Testbench with OSVVM.

Next, at the end of the webinar, it walks you through the steps of loading OSVVM and running the scripts, so do this in your simulator. While I ran these scripts on RiveraPRO, the scripts run exactly the same way in ModelSim/QuestaSim. At the end of the day, it is my intent to expand the scripts so they run on the tools that support OSVVM – either as TCL or if necessary also as BASH.

[Miroslav Marinkovic]

Hi Andrea,

Regarding your question 3):

First, you mentioned that your current VHDL testbenches write output data into a file, and then you process (offline) the obtained data vs. reference data.
In my opinion, it is better to compare output data vs. reference data directly in VHDL testbench, because you have a self-checking testbench in that case.
I am aware that this approach requires that your reference DSP model (in Matlab, C++,.. or similar) should be
“bit-true” model.

In addition to the verification task which Jim mentioned, you can do:

– If your DSP DUT have several configuration, then I assume you can have a separate pair of stimuli (input) data and reference (output) data for each DUT configuration.
Then OSVVM can help you to randomize the DUT configuration and connect each DUT configuration with the corresponding pair (stimuli, reference) in VHDL simulation.
Of course you can also randomize the stimuli data, but you have them already in a file, and they are probably already random (generated from Matlab, C++, …)

– You can randomize, for example, “data_valid_in” signal of your DSP core (probably you have it, or some similar signal)

Best regards,
Miroslav

[Richard Head]

Hi Andrea

I am answering as someone who was in a simular position to you, who now has a good working knowledge of OSVVM and a full AXI4 Verification BFM available to me hand written using my own interfacing around OSVVM features. I have never done any OSVVM training, but I do have a background with some experience of SV and UVM.

1. I cannot comment on any training, but I think one big advantage of OSVVM is it’s toolbox like approach. It is very easy to add certain parts to existing testbenches. I have seen several older testbenches where I wrok where people have picked up OSVVM purely for the randomisation package and to a lesser extent, the logging. These are probably the two easiest parts to start using. A lot of the knowledge you need to use OSVVM is more testbench theory than OSVVM itself. I did a Doulos advanced verification course about 15 years ago, plus my UVM experience, which made my take up of OSVVM much easier. Often it is these concepts that are the hardest to learn.

2. I custom built an entire AXI verification package, built around OSVVM. I do not use the OSVVM transaction techniques but it is full of scoreboards and logging. My main reasoning was that simulating a MIG and DDR is SLOOOOOW, so I needed something much more lightweight. It is now capable of bursts, transaction queuing and timeout alerts. And because I went all in with AXI4, AXI4L came for free (its just a limited subset of AXI4 – my AXI4L master BFM are little more than a wrapper around the AXI4 BFM). I have two slave BFMs – a simple one that simply absobs transactions and returns responses (randomised data for reads). This is useful if you are testing only the write side, for example. And another that has a memory model underneath. It is extremely fast (plugging a Master BFM into a Slave BFM I can write an entire 4k picture in about 5 seconds with axi transactions). This initially took about 3 months of work pretty much dedicated to this BFM, with plenty of additions and tweaks in the 2 years since I wrote it.

3. Getting a scoreboard working first comparing actual vs expected data would be a good first step. Then you could probably use the Coverage package to maybe reduce the need of using externally generated data (it would likely require a VHDL model though).

4. I think Jim Covered this.

I think ActiveHDL is pretty cheap for a single language licence. I think it is about 1/4 the price of questa. It is very fast and very capable.

Good luck with your OSVVM journey

Richard

[Author]

Posts