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

Ken,
A few comments:
1) On the chicken or the egg, there are in India places called "incubation
centers" that provide in-depth training in verification, along with
practical applications. These centers are different than the 2 or 3-day
training classes. I don't believe that there are such places in the US.
Another way to break this chicken or the egg battle is to get an in-job
training, possibly by accepting a lower level position with the
understanding that you'll be getting into the verification aspect.

2) On VHDL / SystemVerilog, the two have many similarities and differences,
making it relatively easier to learn when you know VHDL, but also harder
when the user has no object-oriented experience. SystemVerilog borrowed
many concepts from VHDL, like packages, records. However, companies that
joined Accellera foresaw the need for assertions, constrained-random
verification, and software concepts into the verification process. On
assertion, SVA was created, and that resembled (and borrowed concepts) from
PSL. On constrained-random verification, a set of constraint declarations
was defined. On software concepts, OO stuff (e.g., classes) were defined.
 The point I am making is that there is a lot to learn to use SystemVerilog,
and it's more than just the syntax. Not to make things more complex, but
VMM/OVM/UVM added another layer of software to create a framework, thus
creating even more things to learn.
I also agree that if one learns all that stuff, but does not actively use
it, one tends to easily forget it - it's the old saying "use it or lose
it".

3) On why SystemVerilog tools are not free, it's because it takes a lot of
effort to make the simulator, and products are made using those tools (e.g.,
chips used in products). Thus your assertion "*Its not like SV can produce
“product”, like other languages can, why not open it up?"* is false. There
is nothing that limits anyone to make a GNU simulator though; however, none
exists as of today.

4) On making VHDL look like SystemVerilog, I totally agree with all of
what Steve
Bailey said.
Ben Cohen SystemVerilog.us

On Sun, Apr 24, 2011 at 12:58 PM, Ken Campbell <sckoarn@storm.ca> wrote:

> I understand what I have to do, learn SV to continue being Verification
> person. I have had some problems finding “free” solutions that would
> enable me to practice. It seems all the free tools do not give you SV,
> just Verilog and VHDL. So the problem is, all employers want 2-3 years SV
> and UVM ... Few will give you a chance if you stated you read the UVM
> LRM. Even if I stated I read all the examples on all the tutorials on the
> web, that does not equate to coding. So how would you suggest I get
> practical experience, that would enable me to transition, when no vender
> enables free usage? Sounds like a closed club to me. If SV is so
> awesome, and you want to promote its use, why can't everyone and anyone
> use it? Microsoft can produce and distribute the “Express” versions of
> its software tools, why can't the EDA industry do the same? Its not like
> SV can produce “product”, like other languages can, why not open it up?
>
> While all those nine iterations of improvements to languages and methods
> were going on, why was VHDL not updated also. Was this because of user
> base worldwide? Or was this because a powerful tool provider shaped
> things in its own vision?
>
> I know that UVM cannot be implemented in VHDL today, as it is my only HDL
> that I can code confidently. I have verified what I believe are very
> complicated designs using VHDL and a little SystemC. I know the
> challenges of verifying complicated designs.
>
> Are you saying that no effort should be put into VHDL standards that would
> further enable verification capabilities of the language? That all VHDL
> coders and verification people should just switch to a new language for
> verification?
>
> I am not sure I understand the numbers in your chart. I see the decline
> and the incline in SV, but the addition of all the percentages is much
> more than 100% for any given year.
>
> I have been a user of tools for verification for some time now, and I have
> seen how tool vendors chop up the features and charge for every one of
> them. I know why tool venders produce tools.
>
> I am sorry if these are not the kind of discussions take place on this
> reflector and if in fact this has gone off topic. I am a new participant.
> As a VHDL user, I was thinking that if VHDL could be altered so that a
> UVM framework could be implemented, then the qualifications for a
> verification person would be language independent. Of course I did not
> expect any language changes to fix my current problem, as stated,
> implementation is years away.
>
> Cheers
> Ken
>
>
> > 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: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
> > Of Ken Campbell
> > Sent: Friday, April 22, 2011 5:10 PM
> > To: vhdl-200x@eda.org
> > 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
> > 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.
> >
> >
> >
>
>
>
> --
> 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.