Electronics > FPGA

VUnit, UVVM, OSVVM: What are similarities and differences?

(1/7) > >>

matrixofdynamism:
The VUnit, UVVM and OSVVM are all aimed to make testbench design easier for VHDL projects by introducing HVL like features into the verification process. They all target SystemVerilog UVM and other language's verification methodologies.

I can see that there is some overlap between VUnit, UVVM and OSVVM but don't understand what each of these are really good for and not good for. Also, I do not understand the features that are present on one but not the other. Ultimately, each of these will excel in something so it would be worth using something from all of them to create the best verification environment.

Has anyone used all VUnit, UVVM and OSVVM?

laugensalm:
I've had to use some OSVVM and had a look at VUnit and its cousin cocotb,
OSVVM is sure an approach with a lot of motivation behind it, but after moving all HDL development to the Python world, I wouldn't want to mess with such a massive overhead any longer. This is mostly due to VHDL being very difficult when it comes to separating pure hardware elements from simulation constructs and limited language functionality WRT to verify constructs 'inline'. This is something where Python as an interpreted language with its meta programming caps has way more potential.

I got stuck with MyHDL co-simulation for a long time for complex mixed language projects where algorithms sketched in Python run alongside their hardware-inferred counterparts. Made VUnit void in my case, but if you have to test your setup with various simulators, it might still be the tool with best interfacing support, but I'm not up to date.
The only problem with MyHDL is that one has to live with the status quo of its architectural issues.

It all depends a bit on what kind of hardware you're developing and what the customers request. With self-verifying approaches from the Python world you can skip a lot of traditional pitfalls that actually require the overhead of *VM libraries due to the V* language deficiencies as design languages for authoring hardware logic.

If you're going 'traditional' with the standard money tools, VUnit via its *VM APIs is probably a safe way to develop proper CI/CD tests. However it may still lack some features for proper Co-Simulation with open source simulators like GHDL and ICARUS, so it might not support sticking complex designs into the model in the loop.

matrixofdynamism:
If Python is adept at hardware design and verification, I am interested to know why it has not taken over the industry yet. I am not at all well informed on the subject.

By co-simulation you mean processor running software connected to peripherals that are HDL designed via some sort of standard bus like AMBA AXI?

Jim Lewis of OSVVM (also leading VHDL language development) has done something for cosimulation and here is article. But, I am not sure if this is actually any good since it is quite new.
https://osvvm.org/archives/2159

I am actually kind of fed up with the hardware domain lagging SOOOOOOO much behind the Software domain. VHDL-2019 was released a few years ago but most tools still do not even support all of VHDL-2008. Then there is this divide between VHDL and SystemVerilog. Then we have SytemVerilog UVM which the VHDL world is trying to catch up with by developing UVVM, OSVVM, VUnit. We have different vendors like Intel, Xilinx, Microsemi, LatticeSemiconductor and who knows what else that might have decent silicone but the software tools are just terrible or almost unuseable sometimes. I mean, why not all work together and make a lot of open source tools as well? All we need is decent simulators with decent wave viewers and BFMs for complex things like full AXI4. Is that really asking for a lot? But that is a different topic altogether.

laugensalm:
I second your pain WRT V *HDL. Have to be careful not to stir up another language war, but one aspect from software development is that a proper VHDL parser and AST representation is pretty darn hard to fully implement (I've tried some static analysis and moved on to Python, eventually). So, we got a massively over engineered VHDL and...an easy to parse hack called Verilog tricking developers with its implicit behaviour.
Then classic hardware developers at least in the german speaking domain where I'm from are extremely unwilling to learn new methodologies, thus 80's HDL material is taught on technical universities, mostly. So there's quite a lag.
Other than that, I'm aware of quite a bunch of developers who don't only *test* their HDL using Python, but also develop in it (including me).
Big vendors are also good at telling you your new methodology is crap, until they suddenly happened to have come up with it by themselves (I could tell stories..). So, I can even see OSVVM lagging behind 10 years...I believe it was 2013 when I published virtual debugging methods via co-simulation using GHDL/ghdlex on the embedded world show.

Co-Simulation would be anything that runs in both worlds, not necessarily a processor. It's basically just looping in your own simulation driver into the HDL simulator's main loop in an asynchronous way. A kind of a 'standard' to do that is the VPI interface of most simulators, then there's VHPI on the VHDL side. And there are various code-emitting backends (MLIR, CXXRTL) that can be driven alongside a python simulation.
Example: A hashing algorithm is to be put into hardware. Algo is sketched in Python, provided with a unit test, someone has implemented a core, now your task is to verify correct behaviour for an incoming data stream. So you'll run the software and the hardware model in a virtual 'lock step' mode driven by a Python main loop.

There's a lot in the OpenSource that is really usable, sometimes also a lot more performant than some of the official money tools. I've got a few examples, if you're interested.

So, you've basically got the choice to go traditional or be stubborn about it and find a method that fits you best, despite what 'industry' says. Eventually, you've got to do the interfacing and testing right so that you can for example emit your testbench to a classic HDL for 'traditional' engineering so that they can verify the design the good old way.

SiliconWizard:
I've looked an toyed with OSVVM, it's a well thought out framework, but ultimately I've failed to see any benefit compared to writing testbenches with just VHDL. I can't say for the 2 others.

But it's like with all frameworks: they may give you a real benefit in some contexts, or just give you the illusion of a benefit, or may just please upper management, or you may like that for personal preferences.
I personally have a general rule of limiting tool "bloat" and dependencies on third-party tools, especially those that are too big and complex to be fully inspected before using them.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod