Author Topic: VUnit, UVVM, OSVVM: What are similarities and differences?  (Read 4510 times)

0 Members and 1 Guest are viewing this topic.

Online laugensalm

  • Regular Contributor
  • *
  • Posts: 123
  • Country: ch
Re: VUnit, UVVM, OSVVM: What are similarities and differences?
« Reply #25 on: June 09, 2024, 09:23:34 am »
Variable args from the co-simulation side isn't really an issue, I guess.

The primary example I have is the mentioned memory mapped register decoder, where, depending on your configuration (<n> UARTS, <m> I2C, other optional peripherals), the MMR peripheral bus slave interface is far away from being static. Thus, all SoC vendor specific tools generate that code from a register map and peripheral description, typically. I'm using an open XML solution similar to IP-XACT)
Then there might be a portable/configureable SoC wrapper on top which translates to several architectures/configurations.

So far I found two solutions:
1) Bare metal: Use #ifdef C-preprocessing style to generate VHDL code that is understood by *all* involved tools out of one top level source file. Plus: Debuggable as 'verbatim' output, Minus: #ifdefs turn the source into a mess at some point and only the big simulation matrix will typically reveal when you break something.
2) Generate everything altogether from Python HDL by using design class hierarchies (VHDL does not provide that level of OOness). Conditional compilation is still possible, but not at an error prone preprocessing stage. Minus: Having to partially re-create/re-verify designs, Plus: Get your verification done 'inline' the automated way, reduce maintenance complexity.

Variant 1a) if you will is to use only generated VHDL records in the interface and 'if .. generate' constructs inside the architecture. However there are catches with some tools, like requiring the source of the non-enabled module being included anyway. This is a no go in at least one customer scenario.

On the other hand, Verilog allows some pragmatic preprocessing fun, but when VHDL source is required...

There was some hope on the horizon a while ago using monolithic approaches as SystemVerilog or advanced Scala based HDL. Then we made some road with Python/MyHDL, which unfortunately has gotten to a certain grade of quirkyness, but at least solved a few portability issues with rather robust and clean syntax that would prove extendable for co-simulation and elegant verification methods. However, the procedural generation capabilities of the MyHDL 'kernel' are limited as well.
 

Offline OsvvmDev

  • Newbie
  • Posts: 1
  • Country: us
    • SynthWorks VHDL Training
Re: VUnit, UVVM, OSVVM: What are similarities and differences?
« Reply #26 on: June 11, 2024, 04:46:48 am »
Just my opinion: If VHDL had integrated such (standardized!) fundamentals, plenty of kludgy ballast could be thrown over board a
. . .
With 'interface' I've meant  port and generics, in fact. In VHDL there's obviously no such thing as variable length parameter list. To some extent you can cover some details using records, but this is again not well thought through until '2019...and, well, you know the rest of the story.
If you are interested in contributing to the development of VHDL, please see:  https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues/

Towards more flexible interfaces, VHDL-2019 added mode views for records.
VHDL-2019 added conditional compilation too.

One of the things we have on the issues lists that would make interfaces more flexible is to Ada-like discriminants.   For adding these to entity and subprogram interfaces see:   https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues/205   For adding these to types and subtypes see:  https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues/81 

During the VHDL-2019 standard, the VHDL working group was staffed by user volunteers.   To make progress, we need more people who are willing to active participate and actively advocate to their vendors to support VHDL-2019 (and unfortunately VHDL-2008 in some synthesis tools).   

I personally invested 1000s of hours into VHDL-2019.   It is time to turn that over to the next generation, such as the people commenting here.   My passion is OSVVM, so that is likely where I will where I will invest most of my time.   We need people participating at all different levels - from administration to reviewing proposals to writing proposals and language change specifications.   We need many people each contributing some in order to make good timely progress.

I saw comments about VHDL not being consistently supported and XSIM as an example of that.   Based on my testing of simulators WRT VHDL-2008, all except XSIM do very well.   I have personally tested with NVC, GHDL, Aldec's ActiveHDL and RivieraPRO, Synopsys' VCS, Siemen's Questa and ModelSim, and Cadence's Xcelium.   XSIM has made some good progress in 2023.2 and 2024.1, however, is not quite there - but is getting much closer - I have all of the OSVVM utility library working and many of the verification components are working.   

WRT VHDL-2019 I have tested with Aldec.   NVC is working on VHDL-2019 features.

I could comment in detail about OSVVM, but it would be biased and it would be the same stuff you have seen me write at https://osvvm.org/ or https://osvvm.github.io/Overview/Osvvm1About.html or Linkedin.   

If you have specific questions about OSVVM, a great place to ask is https://osvvm.org/forums/forum/os-vvm

Like Lars, I think the future is through building a community and collaboration with others.   One great example of this with OSVVM is our collaboration with Simon Southwell and his VProc virtual processor.
 So the new part of OSVVM's Co-Sim capability is the integration of the two projects - both of which are fairly mature by themselves.   VProc has a RISC-V simulator among a wealth of other capabilities.   See:  http://www.anita-simulators.org.uk/wyvernsemi/articles/index.html

One of the hard things with getting OSVVM, VUnit, and UVVM going in the same direction is we all have lots of history with our given approach.   Past attempts at collaboration have been unsuccessful.   One characteristic of open source people is they are passionate and have strong opinions about their approach - including naming styles.
 

Offline lasplund

  • Newbie
  • Posts: 6
  • Country: se
