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

Some comments:
*PSL*: PSL is an assertion language, and has nothing to do with UVM, which
is a framework for verification. Yes, PSL or SVA should be used in the
design and verification process because they 1) clarify high level and
interface requirements for use in the RTL design process, 2) clarify
detailed design intent, 3) use a shorthand type notation to express FSMs,
something that can be done in straight VHDL code, but is more complex.
 Those who have used an assertion language have found significant benefits
as it not just clarify intnet, but they also quickly identify bugs. An
assertion language can also be used in formal verification. Thus, Daniel, I
strongly recommend that you use PSL.

 *Requirements for verification:* In terms of priorities, the most valuable
feature that SystemVerilog added is constrained random value generation,
item 18 of 1800.
This (item 18) clause describes:
— Random variables
— Constraint blocks
— Randomization methods
— Disabling randomization
— Controlling constraints
— Scope variable randomization
— Seeding the random number generator
— Random weighted case statements
— Random sequence generation

This is what VHDL needs. The OO stuff and classes is neat because one can
extend classes (e.g., add more *rand* variables and tasks) and randomize
objects of a class instance with the *randomize* function. In terms of
priority, I feel that the constrained randomization is higher priority than
classes, but there must be way to randomize *rand *variables in block,
meaning those declared in some unit; SystemVerilog did it with classes, but
maybe VHDL can do it in packages? Can packages be extended? In the past
many years, I migrated toward SV and have not really kept up with VHDL; but
I am just throwing ideas.

Ben Cohen SystemVerilog.us

On Fri, Apr 22, 2011 at 11:26 PM, Daniel Kho <daniel.kho@gmail.com> wrote:

> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.