Can VHDL be used for "functional coverage"? Why not?

An article states that

"While functional coverage is provided in Vera, Specman and SystemVerilog; languages such as VHDL and SystemC have neither an inherent support for functional coverage nor a well defined methodology to facilitate it."

It states that "functional coverage is used to check that all important aspects of the design are tested while perceiving the design from a user or system point of view"

Now how is it that VHDL does not support functional coverage?

Because it doesnt have the libraries or language capabilites to facilitate it. You will have to manually check the data to ensure all data points are covered.

There is the OSVVM library (osvvm.org) to try and address these problems, but it is not very widely used (it's trying).

There is no reason that VHDL couldn't have been enhanced to support these features, it's just that the EDA industry does not have the resources to support multiple verification languages. It takes a lot of engineering resources to develop, train, support and maintain the tools for each language, as well as the supporting infrastructure like Verification IP. SystemVerilog was created to consolidate all these environments into one language.

You can certainly write code in VHDL or Verilog to capture functional coverage data, but it would not be very efficient. There can be an lot of data generated by functional coverage "binning" that would be scattered throughout the design and testbench. SystemVerilog makes it easy to describe and collect this data, optimize once coverage has been obtained, and provide tool control over reporting and debugging this data.

Since we are moving towards ever complex designs year after year, does this not mean that since SystemVerilog with its advanced capabilities for verification is fully capable of functional coverage, we should now only emphasize SystemVerilog which can be used for synthesis as well as verification and do away with VHDL?

Also, since SystemC was also created for verification and I have read that it is very powerful tool for SoC verification with software and hardware components in the design, how come SystemC also does not have ability to carry out functional coverage?

My third and last question, are the concurrent assertions as exist in SystemVerilog, all that is needed to carry out functional coverage?

Thank you very much for your answer.

1st Q: a) Synthesis tools don't support SV as well as they do verilog or VHDL. b)Most designs have already been done in verilog/vhdl. They will mostly be reused rather than recoded in SV.

It is perfectly valid to do your design in VHDL and verification in SV. There is a lot of legacy VHDL out there that still works just fine, so why not re-use it.
SV support is there in Xilinx and Altera tools. But is less mature than VHDL

At least weeks, DVCon, two VHDL users, PMC Sierra and Qualcomm presented their experiences migrating from VHDL to SystemVerilog. The biggest hindrance to this migration has been synthesis tool support, especially in the FPGA market, but that gap has been steadily shrinking. These tutorials will be available online shortly.

SystemC was originally developed for modeling hardware in a C++ software development environment. It is especially good at modeling algorithmic based designs like signal processing. By using fixed point libraries, you can model these at a very high level of abstraction and still readily synthesis into hardware. The high level of abstraction makes it practical to integrate hardware and software in the same simulation. But once you need to get down to lower levels of abstraction, you lose that performance advantage regardless of the chosen language.

Later versions of SystemC did add some verification extensions, but not in the area of functional coverage. One of the benefits of SystemVerilog over SystemC in verification is that SV is a complete language that can be optimized for particular applications. SystemC is just a library of macros and routines that would require a lot of user knowledge behind these applications to optimize. This is the same problem using the current VHDL has.

To answer your third question, assertions are one of two mechanisms used to collect functional coverage in SystemVerilog. The other one is covergroups. Assertions are mainly used to collect temporal or protocol based functionality, whereas covergroups are used to collect different data values, like the kinds of operations performed . You may want to take a look at our Coverage Cookbook.

But clearly SV wasnt good enough on its own, else UVM wouldnt have been created.

TrickyDicky said:

But clearly SV wasnt good enough on its own, else UVM wouldnt have been created.

Click to expand...

You could say that about any programming language - they all have libraries and associated best practices associated with them.

Re: Can VHDL be used for "functional coverage"? Why not?

TrickyDicky said:

