[vhdl-200x] VHDL is Domain Non-specific. Verilog is domain specific

Subject: [vhdl-200x] VHDL is Domain Non-specific. Verilog is domain specific
From: Tim Davis (timdavis@aspenlogic.com)
Date: Fri Dec 19 2003 - 15:21:15 PST

I propose that the question being debated here is the following:

    VHDL is a domain non-specific language that can be molded to suit a
    large number of different hardware modeling styles and problem
    domains. Verilog is a domain specific language that has a very
    narrow scope of applicability to electronic circuits.

Verilog, with a narrower scope, seems appealing because the description
system it uses is simpler but ultimately less powerful. If all you are
doing is gates then what else do you need? That is a fair position to
take. However, falling into the trap of domain specific arguments will
be deadly to VHDL. It will not stand the test of time if we do. Look at
Verilog. It has not stood the test of time. It is being replaced by
System Verilog (or system C even) to dramatically improve the language.
(Forget the fact that it has Verilog in the name.) New descendents of
the language will be hodge-podges of features cobled together. 

--
Aspen Logic, Inc.
By: Tim Davis, President

Andy D Jones wrote:

> Steve,
>
> Bailey, Stephen wrote:
>
>> Note that we have no plans on tabling this proposal.  There have been 
>> no technical problems found with the proposal.  The proposal is one 
>> of several issues needed to facilitate the incorporation of PSL as 
>> the property specification and temporal assertion capability in VHDL.
>>  
>
> snip...
>
>> You are making assertions that have not been substantiated by any 
>> tangible example.  We are not "dumbing it down for the masses."  
>> Quite the opposite.  We are making the language more sophisticated in 
>> its ability to recognize commonly used code snippets and not require 
>> the user to explicitly cover everything.  Any step up in abstraction 
>> level (including this relatively minor move up) requires the removal 
>> of some detail.
>
>
> It is very convenient that you dismiss as intangible any argument that 
> does not agree with your point of view.  I have time after time listed 
> case after case where this is a bad idea, but let me summarize for you 
> my tangible arguments against this.
>
> The plain truth is that std_logic_1164 was developed to model signal 
> levels and strengths beyond a simple one and zero, and provide for 
> operations on those values.  It purposefully did not define any state 
> or states as true or false, since that is entirely up to the context 
> of the design, and well beyond the scope of that standard or even the 
> language itself.
>
> Now you folks come along and want to imply meaning where none was 
> intended.  You want to forever and always define '1' (and 'H') as TRUE 
> and everything else as FALSE.  Have you stopped to think that if they 
> had wanted that done, even explicitly (let alone implicitly), they 
> would have provided a conversion to accomplish it?  Surely this was 
> debated and rejected (after all, they did provide is_X() and other 
> tests, but not even ones for is_0() and is_1(), let alone a completely 
> ambiguous to_boolean()). Even in the base language, such assumptions 
> were purposefully not defined for BIT values that lack both strengths 
> and metavalues. And for good reason: such definitions are beyond the 
> scope of the language, and vary from context to context (i.e. active 
> low signals vs active high signals).
>
> Secondly, the same users that complain about having to type a few 
> extra characters when using sul or bit values in conditionals are also 
> going to complain about having to explicitly test them in boolean 
> expressions.  The legalese of constraining this implicit conversion to 
> conditionals is well beyond them; their fingers hurt!  They will 
> eventually demand that, if we don't have the same features in 
> expressions, "the language lacks consistency, and must be fixed!"  But 
> by then we will have lost the high ground and will have no choice but 
> to concede to their aching fingers.
>
>>  
>> Did anyone see the quote attributed to Cliff Cummings in a 
>> SystemVerilog article this week or last (I believe it was EE Times, 
>> but I can't find the article now)?  Cliff stated that, with 
>> SystemVerilog, it will be possible to write the same functional model 
>> in 70% less code than what is required in Verilog.  The important 
>> point is not whether 70% is an accurate number.  The point is that 
>> Cliff is correct in that SystemVerilog requires less code than 
>> Verilog.  This is our competition.  If people can design and write 
>> testbenches ?x times faster in Verilog than VHDL, VHDL will shrink to 
>> irrelevance.
>>  
>> This does not mean that VHDL must blindly mimic Verilog.  It does 
>> mean we need to make VHDL more efficient.  Readability and 
>> maintainability remain key value differentiators.  So far, no one has 
>> demonstrated how a proposal objectively violates these language 
>> values.  It has been demonstrated how the proposals improve efficiency.
>
> Since when is efficiency of a language defined by its compactness?  
> The efficiency of a language can be measured by the the product of the 
> rate at which bugs are created, and the time it takes to find and fix 
> those bugs. The first measure is indeed strongly related to 
> compactness.  Many studies have revealed a factor of bugs per line of 
> code that is remarkably stable across languages of widely varying 
> brevity.  However, the time it takes to find and fix those bugs is 
> highly dependent on language style, favoring strongly typed, explicit, 
> even verbose languages.  The whole reason for the existence of VHDL is 
> that we believe that the latter outweighs the former.  In terms of 
> total efficiency, it is better to have an explicit language that 
> catches bugs early by denying ambiguity, than to have a compact 
> language that encourages ambiguity.  This is the foundation that vhdl 
> was built on.
>
>>  
>> I've said it before and I'll say it again:  If you love everything 
>> about your day-to-day experience with VHDL, then make sure we make 
>> everything backward compatible so you can continue your life 
>> unchanged.  Otherwise, stand aside (as long as we are doing no 
>> objective damage) and allow us to make it a higher productivity tool 
>> for a broader user class.  If you stand in the way of progress, 
>> you'll find that you'll have no VHDL tools 5-10 years from now.  Is 
>> that a future you want to see?
>
> If we make vhdl more like verilog for the wrong reasons, we will lose 
> both our differentiation and our advantage, and vhdl will also die, 
> only we will have killed it with our own hands. We must capitalize on 
> VHDL's differences, while adding features that use those to utmost 
> advantage, not by adding some eye candy proposals such as this that 
> tear down what so many struggled to create.
>
> Why do you think that VHDL trounces verilog in FPGA designs? Could it 
> be that a whole new group of users looked at both languages for the 
> first time, and chose vhdl on its merits? Comparatively, the ASIC 
> market got drunk on verilog before vhdl was available for synthesis, 
> and have succumbed to momentum ever since.  So in a market where a 
> true choice is evaluated solely on its merit, vhdl wins.  I suspect 
> that system verilog will win the verilog/asic market due to momentum, 
> but not win many head to head competitions against vhdl, if we are 
> smart about the changes we make to the language.
>
>>  
>> -Steve Bailey
>
>
> Andy Jones

This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 15:24:13 PST