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

Hans,
Agreed. I think it's possible for us to get together and discuss about how
to further brighten the already bright future of VHDL?

Regards,
Daniel

On Tue, Apr 26, 2011 at 11:58 PM, hans@ht-lab <hans64@ht-lab.com> wrote:

> Can I also suggest we stop mentioning direct or indirectly the demise of
> VHDL, I really don’t understand what the point is of this. We are a group
> that likes to promote and enhance VHDL any way possible, right?
>
> Regards,
> Hans.
>
> *From:* ben cohen <hdlcohen@gmail.com>
> *Sent:* Tuesday, April 26, 2011 4:41 PM
> *To:* vhdl-200x@eda.org
> *Subject:* Re: [vhdl-200x] Requirements to do verification
> I cannot give you exact statistics, but I see in the US, organizations
> that use VHDL who have first transitioned to mixed-mode to benefit from the
> usage of OVM for verification (i.e., RTL in VHDL, verification in
> SystemVerilog). However, that meant training and maintaining 2 languages.
> Since VHDL and SV structures are not that far off for RTL (if you follow the
> right methodology), they are abandoning VHDL for new designs. That trend is
> also driven by costs because of tool licensing and training. It is offset
> though by the increase in training costs for OVM; but they felt that OVM is
> superior to what they had before in the design of their testbench in VHDL,
> and thus the total switch.
> Ben Cohen
>
> On Tue, Apr 26, 2011 at 8:21 AM, Daniel Kho <daniel.kho@gmail.com> wrote:
>
>> Hi Steve,
>> I'm not sure if it's appropriate to discuss the survey results here, but
>> well, let me know if it isn't and I'll discontinue. Anyway, here is what I
>> think about the results (others will have differing opinions of course).
>>
>> I'm just looking at "Verification Language Adoption by Region", and only
>> comparing VHDL, Verilog, and SV here. From the graph, I conclude the
>> following:
>> 1. That VHDL usage in North America is pretty strong, closely comparable
>> to SV, but Verilog usage is quite a bit higher.
>> 2. In Europe/Israel, VHDL usage is the highest, even higher than Verilog
>> and SV.
>> 3. SV wins in Asia and India by a huge margin.
>>
>> Referring to Point #3, I agree that SV has been widely adopted especially
>> in Asia (where I am currently), and I am beginning to feel it's getting more
>> difficult to get VHDL jobs.
>> However, it isn't too bad, as I can still manage to be employed. Consider
>> myself lucky (or whatever), but I also get to pick my employer though the
>> same can be said in reverse. I have declined a few Verilog-only jobs as I
>> refused to adopt other HDL languages. Since my college days, I'm stuck with
>> VHDL, and I'm happy that I stuck to it.
>>
>> There are a few interesting points to consider:
>> 1. In one of my employments, our counterpart design centre was based in
>> Europe, and so again I was happily designing in VHDL.
>> 2. I see more and more European companies following the past success of
>> American companies in Asia, where they begin to set up their design centres
>> in Asia. This means, I would predict more VHDL usage in future for Asia.
>> 3. There are still a number of North American companies in Asia who prefer
>> to use VHDL.
>> 4. Many Asian companies have been supporting the American market (I still
>> see more American companies than European/other companies in my place). That
>> could be the reason behind why Verilog is so widely adopted. However, as
>> mentioned, things could change for the better for VHDL when more European
>> and North American companies set up their plants in Asia.
>>
>> Regards,
>> Daniel
>>
>>
>> On Tue, Apr 26, 2011 at 10:25 PM, Bailey, Stephen <
>> stephen_bailey@mentor.com> wrote:
>>
>>> The Mentor survey was not done via Mentor’s website. It was
>>> commissioned to a firm which does these types of things. If people came to
>>> the Mentor website to do the survey, it could not be a blind survey.
>>> Participants did not know who commissioned the survey.
>>>
>>>
>>>
>>> Facts are facts whether you like them or not.
>>>
>>>
>>>
>>> -Steve Bailey
>>>
>>>
>>>
>>> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On
>>> Behalf Of *Daniel Kho
>>> *Sent:* Tuesday, April 26, 2011 5:41 AM
>>>
>>> *To:* vhdl-200x@eda.org
>>> *Cc:* owner-vhdl-200x@eda.org
>>>
>>> *Subject:* Re: [vhdl-200x] Requirements to do verification
>>>
>>>
>>>
>>> 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.
>>>
>>> Regards,
>>> Daniel
>>>
>>> On Tue, Apr 26, 2011 at 5:30 PM, <john.aynsley@doulos.com> 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
>>> UVM VIP.)
>>>
>>> Respectfully,
>>>
>>> John A
>>>
>>>
>>> From:
>>>
>>> "Bailey, Stephen" <stephen_bailey@mentor.com>
>>>
>>> To:
>>>
>>> "vhdl-200x@eda.org" <vhdl-200x@eda.org>
>>>
>>> Date:
>>>
>>> 24/04/2011 16:30
>>>
>>> Subject:
>>>
>>> RE: [vhdl-200x] Requirements to do verification
>>>
>>> Sent by:
>>>
>>> owner-vhdl-200x@eda.org
>>>
>>>
>>> ------------------------------
>>>
>>>
>>>
>>>
>>> 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<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<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<Jim@SynthWorks.com>
>>> >> SynthWorks Design Inc. http://www.SynthWorks.com<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* <http://www.mailscanner.info/>, 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* <http://www.mailscanner.info/>, 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* <http://www.mailscanner.info/>, 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.