Re: [vhdl-200x] Requirements to do verification

From: Daniel Kho <>
Date: Tue Apr 26 2011 - 04:40:54 PDT

Hi all,
The Mentor survey statistics does not take into consideration many people
who did not take the survey. I for one (and I'm sure many others) do not
visit Mentor's website frequently.

From what I understand, VHDL's use is widespread in UK, Europe, and
Australia, and I believe most of the Commonwealth. Since I moved to be doing
RTL design from my previous hardware test background, the more I find myself
having to test out my designs.

Also, as I begin to write more and more testbenches, the more I feel I
haven't made use of many of VHDL's useful features. I haven't caught up with
a lot of VHDL's testbench features such as "external names" for example. In
fact, constrained randomization is already possible with VHDL (as on Jim's
website); it's just not included (yet) as a built-in library.

From a user perspective, I would like to use the same language for both
design and verification. That means, to just stick with VHDL for both. And
probably because I'm "relatively" new to design verification techniques, I
find that VHDL is good enough for everything I need.

With Jim, I also come to the belief that VHDL probably does not need UVM.
There are a lot of features in VHDL that can be used to model really great
testbenches. From the sound of it (UVM), it sounds like learning a whole new
language and methodology, when I would very much like to keep my testbench
as simple as possible.

For my current design, I am even trying to model my testbench such that it
can be both simulatable and synthesisable to hardware. Also, I plan for my
testbench to be as extensible and modular as possible (means easily entended
in future to include automated regression, artificial intelligence, etc.).
And I find myself using very neat techniques from Jim's site, and some of
Jonathan Bromley's techniques on bus functional models too (and of course
numerous others).

I also have with me a book by Peter Ashenden, and found that many of the new
and interesting testbench techniques are not yet implemented in my synthesis
and simulation tools.
Just my humble opinions.


On Tue, Apr 26, 2011 at 5:30 PM, <> wrote:

