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 -------

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

     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."

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    

: 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 *

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.

Sorry about the previous post.. pilot error

   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.

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  


---------------------------------------------------------------------------

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

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.

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...

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  

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