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

Hi all,
Probably I got left behind myself, as I really have no idea on UVM and the
SV way of doing verification. Actually, I don't even use PSL when VHDL
actually supports it.

I agree it's getting a bit difficult when employers tend to standardise to
SV, but for me, I would rather just stick with one language than to re-learn
another language that eventually will have to compete again with VHDL-2008
or future versions of VHDL. I guess I'm just fortunate enough to find new
employment.

Anyway, can someone enlighten me on what benefits learning UVM or PSL (or
OOP-style verification) would bring me?

I guess I am still very much traditional in my verification mindset, and am
happy enough with writing bus functional models with CPU/memory-style reads
and writes between my VHDL Tester module and my VHDL DUT. I can't see any
(perhaps I don't see it yet, so please nudge me) benefit of moving towards
UVM / PSL or the like.

There are some things I wished could be done much more simply for my
testbenches though. One would be configurable entities. VHDL already
supports component configurations, but I wished I could do the same thing
for entity instantiations. Another would be to allow simulation-only
constructs to be synthesisable (perhaps interfaces could do the trick). I
can imagine a real synthesisable interface for "report" for example.
There are a bunch of others, but none of them involves moving to UVM or PSL.

Just my 2cents. Any thoughts?

Regards,
Daniel

On Sat, Apr 23, 2011 at 7:10 AM, Ken Campbell <sckoarn@storm.ca> wrote:

> 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
> VHDL.
>
> 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: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
> > Of Ken Campbell
> > Sent: Friday, April 22, 2011 12:37 PM
> > To: vhdl-200x@eda.org
> > 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 mailto:Jim@SynthWorks.com
> >> SynthWorks Design Inc. http://www.SynthWorks.com
> >> 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.