VHDL equivalent of systemverilog

[hobbyiclearner]

Hello,

I am a basic user of VHDl and wanted to know if there is any VHDL equivalent of systemverilog.

Thanks,
Hobbyiclearner

 

[sharath666]

R u talking about a SV to VHDL convertor? I doubt it..

 

[TrickyDicky]

Yes. It's called VHDL, or system verilog.

What exactly are you trying to do. You can do many sv things in vhdl.

 

[dave_59]

For basic RTL design, VHDL and SystemVerilog are very similar as far as what synthesis tools support.

But when it comes to testbench writing (random constraint solving, functional coverage, object-oriented programming), or integrating C models with your testbench or your design, VHDL has no equivalent,

 

[SynthWorks]

Hello,

I am a basic user of VHDl and wanted to know if there is any VHDL equivalent of systemverilog.

Thanks,
Hobbyiclearner

The key capabilities SystemVerilog brings are:

• Constrained Random
• Functional Coverage
• Assertions

The OSVVM library gives VHDL the ability to do Constrained Random tests and Functional Coverage. In fact, the Functional Coverage in OSVVM is has quite a bit more capability than SystemVerilog functional coverage. One of those features is an Intelligent Testbench randomization capability called Intelligent Coverage. The library is open source and free. You can find out more at: http://osvvm.org/ and my blog at http://www.synthworks.com/blog/osvvm/

VHDL-2008 adds assertions via PSL.

SystemVerilog does not have a language based Intelligent testbench capability. A number of vendors have their own proprietary capability that they bolt on top of SystemVerilog, however, they are most certainly not free like OSVVM.

The vendors are in the process of forming a portable stimulus working group within Accellera to address to introduce a vendor independent Intelligent Testbench capability - which means for the time being, VHDL is ahead of System Verilog in that via OSVVM it already has a portable Intelligent Testbench capability.

- - - Updated - - -

But when it comes to testbench writing (random constraint solving, functional coverage, object-oriented programming), or integrating C models with your testbench or your design, VHDL has no equivalent,

Only when you ignore OSVVM. See my post on OSVVM for more.

Addressing Dave's other statements: True, OSVVM does not have a constraint solver - we have replaced the need for one by using an Intelligent Testbench approach that simplifies your over all process, and in general, reaches coverage closure faster than constrained random, and without expensive tool or tool options.

SystemVerilog does not have a language or even tool portable Intelligent Testbench capability.

True, neither VHDL nor OSVVM have OO. Functional coverage is a data structure, there is no need for OO. Since VHDL has architectures, OO does not provide any advantage in model construction (in VHDL, multiple architectures replace factory classes). As a result, we are able to use a much simpler testbench structure that is similar to RTL structure and avoids alienation of RTL engineers.

OTOH, perhaps in SV OO is an advantage since it alienates RTL design engineers and keeps them from messing up the testbench. See the blog post http://blogs.mentor.com/verificatio...stemverilog-unifying-design-and-verification/

The VHDL standards group is adding a DPI for C. So if your simulator does not already provide a way to call C programs from VHDL, they will in the future.

 

[hobbyiclearner]

OK... is there any book for OSVVM pls.

Thanks,
hobbyiclearner

 

[TrickyDicky]

The OSVVM webpage is https://osvvm.org/

 

[mrflibble]

I must say that statements like "we don't have constraints solvers because we don't need any" and "we don't have any OO going for it because we don't need any" are a bit ... novel. Why do we not need a constraint solver? And "because the testbench is Intelligent [tm]" is no answer to that. ;-) In the meantime I think I rather like the constraint solver and the amount of work it saves compared to not having constrained randomization. As for OO, who would ever want to have some extra abstraction to help reuse their IP. After all, who would ever use C++ when they can make do with just "proper use of namespaces in C"? ;-)

I think my favorite part in that blog post has to be the part where OSVVM is ~ 5x faster than SV. Because "well darn that SV, it runs testcases multiple times because of that normal distribution. Now contrast this with our awesome OSVVM, which is super handy because it will not duplicate work. And thus it is 5x faster". Interesting. So I guess by changing the relevant SV code from rand to randc I suddenly "created a 5x speedup"? Who would have guessed 5x speedups were so easy!

I realize that some marketing is required, but that apples vs cyclically randomized fruit comparison really takes the (fruit)cake.

Maybe there is something useful to OSVVM, but based on my admittedly limited reading so far (this thread + the referenced blogpost) it doesn't sound all that interesting to me. But, lets stay positive, and lets assume I just didn't understand it. Why is a constraint solver not required (without referring to marketing terms such as Intelligent Testbench, because that has zero meaning)? And why is OO a bad thing for verification? Because OO will hurt verification engineer's brains? I should hope not...

 

[SynthWorks]

Why do we not need a constraint solver?

OSVVM bases its randomization on a functional coverage model - either point or cross coverage. OSVVM does a random walk across the coverage model to randomly select the next test values to apply. You could say the coverage model and current coverage is used to solve what to do next - but it is not anything like a constraint solver.

