Cooley's VHDL vs. Verilog is silly 
Author Message
 Cooley's VHDL vs. Verilog is silly

No-one in this thread has mentioned relative ease (or difficulty) of
getting performance out of implemented designs.

When you're pushing performance, synthesis tools won't always flatten
logic as much as necessary to make timing, especially in complex blocks
with many outputs. Rearranging operations may be required. The designer
needs to understand the lowest levels of the design, and why the
synthesis tool is doing what it's doing. (S)He needs to be able to
control the order of operations of muxes, adders, etc.

An earlier post mentioned overloading VHDL operators ump{*filter*} different
ways.  At least on the surface, this seems like a recipe for not
understanding how the design will be implemented, and therefore how it
will perform, or how to fix timing which doesn't meet applied
constraints. This may be fine for a test fixture, but is inadequate for
real hardware.

In the high-level abstract world of VHDL, do you still have access to
the low level implementation control that synopsys (for example)
documents for verilog statements? If not, how is one supposed to
control long paths when synthesis constraints aren't met by the synthesis
tool? Do you end up rewriting the function at an rtl level in a clumsier
language?

Confession: I am VHDL-illiterate.

Paul



Sat, 22 Nov 1997 03:00:00 GMT  
 Cooley's VHDL vs. Verilog is silly

Quote:

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

Both camps have much to learn from the other. I am convinced my
Verilog models benefit from the structured approach VHDL taught me but
Verilog has also made me see some weaknesses in VHDL in every-day
uses.

The Verilog-vs-VHDL is indeed only good for generating pointless
magazine articles. The differences have been highlighted so much,
that one forgets how similar they actually are (for example, ALL
and ANY synthesis guideline is applicable to BOTH languages).

You can do some pretty high-level stuff in Verilog if you are
disciplined enough to properly structure the code so it remains
readable and maintainable - something I learned from VHDL. But VHDL
could learn a trick or two from verilog about reseting a model!!!

We, at Qualis, feel that users would be better served by a merging of
IVC and VIUF, bringing tools (most of which are already bilingual),
methodology, guidelines and techniques together, since they are all
applicable to one language or the other to some extent. Boasting about
whose model has less semicolons than the others does not advance the
science of hardware design and verification. Re-inventing methods,
tools and ideas already proven by the other language (the NIH
syndrome) is counter-productive.

With almost all VHDL & Verilog simulator now offering "co"simulation,
there are no technical reasons to keep these conferences separate.
All the VI committee members I spoke to are in favor. All the OVI
members others in the company have spoken to are in favor. Every user
I talk to is in favor. All the vendors (at least the bilingual ones -
the others have to gain in perpetuating the war) are in favor of
saving the expenses of 2 conferences shows a year.

We'd only get a better, more worthwhile conference - the last VIUF was
at best mediocre...and I was on the technical committee!

So, why don't you start filling my mail spool partition (please don't
quote this whole article back to me! only fill the form below). Use
[X] to mark your preferences - I may want to use a PERL script to
collect data. If I get a statistically significant sample size,
I will post a summary and write to the VIUF and IVC boards about
my (then our) request.

---------------------------------------------------------------------
I wish to remain anonymous:     [ ]

Name:
Address:
email:
Experience with                                      VHDL [ ]
                                                  Verilog [ ]

You are in favor of a merging of IV & VIUF  Y [ ]   N [ ]

I have attended IVC in the past                 Y [ ]   N [ ]
I have attended VIUF in the past                Y [ ]   N [ ]

It should be held X times a year                1 [ ]   2 [ ]
It should always be in the same location        Y [ ]   N [ ]
It should be on the X coast                     E [ ]   W [ ]

Comment:

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

--
Janick Bergeron       Qualis Design Corporation            Ph.: (503) 531-0377
Principal                   PO Box 4444                    Fax: (503) 629-5525

  VHDL  -  Verilog  -  Synthesis  -  Modelling  -  Verification  -  Training



Sat, 22 Nov 1997 03:00:00 GMT  
 Cooley's VHDL vs. Verilog is silly

