Subject: RE: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Bailey, Stephen (SBailey@model.com)
Date: Sun Dec 21 2003 - 09:04:29 PST
1. PSL is not Verilog. It is insulting to the members of the PSL, assertions and fast-track team to imply the blind incorporation of anything (whatever its source). Disagreement with why something was done does not give the right to make such accusations. I know we are all human and have strong opinions on our "hot issues," but please refrain from making such accusations in the future.
2. Andy has already voiced his opinion against the parallel if?, etc. constructs (in a separate post) which would prevent any possibility of unintentional inclusion of the capability and make any use of it visually obvious. Therefore, the conclusion is that there is no formulation of this proposal that would please Andy.
3. Anyone who does not believe that SystemVerilog is a real threat to the future of VHDL is badly mistaken. See title of paper 8.3 for DVCon 2004 ( http://www.dvcon.org/ses8.html <http://www.dvcon.org/ses8.html> ). A version of this paper was presented at the Boston SNUG in Sep.
I'm sorry we cannot please Andy, but I'm equally convinced that we won't be able to please everyone with every proposed language change. It has been said, by better observers than me, a successful standard is one that dis-satisfies everyone equally. While clearly that is not our goal as we have tried to accomodate and address the complaints with this proposal, it is now clear that we will not satisfy everyone with this proposal. We will move forward by incorporating the best ideas that came out of this discussion and submit the revised proposal for WG approval at some point in the upcoming months.
-Steve Bailey
-----Original Message-----
From: Andy D Jones [mailto:andy.d.jones@lmco.com]
Sent: Friday, December 19, 2003 5:31 PM
To: Bailey, Stephen
Cc: 'vhdl-200x@eda.org '
Subject: Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
Bailey, Stephen wrote:
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.
It seems obvious to me that I will have to use it: every time I read, review, incorporate or debug a design that does use it!
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.)
The 1164 standard defined '1' and 'H' as a high level on the signal, and '0' and 'L' as a low level on the signal. The terms rising_edge and falling_ege correctly identify transitions from low to high and from high to low, respectively. Note that they did not use terms like "asserting edge" and negating edge", again, because those would imply meaning where none was intended: boolean equivalence.
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?
By making a standard, implicitly called function that does create boolean equivalence! Is this so hard to see? Surely you don't intend to leave the creation and definition of such a funtion up to the user? Therefore it will be part of the standard (1164 or
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)
I and many others are not happy at all with blind incorporation of an assertion syntax that is borrowed from verilog, complete with all it's ambiguity. And just as you use this as an argument for extending boolean equivalence beyond PSL, they will use the same argument to extend it to areas where we both agree it does not need to go (expressions, etc.) To assume otherwise is pure folly.
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.
This leap of faith is part and parcel of vhdl. Why else would someone use it? Verilog is much more compact than vhdl will ever be, so if you or any other vhdl user does not beleive it, you're using the wrong language. So quit trying to break the right language for me!
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."
What is the real value in this proposal? Other than saving a few keystrokes, what does it give us? NOTHING! It does not enhance readability for any more users than it detracts, so there is no net value there. It does not enhance the ability of tools to find bugs earlier, so there is no value there; just where is this value you're speaking of?
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.
Users that value a consistent execution model and strong data typing, and already have that will not be rushing out to use a buggy new language which does not have these features, and has precious little else to provide. SystemVerilog is a HUGE improvement over verilog, but it has practically nothing over vhdl and more than a few disadvantages.
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
Andy
This archive was generated by hypermail 2b28 : Mon Dec 22 2003 - 20:26:10 PST