Subject: RE: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec...
From: Bailey, Stephen (SBailey@model.com)
Date: Wed Dec 10 2003 - 15:58:40 PST
As promised, here's my separate comments on "boolean-equivalence".
First, the proposal absolutely, positively does NOT violate VHDL's strong-typing property. In fact, the proposal was specifically designed to work within that context. If we wanted to violate the stong-typing, we would simply insert language in the LRM defining boolean equivalance for specific or arbitrary types.
The proposal is a enhancement to VHDL that GENERALIZES the concept of "condition" in the language. It makes it possible for users to define boolean equivalence for any arbitrary type. It does NOT require that such equivalence be defined. The mechanism by which boolean equivalence is specified is by explicitly declaring an "operator" (alphanumeric mnenomic name TBD but not to create conflict with existing user-defined names). If, at the point of a condition where the type of the expression is not boolean, the type of the expression matches a visible condition operator, then that operator will be implicitly called to convert the type to boolean.
I assume it is this implicit call of the operator that is upsetting people. More on this in a bit.
With the new capability, it is further proposed that we exploit to define the OBVIOUS boolean equivalence of commonly used types:
- BIT: 0 = FALSE, 1 = TRUE
- (Possibly) INTEGER: 0 = FALSE, any other value = TRUE
- Within the 1164 WG, they can decide whether to define a boolean equivalence operator such that: 1/H = TRUE and everything else FALSE (or whatever they agree on).
On the implicit call of the condition operator:
- Automation improves productivity.
- Productivity allows more to be done with the same amount of resources.
- Automatic conversion to boolean is a form of automation and productivity.
Can it be misused? Yes, but there are many things in VHDL that can be misused. If that's a criteria, we might as well discard the entire language to ensure no one ever does anything bad with VHDL.
Can it be unintentionally misused? No, it should not be possible to unintentionally misuse this capability since it requires the explicit declaration of the condition operator. But, I acknowledge that if such operators are defined for Bit, integer and std_[u]logic[_vector], then users can unknowingly use them.
But, if users wish not to use them, then all they need to do is to continue doing what they must do today: Explicitly convert the expression to type boolean either by construction (sl = '1') or by type conversion (to_boolean(sl)).
Once again, I must ask what value is being lost and what value is being gained?
Gains are obvious:
if sl then
is shorter and more concise (with NO loss of meaning) compared to:
if sl = '1' then
I see no confusion with:
if resetn then
As a trailing 'n' is used to tag active low signals. In this case, the user probably wanted:
if not resetn then
If this were a huge problem, Verilog users would be complaining about it. They are not.
Value lost? I don't see any.
PLEASE, PLEASE keep in mind that if the user base for VHDL does not grow, VHDL will die. The user base for VHDL will not grow as long as VHDL is perceived to be lower in productivity than Verilog.
You may love VHDL the way it is. But, "loving it to death" will only insure that you will need to move to Verilog in the near future.
(I do recognize that some of these issues are relatively minor in the bigger picture. However, I still think they are important as they every designer experiences these things on a daily basis.)
-Steve Bailey
I must say that I tend to agree with Mr. Jones on this issue. I have written (for local uses) a number of 'to_boolean' functions [function over-loading is so useful!] to allow me to use constructs such as "if to_boolean(some_signal) then" which are pretty easy to understand on later reading. I also declare a lot of module-internal signals as type boolean in order to be able to use "if some_strobe then", which is also rather obvious in intent.
The appropriate mapping between 'boolean' and 'bit' values is obvious from the definitions in the 'standard' package, and these can be extrapolated to many other standard types, such as std_ulogic and even integer.
The advantages of strong typing are well worth the overhead that they bring, IMHO, and should not be sacrificed lightly.
Robert Ingham,
Principal Engineer
Communication & Control Electronics Ltd.
--DISCLAIMER This e-mail is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the sender and should not be taken as representing the view of C&C Electronics Limited. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this e-mail in error please notify C&C Electronics Limited by telephone on +44 (0) 1252 554444 or by fax on +44 (0) 1252 554400.
-----Original Message----- From: Andy D Jones [mailto:andy.d.jones@lmco.com] Sent: Wednesday, December 10, 2003 2:59 PM To: VhdlCohen@aol.com Cc: Jim@synthworks.com; vhdl-200x@eda.org Subject: Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec...
No! Say it isn't so! This is an incredibly slippery slope we're headed down. A strongly typed language is just that for a reason: so we don't make assumptions about what is meant by the code (we all know the old addage about assumptions).
I wrote a typical package that defines functions like is1() and is0() that return boolean, so they can a) handle weak values properly, and b) assert warnings if a metavalue is detected (returns false). I've thought about adding a default second argument that sets the assertion level, but haven't yet. If one is looking for absolute speed in simulation, and is willing to give up the assertion and synthesis compatibility, you could even declare constant arrays is1() and is0(). You could even have interchangeable packages for both to switch between implementations.
As for shorter names, I can't be the only one that uses subtype declarations like "subtype slv is std_logic_vector;" and "subtype sl is std_logic;" to abbreviate subsequent declarations. With a few tricks like that, we can all benefit from the same effects without modifying the language.
I like to handle things like this in this way because it allows me to play around with it for a while before I decide it is really beneficial. Thankfully, there is enough flexibility already in VHDL to allow this experimentation. Changing/adding language standards is a lot more permanent.
In the earlier discussion about if vs when, I can see value in both sides. If the same syntax is used in both sequential and concurrent contexts, it allows moving code between the two easier, which is definitely useful. On the other hand, having different syntaxes for different contexts is also a reminder of the different contexts. I sometimes wish that the concurrent signal assignment operator were different from the sequential one, rather than both using the same "<=" to remind the user (writer and reader) that the two meanings are really quite different. But I've also often wanted to use the when/else (or if/else) syntax from concurrent assignments to avoid the more verbose if/then/else constructs in sequential code. If we can give adequate consideration to this wider issue on the fast track, that's fine, but I'd prefer this get pushed back to the architecture issues so it can be thought through a little further.
Andy D Jones Lockheed Martin Missiles & Fire Control Dallas TX andy.d.jones@lmco.com
VhdlCohen@aol.com wrote:
In a message dated 12/9/2003 5:52:53 PM Pacific Standard Time, Jim@synthworks.com writes:
- Boolean Equivalence > > Please don't. Implicitly assuming a boolean value leads to > confusion. We should not trade the type-safe nature of VHDL for > (debatable) convenience. Is it really so much better to type "if > (<signal>)", than "if (<signal> = '1')"? How about the less-obvious > case "if (resetn)"? Should that read as "resetn = '1'" or "resetn is > active (low)". VHDL would have to assume the former, while users > browsing the sources would be tempted reading the latter statement > into the code.
Currently it is needed/desired in the PSL context. We are evaluating whether it makes sense in a wider context. I am kind of leaning in the same direction you are. Other members of the group are pushing in this direction. To me it has not hit my
Actually, current PSL already interprets STD_uLogic '1' and '0' as Boolean true / false. ---------------------------------------------------------------------------- Ben Cohen Publisher, Trainer, Consultant (310) 721-4830 http://www. <http://www.vhdlcohen.com/> vhdlcohen.com/ vhdlcohen@aol.com Author of following textbooks: * Using PSL/SUGAR with Verilog and VHDL Guide to Property Specification Language for ABV, 2003 isbn 0-9705394-4-4 * Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8 * Component Design by Example ", 2001 isbn 0-9705394-0-1 * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1 * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115 ------------------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Wed Dec 10 2003 - 16:01:53 PST