Cooley's VHDL vs. Verilog is silly
Author |
Message |
Fred Ro #1 / 27
|
 Cooley's VHDL vs. Verilog is silly
I sent a message to John Cooley last week regarding his "VHDL vs. Verilog, You be the jury" posting. However, a week later I am still annoyed enough about it to send out a general posting. I have paraphrased my original comments below. John is missing the point with the contest and comparison. VHDL vs. Verilog, C vs. Ada, C++ vs. Smalltalk, tastes great vs. less filling. What community benefit is being provided by continuing to fan the flames? The correct focus is to use the right tool/language for the job. The design contest showed Verilog was the best tool for that design. So what? As John stated himself, a normal counter would be a library element in DesignWare. For other designs, other languages or tools will be better. The contest results showed what anybody in the business for more than 2 weeks already knows, that you can write models for logic devices faster and more concisely with Verilog. Moreover, as models become more abstract, tools and languages become more domain specific. Simulation tools, meta tools, and techniques that support multiple languages are needed for those more abstract models. Are these more abstract models necessary? Of course! Try simulating a 100 processor node system at the RTL level. Even at the RTL level multiple languages are needed for mixed signal designs or designs that use legacy HDL code. I have been involved with simulation/analysis for a long time and was one of the first commercial users of VHDL synthesis from Synopsys. I haven't been involved with ASIC design for about 5 years but am currently involved with some system performance analysis, which includes both VHDL-based and off the shelf tools. Though I am probably considered a VHDL bigot, I try to be language neutral. However, I admit my biases. Regards, Fred Fred Rose Honeywell Technology Center
Phone : (612) 951-7106 3660 Technology Dr. Fax : (612) 951-7438 Minneapolis, MN 55418 ------- End of forwarded message -------
|
Tue, 11 Nov 1997 03:00:00 GMT |
|
 |
Gordo #2 / 27
|
 Cooley's VHDL vs. Verilog is silly
Of course you think it's silly - you lost! If VHDL had won would you still think it was silly - be honest???? I agree with one point - everyone has always known it is easier to use Verilog than VHDL for logic design. IMHO there is no other use for these languages since either is much too slow for larger problems.Anyone with two weeks experience would use C/C++/(pick your language) to model large systems.Trying to use Verilog/VHDL to model very large system (100's processors) would be fruitless.Even a behavior of a processor like a PowerPC is much too slow (C is king here).You just can't get enough cycles to examine your behavior sufficently.
|
Fri, 14 Nov 1997 03:00:00 GMT |
|
 |
John Webst #3 / 27
|
 Cooley's VHDL vs. Verilog is silly
I don't think this comparison was silly. I think it's exactly the kind of exchange of information that the net is for. Also, enough information was provided about the tests for people to make their own minds up. It does seem that Verilog is easier for designing at the gate-level, but that people who do higher level simulations (and/or like to mix various levels) express a preference for VHDL. Why is Verilog easier ? Is it possible to develop a VHDL coding style that gives the advantages of Verilog ? An example of this might be to develop a component library that provides the Verilog primitives. I'm only really guessing here, as I don't know Verilog. -- ------------------------------------------------------------------- John Webster ARM Ltd. Phone 01223 400468 Fulbourn Road
Cambridge CB1 4JN ------------------------------------------------------------------- -- ------------------------------------------------------------------- John Webster ARM Ltd. Phone 01223 400468 Fulbourn Road
|
Sat, 15 Nov 1997 03:00:00 GMT |
|
 |
Robert Newshu #4 / 27
|
 Cooley's VHDL vs. Verilog is silly