Quote:

>I like having a pre-processor. Verilog's is weak, VHDL's is non-existant.

Why don't you take m4 or something like that? You'll have to use makefiles
anyway, so doing some macro preprocessing isn't really hard. m4 is ways
faster than anything else in the compilation process ;-).

Hm... I would like to have a full language as preprocessor, because
specifying a register file is always something like case 00000b: reg0 to
case 11111b: reg31, which could be modeled by

#for i=0 to 31{"case %bb: reg%i\n",i,i} or so. Problems like this are rather
likely to occur.

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/cgi-bin/nph-gateway/hphalle2/~pa...



Mon, 24 Nov 1997 03:00:00 GMT  
 Cooley's VHDL vs. Verilog is silly


|> >

[ trimmed ]

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

How do you define a line of code?

Error rates for line of code are not uniform.  They vary from person to
person, and language to language.  Also, not all errors are the same.

Syntax errors from typos are generally minor and easy to fix.  These do
track the number of characters.

Logic flaws are introduced by the designer, and will happen whatever
language is used.

In between are the implementation errors, which track better the
training and experience of the language user.

What you are thinking of is the comparisons between higher level languages
like C and Pascal with assembler.  Do you have a study comparing error
rates per line of code amonst different languages that are similar? (like
C and Ada)

I can write (almost) all functions in one line of APL, does this make
APL the ultimate in error free languages?

Errors track function points much better than lines of code.  There is about
the same number of function points in a task no matter what language it is
written in.

And you did not address my major point that language difference is minor
when compared to the rest of the design environment.




Mon, 24 Nov 1997 03:00:00 GMT  
 Cooley's VHDL vs. Verilog is silly

Quote:


>>I like having a pre-processor. Verilog's is weak, VHDL's is non-existant.

>Why don't you take m4 or something like that? You'll have to use makefiles
>anyway, so doing some macro preprocessing isn't really hard. m4 is ways
>faster than anything else in the compilation process ;-).

I've used cpp in the past. I REALLY think this is a poor solution as
the language is supposed to be portable, and as such, I'd need to
port the preprocessor as well. It really needs to be part of the
standards, in my opinion.


Tue, 25 Nov 1997 03:00:00 GMT  
 Cooley's VHDL vs. Verilog is silly

Quote:

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

AMEN !

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

Cabletron Systems, Inc.      (W) 1.603.337.5107
Merrimack, NH                (H) 1.603.424.4573
------------------------------------------------------------------------------



Sun, 30 Nov 1997 03:00:00 GMT  
 Cooley's VHDL vs. Verilog is silly

Quote:


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

> AMEN !

of course this has been debunked a couple of times now ... the
conference was a SYNTHESIS conference and the contest was to SYNTHESISE
a counter - you got to choose your own language.

Did the VHDL contest require you to actually synthesise a complete
Denver Airport Baggage Handling system? if so where did you put it?

---------------------------------------------------------------------
Paul Campbell - Taniwha Systems Design - Oakland CA USA
$cientology - the 'religion' for the '50s, where brainwashing is
a sacrament - if you think your newsgroup has wackos check out
alt.religion.scientology!



Mon, 01 Dec 1997 03:00:00 GMT  
 Cooley's VHDL vs. Verilog is silly

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

: AMEN !

: ------------------------------------------------------------------------------

: Cabletron Systems, Inc.      (W) 1.603.337.5107
: Merrimack, NH                (H) 1.603.424.4573

So what you are saying here is that VHDL can handle situations like
the Denver airport and Verilog can't...but then... the Denver airport
didn't work right...did it? ;-)

Steve Wilson



Fri, 05 Dec 1997 03:00:00 GMT  
 Cooley's VHDL vs. Verilog is silly

Quote:

>[...]
>Errors track function points much better than lines of code.  There is about
>the same number of function points in a task no matter what language it is
>written in.

Is there a tool to count function points for VHDL (or Verilog)?

Mark



Fri, 05 Dec 1997 03:00:00 GMT  
 
 [ 27 post ]  Go to page: [1] [2]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software