Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003

Subject: Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Andy D Jones (andy.d.jones@lmco.com)
Date: Fri Dec 19 2003 - 08:54:21 PST

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 - 08:58:15 PST