|> |> I don't think this comparison was silly. I think it's exactly the kind |> of exchange of information that the net is for. Also, enough |> information was provided about the tests for people to make their own |> minds up. |> |> It does seem that Verilog is easier for designing at the |> gate-level, but that people who do higher level simulations (and/or |> like to mix various levels) express a preference for VHDL. |> |> Why is Verilog easier ? |> |> Is it possible to develop a VHDL coding style that gives the |> advantages of Verilog ? |> |> An example of this might be to develop a component library that |> provides the Verilog primitives. I'm only really guessing here, as I |> don't know Verilog. |> |> -- |> ------------------------------------------------------------------- |> John Webster ARM Ltd. |> Phone 01223 400468 Fulbourn Road
|> Cambridge CB1 4JN |> ------------------------------------------------------------------- |> -- |> ------------------------------------------------------------------- |> John Webster ARM Ltd. |> Phone 01223 400468 Fulbourn Road
The comparison was silly. This was a small design with a component library. A schematic capture tool would be better than either language. Also time constraint was the major factor, while in real life design change and interpersonal communication are the major factors. Design content and requirements change amongst a design team as partitioning is refined for timing, power, and workload balance. Which language is better depends on the size of the team, the size of the problem, support of tools and ASIC vendor for language, existing knowledge(training), the amount of external design churn, and other factors particular to ones situation. There is no valid comparison of languages outside of a particular team's particular situation, so there is no valid global comparison possible. Any such global claim is invalid or a matter of TASTE. Robert N. Newshutz
|
Sat, 15 Nov 1997 03:00:00 GMT |
|
 |
Carl Wuebk #5 / 27
|
 Cooley's VHDL vs. Verilog is silly
Quote:
> It does seem that Verilog is easier for designing at the > gate-level, but that people who do higher level simulations (and/or > like to mix various levels) express a preference for VHDL.
Or perhaps Verilog excels at small problems such as one in the contest, and VHDL may be more appropriate for designing large systems. I'm acquainted with some students in a Computer Science class on systems design... the class teaches a rigorous definition process which delays small projects but speeds up large ones. Perhaps the additional definitions required in VHDL do the same thing -- delay small projects but speed up large ones. And again, the Verilog users may have just gotten lucky this time :-). The one argument I haven't seen refuted is based on "bug rate" measurement... I've heard (but can't point to sources for) the following: * Bug rate is measured per line of code. * VHDL and Verilog bug rate is about the same. * VHDL requires about 3X the number of lines of code to describe a given function as Verilog. If these are true (and I can't assert that they are), then I should be able to guess that a VHDL description of a function would have about 3X the bug rate of a Verilog one... and that's what I'd be concerned about. Now for the disclaimer: These are just things I've heard or read. I don't write "code" in either language (although I'm writing a Verilog->FET translator this morning in Perl :-), so I don't really know what I'm talking about. Thanks,
"My opinions only -- not those of my company."
|
Sat, 15 Nov 1997 03:00:00 GMT |
|
 |
Fred Ro #6 / 27
|
 Cooley's VHDL vs. Verilog is silly
G> Of course you think it's silly - you lost! If VHDL had won would you still G> think it was silly - be honest???? I agree with one point - everyone has always known yep, the contest is silly, regardless of who won. If John wants to use his bully pulpit for something useful, push the vendors towards good support of multi-language (VHDL, Verilog, C, etc.) simulators. G> it is easier to use Verilog than VHDL for logic design. IMHO there is no other use for G> these languages since either is much too slow for larger problems.Anyone with two weeks G> experience would use C/C++/(pick your language) to model large systems.Trying to use G> Verilog/VHDL to model very large system (100's processors) would be fruitless.Even a behavior G> of a processor like a PowerPC is much too slow (C is king here).You just can't get enough G> cycles to examine your behavior sufficently. I have used VHDL to model large systems at the performance level. I have also put together design processes which utilize a mixture of Verilog, VHDL and C. C is definitely faster and more applicable for certain applications. However it dead ends unlike an HDL. Sometimes that matters and sometimes it doesn't. Fred -- Fred Rose Honeywell Technology Center
Phone : (612) 951-7106 3660 Technology Dr. Fax : (612) 951-7438 Minneapolis, MN 55418
|
Sat, 15 Nov 1997 03:00:00 GMT |
|
 |
Bob Hoffm #7 / 27
|
 Cooley's VHDL vs. Verilog is silly