> I agree with Steve. Our experience of the market at Doulos clearly shows
> that SystemVerilog is now #1 for functional verification and is still on the
> rise. While I remain a firm fan of VHDL as a language, and am sure VHDL
> will continue to be used for years to come, and while I would put many
> caveats around the use of SystemVerilog as a language, I believe the
> interests of the VHDL community would be best served by acknowledging the
> commercial reality that SystemVerilog now dominates in the constrained
> random verification space, and exploring ways in which VHDL could
> interoperate with UVM in SystemVerilog rather than attempting to increase
> the expressive power of VHDL such that UVM could be "implemented within
> VHDL" at this stage.
> (As an aside, we have started to teach ways in which people can construct
> UVM-inspired verification environments in VHDL as it stands, easing
> interoperability with SystemVerilog environments and most importantly with
> Respectfully,
> John A
> From: "Bailey, Stephen" <> To: "
>" <> Date: 24/04/2011 16:30 Subject:
> RE: [vhdl-200x] Requirements to do verification
> Sent by:
> ------------------------------
> Ken,
> UVM cannot be implemented in VHDL today. At best, an interface from UVM TB
> to a VHDL design could be defined. However, changes to VHDL are not
> required in order for VHDL users to benefit from SV and UVM. All vendors
> support SV and VHDL mixed simulations. Languages are tools. VHDL designers
> have the same verification tools available to them as Verilog or
> SystemVerilog designers.
> I disagree that VHDL must be enhanced in order to support UVM. There are
> no technical barriers preventing VHDL users from using UVM today; they only
> need be willing to use SV as a language for verification. Providing UVM
> capabilities in VHDL does not advance technology for verification. It is
> solving the same problems for the 9th time (e, Vera, Superlog,
> SystemVerilog, AVM, RVM, OVM, UVM). If the effort to do so was equivalent
> to painting the handle of a screwdriver a different color, there would be no
> discussion. However, the reality is that the effort required will be many
> man-years of effort in the standards committee followed by at least 10x that
> level of effort for EACH vendor to implement & support it. And, at the end
> of the day, VHDL users will be able to do the same thing that they could do
> today, just in a different syntax.
> There are real new and emerging verification challenges that need to be
> addressed. Throwing such a massive amount of resources at forging (not
> inventing as there is no new technology) the 9th version of the same wheel
> is an irresponsible waste of resources.
> The future of VHDL is determined by the market (the aggregate of decisions
> made by individuals and individual corporations/entities). Harry Foster has
> been reporting on the Mentor's blog the results of our blind survey of the
> verification market. In that survey, it is very clear that all languages
> are on the decline except SystemVerilog which is being adopted at an
> unprecedented rate and SystemC (as well as C/C++) which are relatively
> stable in usage. I reported the preliminary (North America only) data to
> this email list previously. Here's the world-wide data (languages used in
> verification):
> VHDL: 27% in 2007, 21% in 2010, 16% projected this year
> Verilog: 68%, 53%, 47%
> Vera: 11%, 8%, 3%
> SystemC: 17%, 16%, 19%
> SystemVerilog: 24%, 60%, 74%
> e: 16%, 15%, 11%
> C/C++: 30%, 35% and 32%
> Other: 5%, 3%, 2%
> I have already pointed out the question of market timing/window. SV
> incubated for years in Accellera (5-7 years) before emerging as a viable
> standard. And, that was with the benefit of a precursor to use as the
> foundation (Superlog). My company must have 100+ man-years in building and
> maintaining SV tooling and the AVM/OVM/UVM methodologies.
> To answer your question: The purpose of specifying new language features
> is to provide value that addresses market (user) needs. The purpose of a
> business undertaking any effort to support language standardization efforts
> and the consequential R&D and marketing effort to create products based on
> that standard is the ability to earn a return on their investment. If it
> were your millions of $'s to spend, could you justify spending it on VHDL
> language changes that address a declining niche in the market WITHOUT
> providing any compelling value over existing solutions available to that
> market? NOTE: e and SV already have significant footholds in the VHDL market
> so that 16% will continue to decline.
> Or would you look to invest that money solving problems that have yet to be
> solved that could give you competitive advantage and target a larger market
> (if the problems have yet to be solved, you have 100% of the target market
> available)?
> It is not an unknown effort to add these capabilities to a new language.
> We know the cost will be very high. Several man-years over several years
> is not an exaggeration.
> This group is self-selecting and they have a lot of passion for VHDL. I
> entered the EDA industry via VHDL (I worked at Intermetrics which defined
> the language). I chaired the 1076 group for ~4 years. However, if I
> attempt to evade reality and try to live in a fantasy world, I will get
> fired because I will not be defining solutions that the market needs AND my
> employer can make money delivering (aka, I will be a failure). Therefore, I
> cannot allow my sentimental attachment to VHDL distort the objective
> reality.
> If I were an unemployed verification engineer who saw the above survey
> data, I would be doing everything possible to learn SV and UVM. After all,
> you are your own businessman. There is a market that you are targeting.
> Are you offering value that employers want? 3 out of 4 employers want
> SV/UVM verification skills. About 1 in 3 to 5 want SystemC and/or C/C++.
> Less than 1 in 5 (and declining) are looking for VHDL verification skills.
> You would be hard pressed to find a more compelling set of data related to
> career decisions.
> -Steve Bailey
> -----Original Message-----
> From: [<>]
> On Behalf Of Ken Campbell
> Sent: Friday, April 22, 2011 5:10 PM
> To:
> Subject: RE: [vhdl-200x] Requirements to do verification
> Steve,
> Correct me if I am wrong, but the UVM method is based on a library written
> in SystemVerolog. UVM is a product of 5 or more years of practical use.
> It is a collaboration of several methodologies implemented with an OOP,
> SystemVerolog. I would expect someone to create a C++ or SystemC version
> of UVM eventually.
> But the way VHDL is today, there is not much chance of making a
> verification environment that looks and feels like a UVM SystemVerolog
> environment. Not in an employers eyes anyway, I personally can derive
> similarities, but it is not OOP.
> The extensions being considered to VHDL, like those defined in White paper
> by Peter Ashenden, I would hope would enable a library to be created that
> could be based on UVM. Though this may be some time in the future, and
> UVM may change, the language extensions should be made so that VHDL can
> continue provide the facilities users need or think they need. Is it the
> purpose of specifying new language enhancements to sway usage? What is
> considered the future of VHDL as a language? Is that determined by user
> base, the tool vendors or the standards community?
> I think there is an advantage to building on market success, and SV has
> been successful. VHDL seems to be lagging other languages when it comes
> to OOP. I can understand this as, thankfully, as VHDL is a strongly typed
> language. Waiting to put OOP capabilities into VHDL will not benefit
> anyone. The implementation of OOP in languages is not new, so after a
> standard is created, it should not be a huge unknown effort to implement
> in tools. VHDL has a huge user base, I am sure OOP additions would be
> adopted and used as soon as they became available. I would think that
> users would create the UVM library for VHDL, there are many that like
> I have looked over the UVM Class Reference Manual 1.0 and really do not
> see why things have to be so complicated. There must be some reason for
> it all or it would not be so successful.
> So I guess what I am suggesting is that VHDL be specified to enable what
> ever the methodology of the day is, whether that be common or special, to
> be implemented using modern techniques.
> I hope that answered your questions.
> Ken
> > Ken,
> >
> > Sounds like you have identified what the (job) market needs.
> >
> > What's the smart thing to do? Create a product that the market needs?
> >
> > Or convince the market that it doesn't need what it thinks it needs,
> > instead it needs something else? If so, what does that something else
> > offer that gives it significantly more value than what the market knows
> it
> > requires?
> >
> > And, consider market windows. Will your superior offering gain market
> > acceptance if it is delivered 5 years from now? Will the inertial
> > barriers to entry be too great by then or will the creator of that
> > speculative product go bankrupt first?
> >
> > -Steve Bailey
> >
> > -----Original Message-----
> > From: [<>]
> On Behalf
> > Of Ken Campbell
> > Sent: Friday, April 22, 2011 12:37 PM
> > To:
> > Subject: Re: [vhdl-200x] Requirements to do verification
> >
> > Hello everyone,
> > As an answer to the question.
> > I think the additions to VHDL should enable the implementation of a "look
> > and feel" of UVM. Initially the target should be the objects that
> provide
> > the most value to a verification environment. Like some kind of subset
> of
> > UVM that would enable the most important verification tasks to be
> > automated, basic building blocks and interfacing...
> >
> > The reason I say this is because there is a wave of SV usage. I
> currently
> > can not get employed because I do not have experience with any SV
> methods,
> > but have been doing verification for 15 years now. I got left behind
> > using a VHDL test bench system I published on OpenCores. Now after 3
> > months, at least 10 ASIC/FPGA verification jobs have gone by because of
> my
> > lack of specific verification tool methods / language.
> >
> > So, to improve the chances of cross employment and standardization for
> the
> > future of verification people, I recommend a UVM methods implementation
> as
> > a target for VHDL language enhancements.
> >
> > As Jim said, VHDL is very capable and very much alive. I have recently
> > started a blog describing how to best use the VHDL test bench package I
> > published. This has increased the downloads from 1-3 per day to 4-7.
> The
> > blog is getting more attention than I thought it would and for me that is
> > evidence that VHDL is very much alive.
> >
> > Is this the kind of input you were looking for?
> >
> > Regards,
> > Ken Campbell
> >
> >
> >> All,
> >> If we are to make VHDL a viable verification language,
> >> what features do we require?
> >>
> >> I am thinking the main ones are functional coverage,
> >> randomization, data structures (ie: scoreboards,
> >> memories, fifos, ...) and interfaces.
> >>
> >> While I realize some have expressed concern about a language's
> >> ability to be suited for both design (RTL and above) and
> >> verification, I am not sure I agree. I think a frugal
> >> implementation of all of the above is possible.
> >>
> >> The more I work with VHDL the more I am impressed by the
> >> capability.
> >>
> >> Best,
> >> Jim
> >> --
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> Jim Lewis
> >> Director of Training<>
> >> SynthWorks Design Inc.<>
> >> 1-503-590-4787
> >>
> >> Expert VHDL Training for Hardware Design and Verification
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >> --
> >> This message has been scanned for viruses and
> >> dangerous content by MailScanner, and is
> >> believed to be clean.
> >>
> >>
> >
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> >
> >
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <>, and is
> believed to be clean.

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue, 26 Apr 2011 19:40:54 +0800

This archive was generated by hypermail 2.1.8 : Tue Apr 26 2011 - 04:43:52 PDT