Subject: Re: [vhdl-200x] VHDL is Domain Non-specific. Verilog is domain specific
From: Jim Lewis (Jim@synthworks.com)
Date: Fri Dec 19 2003 - 15:45:25 PST
Tim,
Agreed. However, the types bit and std_ulogic are not
non-specific. They were specifically created for modeling
hardware.
If this were done to integer and real, you would have a
good argument.
Cheers,
Jim
Tim Davis wrote:
> 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
>
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 15:47:33 PST