: I sent a message to John Cooley last week regarding his "VHDL vs. Verilog, : You be the jury" posting. However, a week later I am still annoyed enough : about it to send out a general posting. I have paraphrased my original : comments below. Yeah, I'd say John poured a little gas on his posting :) : John is missing the point with the contest and comparison. VHDL : vs. Verilog, C vs. Ada, C++ vs. Smalltalk, tastes great vs. less filling. : What community benefit is being provided by continuing to fan the flames? : The correct focus is to use the right tool/language for the job. The design : contest showed Verilog was the best tool for that design. So what? As John : stated himself, a normal counter would be a library element in : DesignWare. For other designs, other languages or tools will be better. The : contest results showed what anybody in the business for more than 2 weeks : already knows, that you can write models for logic devices faster and more : concisely with Verilog. : Moreover, as models become more abstract, tools and languages become more : domain specific. Simulation tools, meta tools, and techniques that support : multiple languages are needed for those more abstract models. Are these : more abstract models necessary? Of course! Try simulating a 100 processor : node system at the RTL level. Even at the RTL level multiple languages are : needed for mixed signal designs or designs that use legacy HDL code. Can you give some examples of other designs for which VHDL is more appropriate? You mention 100 processor node system but Verilog certainly supports a behavi{*filter*}description level which would allow for such a simulation. Verilog is not strictly RTL. : I have been involved with simulation/analysis for a long time and was one : of the first commercial users of VHDL synthesis from Synopsys. I haven't : been involved with ASIC design for about 5 years but am currently involved : with some system performance analysis, which includes both VHDL-based and : off the shelf tools. : Though I am probably considered a VHDL bigot, I try to be language neutral. : However, I admit my biases. : Regards, Fred Being language neutral is good, but what does VHDL add to the "making hardware" arena? The afore mentioned "silly" contest demonstrated a piece of hardware which needs to meet time to market deadlines. If VHDL doesn't support time to market and Verilog can perform system level (behavioral) modelling, what does VHDL bring to the show? : Fred Rose Honeywell Technology Center
: Phone : (612) 951-7106 3660 Technology Dr. : Fax : (612) 951-7438 Minneapolis, MN 55418 : ------- End of forwarded message ------- As you might discern, I'm Verilog-centric but trying to keep an open mind. -- Robert L. Hoffman * My Opinion, not my Employers *
|
Sat, 15 Nov 1997 03:00:00 GMT |
|
 |
Ieromnimon #8 / 27
|
 Cooley's VHDL vs. Verilog is silly