Re: VUnit, UVVM, OSVVM: What are similarities and differences?
« Reply #27 on: June 12, 2024, 01:11:28 pm »
I'd say that vectorized interfaces + generate statements is the most straight-forward way to provide the configurability you're looking for. If some tools have problems with such a solution you will need a workaround but VHDL is not to blame for that.

If the workaround is to generate the VHDL, I would look for some machine and human readable format that is the specification. XML is not great for human reading but it works. The VHDL representation of that specification as well as all other representations (doc, drivers etc) are generated from that single source of information.
 

Online laugensalm

  • Regular Contributor
  • *
  • Posts: 123
  • Country: ch
Re: VUnit, UVVM, OSVVM: What are similarities and differences?
« Reply #28 on: June 16, 2024, 07:53:25 am »
I'd say that vectorized interfaces + generate statements is the most straight-forward way to provide the configurability you're looking for. If some tools have problems with such a solution you will need a workaround but VHDL is not to blame for that.

If the workaround is to generate the VHDL, I would look for some machine and human readable format that is the specification. XML is not great for human reading but it works. The VHDL representation of that specification as well as all other representations (doc, drivers etc) are generated from that single source of information.

Not sure what you mean by vectorized, but coercing records into SLVs is not an option. Plus, apart from `generate` not being orthogonal enough as a language construct (being a concurrent statement, i.e. not allowed inside a FSM process, for instance), it tends to make the code as messy and hard to maintain as the CPP hacks or the 2019 "`if" constructs. This is where OO concepts (class derivation) create less overhead.
Sidenote: the CPP hacks for configureable FSM states were required in order to pass coverage tests.

Sure, VHDL per se is not to blame for synthesis interpreting the 'standard' in its own way or not fully. Its complex architecture is just a hindering factor in synthesis tool development from a pragmatic perspective, so i'd assume it pretty unlikely that VHDL 2019 will make it into most vendor's synthesis tools, unless something radical is happening on the CIRCT/MLIR domain that is adopted by the commercial tool folks.

XML is just a widely accepted industry standard, readability might be debateable, but there's quite a number of schema capable editors that make authoring easy. And for the most recent status quo, I'd consider Python pretty readable as a HDL source, but I'm aware of HDL coders hating the indenting scheme, too. I'd just say: At the end of the day, a robust IP core must be delivered..

 

Offline lasplund

  • Newbie
  • Posts: 6
  • Country: se
Re: VUnit, UVVM, OSVVM: What are similarities and differences?
« Reply #29 on: June 18, 2024, 09:20:26 pm »
I was thinking about vectors of records. Generate statements is one approach but sequential code can also depend on the size of those vectors. There are of course countless examples where problem x in language y is better solved in language z, no matter x, y, and z. Question is if the alternatives are compelling enough for a switch?

I have probably seen dozens of alternatives to mainstream HDLs during my career but for various reasons they don't seem to get significant traction. I also see many initiatives among my clients. Mostly individuals experimenting and some pilot projects. Never seen it at scale for any duration. This is why VUnit is HDL centric with options to extend when needed (here is an example). We should keep trying though and the next initiative I will explore is probably Spade.

Other widely supported formats that I prefer over XML are JSON, YAML, and TOML.
 

Offline EspentT

  • Newbie
  • Posts: 1
  • Country: no
Re: VUnit, UVVM, OSVVM: What are similarities and differences?
« Reply #30 on: June 24, 2024, 06:05:00 pm »
I guess I cannot really be neutral when it comes to UVVM vs OSVVM (or Vunit), so I will not comment on that, but only comment on why a VHDL verification methodology may be your best choice.

I think it is important first to evaluate where people spend time on verification. So, first of all, according to Wilson Research, half the verification time is spent on debugging. That means the debuggability / debug support is critical, and the best way to reduce debug time is to have a very good testbench structure and easily understandable high level commands. Making a component oriented very structured TB architecture is really simple in VHDL, and in UVVM it is a bit like Lego. But the time spent here is not necessarily very significant. What really *is* significant is the time you spend developing, debugging and running your many test cases. This easily constitutes 60-90% of the total verification workload.

Here, good VHDL verification methodologies are as good as any other more modern software oriented language. The following test case lines from UVVM show that even SW designers can easily both understand and write FPGA test sequences:

axilite_write (REG_INTERRUPT_ENABLE,  AXISTREAM_IRQ, “Enabling AXI-S interrupt”);
axistream_transmit (v_byte_array, “sending packet ***”);
axistream_expect (v_byte_array, "receiving packet ***";
axilite_check (REG_INTERRUPT_STATUS,  AXISTREAM_IRQ, “Receiving AXI-S interrupt”);


The byte array illustrated here could of course be any size, as the parameter of the procedure is unconstrained. The example shows overloads where the actual signals are not included, but this would be similar in any sensible approach.
Good sequential sequences like this are simple to write in any methodology, but accessing these interfaces simultaneously requires a more structured testbench, and UVVM allows simple control of such testbenches as well, thus providing a great means for detection of cycle related corner cases.

There are in fact many similar error prone digital design aspects of FPGA design that most SW designers would never search for. A VHDL testbench with concurrent procedures, processes or verification components – organized in a very structured architecture, such as the Verification components of UVVM would handle this better than any existing non-HDL oriented languages or methodologies.

You can find more information under : https://emlogic.no/uvvm/
« Last Edit: June 24, 2024, 06:11:56 pm by EspentT »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf