*I am actually somewhat surprised that nobody else commented on Steve email,
am I the only one that read a very negative SV/Vendor biased response? If
you read his comments then what he is basically saying is that we should all
ditch VHDL and move to SystemVerilog since there is only room for 1
high-level verification language. If there was only one programming language
in the world we would have no innovation (and yes I understand the
advantages as well).*
[Ben] I agree with what Steve said, and this is because you can basically
say that the VHDL design and verification language set is included in
SystemVerilog. Thus, if you stick by simple design rules you can easily
translate VHDL into SystemVerilog code. SystemVerilog introduced other
constructs targeted for verification. There is a strong momentum in the use
of SystemVerilog, and there are real issues for both the vendors and the
users in adopting a catched-up version of VHDL a la SystemVerilog.
Specifically, for the user, the issues are:
- Support and maturity of the new constructs. What are the risks in early
adoption?
- Support and maturity of frameworks, a la VMM/OVM/UVM, which are gaining
standardization and popularity.
For the vendors, he has issues also:
- Enough rewards (or sales) for the design and support of this new standard
that looks very much like SystemVerilog? If the differences are basically
syntactical, it is really not worth it to make the changes. As far as the
difficulty for VHDL users to transition to SystemVerilog because of syntax
(e.g., the ";" and location of type definitions in the declarations), I see
this as an American learning how to drive in the UK with a car that has the
steering wheel on the left side of the car. At first it feel odd, but we
learn very fast!
- Costs involved in creating and maintaining 2 sets of tools taht will look
pretty much alike.
*I did go on a SystemVerilog course and never seen such an inconsistent
monster of a language, my Doulos "reference" guide is 400 pages and I still
don't know were to put my semicolons :-). We have the opportunity to keep
VHDL a clean and consistent language but to make the language future prove
we have no choice but to extend it. If we leave it as an FPGA RTL design
language it will slowly disappear.*
[Ben] Noone is obligated to use all the features of SystemVerilog. One can
always stay in the subset of the VHDL world. However, the rich set of
SystemVerilog allos you to explore into better verification environments.
Ben Cohen
Ben@systemverilog.us
On Mon, Dec 20, 2010 at 7:20 AM, Hans <hans64@ht-lab.com> wrote:
> Hi Martin,
>
> I suspect you are correct. Like me you might have also attended the
> Modelsim User Conferences over the years and every time the question was
> raise who use VHDL versus Verilog by far the majority of the hands-up were
> for VHDL. However, if you do the survey amongst high-end verification
> engineers (ala Questa/NCSim/VCS users) then you will get a close to 100% SV
> vote, which is no surprise. We should all remember the phrase "Lies, Damn
> Lies and Statistics".
>
> I am actually somewhat surprised that nobody else commented on Steve email,
> am I the only one that read a very negative SV/Vendor biased response? If
> you read his comments then what he is basically saying is that we should all
> ditch VHDL and move to SystemVerilog since there is only room for 1
> high-level verification language. If there was only one programming language
> in the world we would have no innovation (and yes I understand the
> advantages as well).
>
> I did go on a SystemVerilog course and never seen such an inconsistent
> monster of a language, my Doulos "reference" guide is 400 pages and I still
> don't know were to put my semicolons :-). We have the opportunity to keep
> VHDL a clean and consistent language but to make the language future prove
> we have no choice but to extend it. If we leave it as an FPGA RTL design
> language it will slowly disappear.
>
> I don't understand Jonathan's idea to make an easy interface to other
> language since most simulators already provide this. In my case (I use
> Modelsim) it is very easy to add a SystemC testbench to my VHDL code or to
> use the DPI interface via a thin SV layer, standardizing this is not going
> to make any difference to me.
>
> I do however like Jonathan's idea of "leapfrogging SV", not sure how but
> something to think about.
>
> Hans
> www.ht-lab.com
>
>
> ----- Original Message ----- From: "Martin.J Thompson" <
> Martin.J.Thompson@trw.com>
> To: <vhdl-200x@eda.org>
> Sent: Monday, December 20, 2010 2:00 PM
> Subject: Re: FW: [vhdl-200x] Call for Vote on Group Organization and PAR
>
>
>
> Stephen Bailey wrote:
>
>> Data which the SG may find useful. The data is from a recent blind
>> survey commissioned by Mentor and conducted by Wilson Research Group.
>> This data is from North America. The rest of the world portion of the
>> survey was recently completed and the combined results not yet
>> available.
>>
> <snip - numbers showing VHDL in decline, SV on the up>
>
> I'd be very interested in the rest of the world results - when will they be
> available? Also, is the NA part of the survey published? I'd be interested
> to read the methodology used.
>
> From the VHDL perspective, this doesn't match my impression from over in
> Europe - maybe because I'm at the FPGA end? I can't comment on SV as I
> don't move in those circles. Or is it because I'm a designer who does also
> does verification rather than being a hard-core verification-only engineer?
>
> Do the other non-USians on this reflector see this also, or is it just me?
>
> The survey included FPGA and ASIC designs and respondents from all
>> industries/markets. Although data from the rest of the world might
>> soften a bit what is being reported in NA, based on my personal
>> experience, I don't expect it to be meaningful in any area except maybe
>> SystemC, which has historically higher use in Europe and Japan than in
>> the U.S.
>>
>
> When you say "meaningful" do you mean "it won't change the percentages
> much" or that those markets are not as influential? (Not being snarky - it's
> a genuine question! I realise that there are a few big players who have more
> influence than others)
>
>
>> In the next year, 80% (4 of every 5) of designers and verification
>> engineers will use a language that is not VHDL. Most of them will be
>> using SV or Verilog.
>>
>> The SG needs to ask itself these questions: Can you stop a tsunami?
>> What can you offer that would overcome a projected 3x+ advantage that SV
>> will have over VHDL in verification usage within the next year; and
>> surely greater than that 2 or 3 years from now. If the plan is to
>> survive the tsunami, what will you do to survive it when EDA vendors
>> clearly know where the market is going?
>> Until these questions are
>> addressed in a manner that reflects reality, my vote will remain No on
>> another VHDL language revision.
>>
>>
> Hmmm.
>
> I'm another VHDL guy who writes all his testbenches in pure VHDL (and yes,
> VHDL strings and files *are* a pain). But I really don't want to have to
> learn another language - I already do VHDL, embedded C, Python,
> Matlab/Simulink to a pretty high level of competency (IMHO :). What seems
> to be being implied is that I'd better get used to it and learn SV. Does
> that mean I have to learn all the delta-timing-related-footshooting-avoiding
> that Verilog implies (or is SV free of those sorts of non-determinism like
> VHDL is?). I really don't want to have to go there!
>
> However, having just read Jonathan's comments, I really like the idea of
> making it *really* easy to interface to a VHDL unit-under-test from any
> other language, be it C, Python, Matlab (or indeed one that I don't use :).
> And then we should put some effort into providing good verification
> environments in one or more of those languages that people find most
> interesting.
>
> Cheers,
> Martin (speaking for himself)
>
>
> Conekt is a trading division of TRW Limited
> Registered in England, No. 872948
> Registered Office Address: Stratford Road, Solihull B90 4AX
>
> --
> 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 Mon, 20 Dec 2010 10:57:35 -0800
This archive was generated by hypermail 2.1.8 : Mon Dec 20 2010 - 10:58:55 PST