There is the OSVVM library (osvvm.org) to try and address these problems, but it is not very widely used (it's trying).

Click to expand...

The OSVVM community has grown beyond 1200 members.

OSVVM's functional coverage capability is quite good. WRT to cross coverage, it is likely some what more capable than SystemVerilog.

In addition to seeing OSVVM.org, downloading the release, and reading the user guides, you can also read my OSVVM blog at:
https://www.synthworks.com/blog/osvvm/

We also have an Advanced VHDL Testbenches and Verification class that focuses on OSVVM. Class is available, on-line, on-site, and at public venues (US, Europe, and ASIA is coming soon).

Of course, if you listen to many EDA vendors, they want you to believe that SystemVerilog is the only thing for verification since they make much more money from SystemVerilog.

If you are following Accellera, you will see them working a Portable Stimulus Working group. This group is focusing on an input format to do intelligent testbenches, which is the next step after constrained random testbenches. One notable thing is the format is not SV, it is something new. I bring this up because, OSVVM already supports a simple form of Intelligent Testbenches - and the format is all VHDL + packages, so it is already portable between vendors.

So if you want portable, next generation capability, VHDL + OSVVM already has it, and, since it is part of the packages, it is free.

- - - Updated - - -

matrixofdynamism said:

Since we are moving towards ever complex designs year after year, does this not mean that since SystemVerilog with its advanced capabilities for verification is fully capable of functional coverage, we should now only emphasize SystemVerilog which can be used for synthesis as well as verification and do away with VHDL?

Click to expand...

VHDL for RTL, and VHDL + OSVVM for verification will do just fine.

If you switch to SV, expect to pay more and re-write all of your verification IP.

dave_59 said:

There is no reason that VHDL couldn't have been enhanced to support these features, it's just that the EDA industry does not have the resources to support multiple verification languages. ...

Click to expand...

During the VHDL-2008 language revision, I look into what it would take to add Functional Coverage as language syntax to VHDL. Unfortunately, if we did a "me too" implementation of what SystemVerilog, it would require OO constructs (which VHDL almost has in Protected Types). We, the working group, decided to postpone implementing OO, so functional coverage as a language feature was shelved.

After this and separately, I started experimenting with packages to do prototypes of what I thought the features could be. These prototypes evolved and eventually became OSVVM (see osvvm.org). After years of revisions (starting in 2010), I realized that packages are as good as or better (in capability and conciseness) than what other verification languages support using language syntax. Particularly for cross coverage. Particularly since in OSVVM each model can support a different coverage goal for each item in the model - this becomes very important since we also use the coverage goals as randomization weights when doing Intelligent Coverage Randomization (A Intelligent Testbench methodology built into our coverage modeling).

dave_59 said:

It takes a lot of engineering resources to develop, train, support and maintain the tools for each language, as well as the supporting infrastructure like Verification IP..

Click to expand...

Agreed, especially when adding language features. OTOH, with OSVVM, we have added functional coverage, constrained random, and intelligent testbenches to VHDL using open-source packages, hence, avoiding the cost to vendors. Vendors simply need to support enough of VHDL-2008 to implement the library.

Not only have vendors implemented enough of VHDL-2008 language features, but both Aldec and Mentor also release pre-compiled OSVVM libraries with their tools. Kudos to them.

OSVVM is free. Currently the required VHDL-2008 features are trivial ones. The harder requirement is actually VHDL-2000/2002, protected types.

There is alot of market pressure for you to switch to SystemVerilog. This is because as @Dave_59 mentioned, vendors have made a huge investment in SystemVerilog and need to recover this investement in the form of more expensive SystemVerilog tools. If you follow them, be sure to understand the complete range of costs first.

Can VHDL be used for "functional coverage"? Why not?

Click to expand...

So while VHDL does not support functional coverage, the OSVVM libarary adds it in a form that is as concise as most language syntax.

What is troubling is that many vendors answer this question directly, no VHDL does not, and then lobby you about SystemVerilog, conveniently forgetting about OSVVM. This is just like making claims about SystemVerilog and ignoring UVM - it is just non-sense.

Hence when you ask about VHDL and Functional Coverage, the real question to ask your vendor is whether they support OSVVM or not.

P.S. If you are a vendor working on supporting OSVVM and need a small tweak to the library (other than protected types) to get OSVVM working in your simulator, give me a shout (jim at synthworks.com) - I am open to making sure OSVVM is supported by a wider range of simulators.

I think there are language feature limitations currently that still prevent full exploitation of VHDL as a full on verification language, namely:
1. Cannot have arrays of protected types.
2. Cannot pass access types into/out of a protected type (though this may be a good idea to maintain atomic access).
3. Generic packages cannot have variables in them. Packages can only contain variables when declared in a context that variables can be declared. This severly limits package usefulness in re-use (mentor do not have support for this feature, and it is not on their roadmap for support any time soon - probably because it is fairly useless. I have seen the example in the 2008 features book, and while it is clever, I want to be able to re-use code like this).

Also, proper language defined support for binary file access would also help. Having to access a binary file via the char type is not portable as some simulators can behave differently.

TrickyDicky said:

I think there are language feature limitations currently that still prevent full exploitation of VHDL as a full on verification language, namely:
1. Cannot have arrays of protected types.
2. Cannot pass access types into/out of a protected type (though this may be a good idea to maintain atomic access).
3. Generic packages cannot have variables in them. ...
4. Also, proper language defined support for binary file access would also help. Having to access a binary file via the char type is not portable as some simulators can behave differently.

Click to expand...

TrickyDicky,
1 & 2 already have proposals for VHDL-201X. Be sure to fill out a priority sheet and rank them high if you need them. I find it particularly painful without 1. It would allow me to do a registration layer for coverage modeling. It would also simplify my indexed scoreboard model (currently done using arrays of arrays that are dynamically sized and allocated).

3 is a bug. Did you report it? Be sure to speak to the person who is purchasing tool licenses to prioritize your language support requests. OTOH, protected types allow internal variables - what are you trying to create? Local instances of generic packages would also make a very simple transaction interface.

For 4, it would be helpful if you filled out a VHDL working group TWIKI that characterize what you think should be happening and what different simulators are doing. Is this a tool bug or a language issue? If you don't have TWIKI access, send me an email at jim at synthworks dot com.

Jim

SynthWorks said:

3 is a bug. Did you report it? Be sure to speak to the person who is purchasing tool licenses to prioritize your language support requests. OTOH, protected types allow internal variables - what are you trying to create? Local instances of generic packages would also make a very simple transaction interface.

Click to expand...

If its a bug, its an LRM bug. You cannot have variables (not shared variables) in a package unless it is declared inside a scope that accepts variables (process/function/procedure). This is an LRM rule. This means you then cannot reuse the package, because you cannot see the package outside of the process/function/procedure. You can have shared variables, but this then means you cannot create an instance of the package inside a process/function/procedure scope.

In your book, you have example where you create a package inside a process to do scoreboarding. This is a nice example, but has no re-use value, which makes it fairly useless IMO.