RFC: Enhancing VHDL for OO, Randomization, Functional Coverage

Hi, The VHDL standards community needs feedback from VHDL users.

Currently the Accellera VHDL TSC is working on enhancements to add classes/OO, Randomization constructs, and Functional Coverage with a goal of giving VHDL the same verification capability as SystemVerilog or E.

One of the VHDL simulation vendors has indicated that they only want to implement new features if the user community wants these features.

The questions come down to: Do you want these features added to VHDL? Do you want to VHDL to be capable of handling all of your testbench needs?

This work is work in progress and below is the current status. Keep in mind too that your interest/support of this work will help raise the focus and inspiration of those doing the work.

Classes / OO: Peter Ashenden submitted a class proposal last year and provided updates to it this year at DVCon. Currently he plans on finishing an updated draft soon.

Randomization: I just submitted the first draft of the randomization proposal.

Functional Coverage: I have started working on this - anyone else who is interested is welcome to contribute as much as they would like.

With a focused effort, like the one to finish the Accellera 3.0 draft of the standard, I think we can be done with these by September.

Although some have expressed doubt, it is clear that vendors will do what their user community asks them to do - otherwise, someone else will and, as a result, will earn your business.

You can post here, send your reply to me (let me know if I can use either your name and/or company name when I tally the results for the Accellera VHDL TSC), or join the Accellera VHDL TSC (which you can do as a non-Accellera member by registering) and post your reply there.

Thanks, Jim Lewis VHDL Evangelist SynthWorks VHDL Training

Reply to
Jim Lewis
Loading thread data ...

I have been a long time for Classes/OO, Randomization and Functional coverage that is already part of SystemVerilog. VHDL is my favorite HDL and I think it has always had very high-level constructs ahead of its time. The VHDL-2006 is a much needed update, but still comes short of the features that SystemVerilog boasts for verification. I think Classes/OO is great for synthesis as well and brings the language to higher abstraction level that is already enjoyed by software developers.

It is a shame that (big) vendors are pushing SystemVerilog and think that there is not enough customer base for VHDL. I beg to differ and have be anxiously waiting for VHDL update and OO, verification extensions.

I do not want to start language wars, but take a good look at table on page () of the following article and you would agree that VHDL has been at higher-level of abstraction than Verilog.

formatting link

Verilog is still good for gate-level descriptions and with Verilog

2001 extensions they brought it up to par with VHDL, and then SystemVerilog extensions added more features to get market share from Verisity and E supporters by pushing a supposedly standard driven language. Although we all know the big vendor influence.

I hope these proposed features and the good works of Peter, Jim and other drivers of this great language is not taken for granted.

-- Amal

Reply to
Amal

And I guess mti won't support these features with Modelsim, to force Questa sells, like it is with SV. This might be a major issue when it comes to market usage.

Don't know if OO-update is a good idea to a language, but we will see. C++ is not the best idea for OO IMHO because it relays to much on procedural statements. VHDL has no choice, when it comes to procedural statements.

But I would realy appreciate, if vdhl would support built-in "modern" assertions like PSL or e.

Yes I like VHDL to be enhanced for tomorrows tb needs. I am currently working on a design, with included ADC. I have the netlist with ADC as blackbox for some purpose, the netlist with behavioral model for other purpose. In some cases I need to use another library element for a digital gate, than normal. Netlist and and one testbench are verilog and it is a pain to select the corresponding tb-gtl-library settings without configurations(is no porblem using configurations).

bye Thomas

Reply to
Thomas Stanka

I just started with VHDL two months ago and I have to say that I find it frustrating that I keep running into unimplemented parts of the VHDL standard. That's with the Xilinx toolchain and I read a lot of that already that I can confirm. A few days before I tried to model a ADC wrt. the timing constraints and had to notice that the Xilinx ISE Simulator (non ModelSim :() does not support the stable attribute.

Okay, enough of the rant, what I wanted to say is that I'd expect the implementations to conform to the standard.

I'd really like to see that proposal. Coming from software development it really seems logical to apply OO to HDLs.

Also very interesting, we will need pseudo random data for our project as well. Some kind of LFSR will be good enough but having it directly supported would be nice, also for synthesis. I can dream, right :)

While I am just starting with VHDL, I'd like to contribute. In fact, I became member of IEEE-SA just for that. I figured following that discussion would also be the best way to learn VHDL, just as my involvement with Debian GNU/Linux as a developer was a real boost for my Linux know how. However, I don't think my company is interested in spending money and developer time on it so I could only use my spare time for it.

Greetings, Torsten

Reply to
Torsten Landschoff

Hi Jim,

I just noticed that I did not really answer your questi> The questions come down to:

Yes, classes/OO would be very welcome.

Same for randomization.

Everybody should want coverage tests as it is important for correctness. I am not sure though how this will require language changes?

And of course I'd like to use only VHDL for our test benches. Tcl and VHDL kind of works but is not as portable and standardized.

Greetings, Torsten

PS: I am working for nAmbition GmbH but any opinions given above are my own. Feel free to use my name.

Reply to
Torsten Landschoff

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.