In the meantime I think I rather like the constraint solver and the amount of work it saves compared to not having constrained randomization.

Actually you are doing more work. The intelligent coverage random walk is done by a method call (RandCovPoint - see the examples), so from a user perspective, it is no more work than SystemVerilog. OTOH, when you look at the whole process, OSVVM is less work. In SystemVerlog you write functional coverage and randomization constraints - two perspectives of the same thing. In OSVVM, we write functional coverage and use it for randomization.

And why is OO a bad thing for verification?

OO is neither good, nor bad. On the other hand, SystemVerilog marketing droids are in the habit of claiming verification requires OO. VHDL doesn't require OO to do advanced verification. Due to the marketing droid claims, it is necessary to point this out. Of course Verilog is a very different language, so perhaps to make up for its differences, it needs OO to do advanced verification.

I don't think OO is a great match for testbench models. Testbench models are fundamentally concurrent. OO is fundamentally sequential. Concurrency is created with fork and join. Objects have to be created at a correct time/phase - hence you are manually elaborating the design. OO uses factory classes to exchange one class with another to get different behavior (mark this one as a plus).

OTOH, just like testbench models, VHDL architectures are fundamentally concurrent. Connecting testbench models in VHDL uses structural code. Just like RTL code. The language already knows how to elaborate structural code, so no extra work on my part is required. VHDL uses configurations and/or compilation rules to exchange one architecture with another to get different behavior - just like SV does with factory classes.

OSVVM uses a data structure to create a functional coverage so we don't need OO to create functional coverage. Note I am not saying that it is bad that SV uses OO for this, just saying does VHDL not need it.

I think my favorite part in that blog post has to be the part where OSVVM is ~ 5x faster than SV.

Slight misquote there. By writing the coverage and doing a random walk across the coverage model, OSVVM does ~5x less iterations than a uniform distribution. Most solvers strive to have a uniform distribution.

To get a full understanding of uniform randomization (example that uses RandInt) vs Intelligent Coverage Randomization (example that uses RandCovPoint) you need to look at both examples side by side. There is very little difference between them - that is part of the point - Intelligent Coverage Randomization is simple.

Go to OSVVM.org. Download the release. Read the user guide for the full example. Try out the code. Rewrite the example in SytemVerilog if you wish.

So I guess by changing the relevant SV code from rand to randc I suddenly "created a 5x speedup"?

Apples and oranges.

Randc only tells a single object to generate all of its possible values before generating a repeat.

OTOH, OSVVM does a RANDC like randomization across all coverage bins (including cross coverage).

As for OO, who would ever want to have some extra abstraction to help reuse their IP.

Reuse pre-dates OO. Reuse works just fine in VHDL. Always has. Packages facilitate creation of utility libraries, such as OSVVM. Generics allow entities and, with VHDL-2008, packages to be parametrized. With VHDL-2008, generics can constants, types, subprograms, or packages. With these features creation of things like parametrized scoreboards is fairly straight forward.

BTW, since in VHDL we use structural code to connect our models and use concurrency in architectures that is part of the language, please don't count anything that you use either to manually elaborate your OO structure or to create concurrency in your designs as a "win" for re-use. That is just extra tedious work you have due to your chosen methodology.

 

[TrickyDicky]

My big problem with all this is the market.
You cant go ahead and use OSVVM without being considered "a bit strange" and be asked "why didnt you use SV, like everyone else".

Without some market adoption, it is very hard to convince people to stick with VHDL for verification.

 

[SynthWorks]

My big problem with all this is the market.
You cant go ahead and use OSVVM without being considered "a bit strange" and be asked "why didnt you use SV, like everyone else".

This is definitely something we need to work on.

Since there is lots of money for vendors in SystemVerilog (last I heard was at least 2X in cost, but I don't keep up on those things), they have lots of marketing. In the US, it was common for them to inject the fear, "if you don't adopt SV now, you will be looking for a job in a year."

Without some market adoption, it is very hard to convince people to stick with VHDL for verification.

I think it is more than that. OSVVM community now has over 1200 members.

I think the issue is that historically the VHDL community has not been prone to talk about their successes and methodology. Maybe, that is because it was "ho hum, just completed another successful project with VHDL." As opposed to, "I just wrestled with Verilog and finally completed the project - whew".

The last survey I saw showed that 60% of the market uses VHDL for FPGA verification.

One thing we can do is have guest blog posts for success stories on OSVVM.

 

[TrickyDicky]

I think the problem faced is that traditionally there are two problems with FPGA verification:

1. The engineers working on the firmware probably came from a hardware background, and are not software minded enough to write a decent testbench (or hated it). Also, many of peoples skills Ive seen with VHDL are not strong enough to extend into verification.

2. With FPGAs as they are, directed tests are often used to get it working with bugs ironed out later.

These are two very big hurdles to overcome (its getting better). The ASIC guys using verilog already did loads of verification already with other languages so moving to SV was just a natural progression.