Subject: RE: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Bailey, Stephen (SBailey@model.com)
Date: Fri Dec 19 2003 - 09:51:56 PST
As Andy's post mostly reiterates our differences in opinion, I will keep my comments brief and targeted.
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.
The context is technical problems. I acknowledge that examples have been given that involve subjective opinion as to readability/maintainability. I dismiss them only in the context that they are subjective in nature. I acknowledge that people will disagree on this. It comes down to majority rule. That will eventually be decided.
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.
I do not personally know the history of what did or did not go into std_logic_1164. Therefore, I will not speak about what I don't know. However, if the package contained a to_boolean function and it did not fit your idea of how (or whether) std_ulogic is converted to boolean, you would not be forced to use it. Seems to me that if the proposal is modified such that any use of its capability must be explicit (use of a separate package), then no basis for this argument exists.
BTW, why did 1164 include rising_edge and falling_edge functions? What if they don't fit my interpretation of rising and falling edges? They aren't needed! All they do is reduce the amount of typing! (While I acknowledge there is a difference in scope, hopefully, you can see how ridiculus these arguments can get. That is why I'm interested in knowing whether there are technical problems with the proposal and not on subjective like/dislike. I'm confident that for everyone that subjectively dislikes it, I can find at least one that does like it.)
Now you folks come along and want to imply meaning where none was intended.
If no boolean equivalence is intended in the written code, how does the proposal impose one?
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.
I have already respectively disagreed with these opinions. And, I also reiterate that the inconsistency exists with PSL today (independent of whether it is part of VHDL or remains separate)
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.
Thank you for conceding my point. And, I acknowledge the scope limits.
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.
This is where the leap of faith is taken. No objective evidence is presented to show that this proposal creates ambiguity and will lead to an increase in the amount of time it takes to catch and repair bugs. I know that it is not possible to do a definitive study WRT VHDL before deciding to adopt the proposal or not, but if the scope of this proposal is inherently problematic in this regard, there must be research that indicates this a significant source of bugs in other languages. I'm not aware of any. The burden of proof resides in those making an assertion (even an implied one like this). I would be very interested in any such information.
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.
I agree. Again, I want to note that we have no requirements to make VHDL like Verilog. We do have requirements to make VHDL a more productive tool. I will not waste my time on eye candy proposals. There is real value in the proposal and it should not be considered "eye candy."
Why do you think that VHDL trounces verilog in FPGA designs?
Primarily not for the reasons you suggest. It is because VHDL tools were historically cheaper and the FPGA market is much more cost sensitive than the ASIC market. Even today, what used to be a commanding VHDL market share in the FPGA space has slid to something approaching a 50/50 split.
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.
Andy, you are flat out wrong in your estimate that existing VHDL users will not switch to SystemVerilog. The SystemVerilog folks are specifically targeting this market and they will succeed if we do nothing (or the wrong/incomplete enhancements) with VHDL. You would be right in saying that this proposal, by itself, would not stop any VHDL users from switching to SystemVerilog. But, such an assessment is far too limited in scope. Remember the primary motivation is to accomodate the incorporation of PSL into VHDL. To the extent we screw that up, it IS a big deal in the marketing battle with SystemVerilog!
-Steve Bailey
This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 09:54:53 PST