Quote:
>G> Of course you think it's silly - you lost! If VHDL had won would you still >G> think it was silly - be honest???? I agree with one point - everyone has always known >yep, the contest is silly, regardless of who won. If John wants to use his >bully pulpit for something useful, push the vendors towards good support of >multi-language (VHDL, Verilog, C, etc.) simulators. >G> it is easier to use Verilog than VHDL for logic design. IMHO there is no
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So very much so, that there is a stark contrast between the plethora of VHDL training courses, and the near absense of such courses for Verilog. It cannot be because Verilog users are more sloppy/lazy than VHDL users, so that leaves the above explanation for the cause of this phainomenon. My experience is (for me at least), a case in point: It took me two weeks to pick-up Verilog, and two more weeks to come-up with full timing specification models of asynch. FIFOs and DRAMs. In contrast, the incredible verbosity as well as the amount of stuff one has to learn in order to do -anything- in VHDL, has been an instant turn-off so far, even though i would like to be efficient in both languages. Quote: >G> other use for these languages since either is much too slow for larger >G> problems.Anyone with two weeks experience would use C/C++/(pick your >G> language) to model large systems.Trying to use Verilog/VHDL to model very >G> large system (100's processors) would be fruitless.Even a behavior of a >G> processor like a PowerPC is much too slow (C is king here).You just can't >G> get enough cycles to examine your behavior sufficently.
Right on the mark again! This has been our experience exactly. It was torture to wait for 80 hrs per data-point, for a performance graph, running verilog on a 96 Mbyte HP-PA RISC system. And the model we used was a rather coarse-cut behavi{*filter*}one, of a 16-processor system. For larger configurations, C was indeed the undisputed king. Quote: >I have used VHDL to model large systems at the performance level. I have >also put together design processes which utilize a mixture of Verilog, VHDL >and C. C is definitely faster and more applicable for certain applications. >However it dead ends unlike an HDL. Sometimes that matters and sometimes >it doesn't. >Fred >-- >Fred Rose Honeywell Technology Center
>Phone : (612) 951-7106 3660 Technology Dr. >Fax : (612) 951-7438 Minneapolis, MN 55418
Frank Ieromnimon,
|
Sun, 16 Nov 1997 03:00:00 GMT |
|
 |
John E. Winkl #9 / 27
|
 Cooley's VHDL vs. Verilog is silly
-- --------------------------------------------------------------------------- John Winkler Voice (813) 539-2007 Honeywell Inc./MS 934-4 FAX (813) 539-2183
---------------------------------------------------------------------------
|
Sun, 16 Nov 1997 03:00:00 GMT |
|
 |
John E. Winkl #10 / 27
|
 Cooley's VHDL vs. Verilog is silly
Sorry about the previous post.. pilot error Quote:
> Newsgroups: comp.lang.vhdl,comp.cad.synthesis,comp.lang.verilog > Date: 30 May 1995 10:48:08 GMT > Organization: Advanced RISC Machines Ltd > It does seem that Verilog is easier for designing at the > gate-level, but that people who do higher level simulations (and/or > like to mix various levels) express a preference for VHDL.
I personally prefer to do all my coding at as high a level of abstraction as possible. For this reason I have developed personal packages that allow me to write thing such as: A <= increment(b,3); My increment function is overloaded for many different data types and is maintained for compatability with the Synopsys synthesis tools. (I don't know if this is possible or easy in verilog, since I don't know verilog. According to my reading of the rules of the contest, I would not have been allowed to load my packages therefore I would have HAD to use the Synopsys packages, (for which documentation was not provided) and so would have been at a severe disadvantage. My assumption is that most other designers that use VHDL at a level consistant with processor design have their own private packages that they've developed over the years and would be in the same fix that I would be. Quote: > Why is Verilog easier ? > Is it possible to develop a VHDL coding style that gives the > advantages of Verilog ? > An example of this might be to develop a component library that > provides the Verilog primitives. I'm only really guessing here, as I > don't know Verilog.
If verilog has a useful set of 'primatives' it should be easily implemented in VHDL. I'm not sure that I really want to mess with things at such a level. I really don't want to restrict myself to a small range of types and what appears to be a single numeric representation. It appears to me that the exact features that make VHDL so flexible and also make it so large may indeed be disadvantageous if your sole purpose is to design at a small module level. Especially if you are restricted to someone elses idea of the functions and operators are that you need to perform your design. -- --------------------------------------------------------------------------- John Winkler Voice (813) 539-2007 Honeywell Inc./MS 934-4 FAX (813) 539-2183
---------------------------------------------------------------------------
|
Sun, 16 Nov 1997 03:00:00 GMT |
|
 |
Joao Mende #11 / 27
|
 Cooley's VHDL vs. Verilog is silly
Quote:
> It does seem that Verilog is easier for designing at the > gate-level, but that people who do higher level simulations (and/or > like to mix various levels) express a preference for VHDL. > Why is Verilog easier ?
Greetings... I only know how to work in VHDL, although I have access to design tools for both. The reasoon -> I never learned Verilog. However, I still find it easier to understand Verilog examples than VHDL examples. I think VHDL is used mainly because of US Government Standars. Correct me if I'm wrong, of course. Joao Mendes
|
Mon, 17 Nov 1997 03:00:00 GMT |
|
 |
Michael Lodm #12 / 27
|
 Cooley's VHDL vs. Verilog is silly
Having designed ASICs in both VHDL and Verilog, I'll stab at this: Verilog is easier to learn, but harder to code more powerful constructs in, such as signed multiplies. Verilog supports hardware simulation staes directly, VHDL uses enumerated types, and as such Verilog does a better job of actually modelling hardware. At the front end of the design project I appreciate VHDL's compile time checking, which caught a large number of errors that I'd be forced to simulate to catch in Verilog. Designs integrate more easily because of the compile time checking in VHDL as well. At the back end of the project, I appreciate the ease with which I can dip into the gate level models in Verilog, apply timing, and simulate mixed models. In VHDL this is a nightmare still. VHDL netlists generated by Synopsys are unreadable compared to their Verilog counterparts. I like having a pre-processor. Verilog's is weak, VHDL's is non-existant. I don't like the overhead of packages and libraries to be maintained in VHDL. Every VHDL simulator we use including Synopsys has a different non-standard library format. Synopsys itself barfs out an error message that is indecipherable relative to libraries or some missing file or other periodically in VHDL. I don't appreciate operator overloading, and prefer to have hardware primitives directly supported by the language as in Verilog. All in all, I would still pick Verilog as the language of choice for ASIC design. What we really need to see is a new language that combines the best features of both languages.
|
Mon, 17 Nov 1997 03:00:00 GMT |
|
 |
Bernd Pays #13 / 27
|
 Cooley's VHDL vs. Verilog is silly
Quote:
>Being language neutral is good, but what does VHDL add to the "making hardware" >arena? The afore mentioned "silly" contest demonstrated a piece of hardware >which needs to meet time to market deadlines. If VHDL doesn't support time >to market and Verilog can perform system level (behavioral) modelling, what does >VHDL bring to the show?
[quoted sig deleted] Quote: >As you might discern, I'm Verilog-centric but trying to keep an open mind.
I saw the contest and it did measure something that seems to be closely related to the goal of both VHLD and Verilog. However, I have the experience that this sort of contest doesn't change anything in the minds of the begods of some parties (as a football game doesn't change the minds of the spectators, does it?). We have a regular contest in another area, the area of real time programming (both the problem and the programming is "real time", because there is a hard deadline ;-). Since 5 years there were 4 wins with Forth and one win with C, and lots of other teams that never saw a result with other languages. Now the situation in real time programming is worse for Forth than 5 years ago (when the contest startet); many do their work with C (however - the only winning C group switched to BASIC at the latest contest and won the 2nd price!). Someone may argue that the winners are professionals; this may be true for the Rostock team that won 3 times, but there were a number of amateur teams in the first places, and even one amateur winner (in '93) with Forth. Now is Forth an amateur language?... You see how the argumentation works. It works the same with this Verilog/VHDL contest. Concrete in mind is harder than walls between countries. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/cgi-bin/nph-gateway/hphalle2/~pa...
|
Mon, 17 Nov 1997 03:00:00 GMT |
|
 |
Henry Dav #14 / 27
|
 Cooley's VHDL vs. Verilog is silly
Quote:
Webster) writes: >|> >|> I don't think this comparison was silly. I think it's exactly the kind >|> of exchange of information that the net is for. Also, enough >|> information was provided about the tests for people to make their own >|> minds up. >|> >|> It does seem that Verilog is easier for designing at the >|> gate-level, but that people who do higher level simulations (and/or >|> like to mix various levels) express a preference for VHDL. >|> >|> Why is Verilog easier ? >|> >|> Is it possible to develop a VHDL coding style that gives the >|> advantages of Verilog ? >|> >|> An example of this might be to develop a component library that >|> provides the Verilog primitives. I'm only really guessing here, as I >|> don't know Verilog. >|> >|> -- >|> ------------------------------------------------------------------- >|> John Webster ARM Ltd. >|> Phone 01223 400468 Fulbourn Road
>|> Cambridge CB1 4JN >|> ------------------------------------------------------------------- >|> -- >|> ------------------------------------------------------------------- >|> John Webster ARM Ltd. >|> Phone 01223 400468 Fulbourn Road
>The comparison was silly. This was a small design with a component library. >A schematic capture tool would be better than either language. >Also time constraint was the major factor, while in real life design change >and interpersonal communication are the major factors. Design content >and requirements change amongst a design team as partitioning is refined >for timing, power, and workload balance. Which language is better depends >on the size of the team, the size of the problem, support of tools and >ASIC vendor for language, existing knowledge(training), the amount >of external design churn, and other factors particular to ones situation. >There is no valid comparison of languages outside of a particular team's >particular situation, so there is no valid global comparison possible. >Any such global claim is invalid or a matter of TASTE. >Robert N. Newshutz
I take issue with the claim that "no valid comparison of languages" can be made. HDLs are really no different in representation than other programming languages, and, programming languages HAVE had significant studies done to analyze effectiveness, code density, error rates, etc. Maybe some people reading this newsgroup would be willing to help John put on a longer more involved exercise. In the late 80s I was part of TI's ASIC tools evaluation team. We spent considerable time developing evaluation methodolgies to sort out the many alternatives. Actual development times for circuits such as John described were in fact part of the evaluation. We also retargeted some very large designs. In 1988 we found Verilog to be the best of the available languages for our purposes. You claim that in real life design time is not a major factor. That may be true for some situations and not true for others. In 1988 I designed a dashboard display controller for a major automotive company. Communications and interpersonal skills had absolutely NOTHING to do with the design. We either met a specific deadline or the program was cancelled. Design time, and simulations in particular, were about all that did matter. Design coordination was accomplished by high level partitioning and models. As a last comment, error rates per line of grammatically non-redundant code are pretty uniform. Thus, a language that REQUIRES more lines of code to implement a given function is INHERENTLY less reliable than a more concise language. Henry
|
Wed, 19 Nov 1997 03:00:00 GMT |
|
 |
Fred Ro #15 / 27
|
 Cooley's VHDL vs. Verilog is silly
BP> I saw the contest and it did measure something that seems to be closely BP> related to the goal of both VHLD and Verilog. However, I have the experience BP> that this sort of contest doesn't change anything in the minds of the begods BP> of some parties (as a football game doesn't change the minds of the BP> Someone may argue that the winners are professionals; this may be true for BP> the Rostock team that won 3 times, but there were a number of amateur teams BP> in the first places, and even one amateur winner (in '93) with Forth. Now is BP> Forth an amateur language?... BP> You see how the argumentation works. It works the same with this Verilog/VHDL BP> contest. Concrete in mind is harder than walls between countries. I agree with this. I don't have any particular problem with the contest held at the Verilog conference. Design contests at conferences are meant to be fun and add to the atmosphere. However you can't infer much from these contests, particularly the real time ones, except the skill of the individual participants. What I do have a problem with though, and why I posted, was the followup post from Mr. Cooley entitled "Verilog Won & VHDL Lost; You Be The Judge!" which was a post to provide fodder for a magazine article. The argument of VHDL vs. Verilog for ASIC design is old news. The differences are well understood, and have been articulated many times in this forum. If Mr. Cooley wants to use his position as self-proclaimed EDA consumer advocate, he should address issues which are costing companies money and which can still be improved. Many designers really have no choice for what language they use for design projects. Or they have to work with other departments/companies which use different design tools. Or they are modifying a old design written in a different language,and no one from the original design team is around anymore. Or the design is an extremely complex system which has a large diverse design team. These are all everyday occurrences which are extremely problematic because of poor interoperability and cosimulation capabilities, among other things. A recent example, the avionics for the Boeing 777, had elements of all of the above problems. And the airplane, which takes its first commercial flight Wednesday, will be supported and upgraded for 25-30 years. Even for products that don't have that kind of life cycle, many of the above requirements hold true. The challenge is to create design processes and tools which meet these requirements and still provide maximum performance to the individual user. The designer is concerned with getting their design out the door as fast as possible. One data point which may help shed some light on the mind set of the two HDL conference organizers, and why they may not see eye to eye. The contest in question at the Verilog conference was the design of a counter. The design contest at a recent VHDL conference was the Denver Airport baggage handling system. regards, Fred -- Fred Rose Honeywell Technology Center
Phone : (612) 951-7106 3660 Technology Dr. Fax : (612) 951-7438 Minneapolis, MN 55418
|
Fri, 21 Nov 1997 03:00:00 GMT |
|
|
Page 1 of 2
|
[ 27 post ] |
|
Go to page:
[1]
[2] |
|