Subject: Re: [vhdl-200x] To_Boolean(std_obj) vs if std_obj
From: VhdlCohen@aol.com
Date: Wed Dec 10 2003 - 10:26:29 PST
I'll go along with whatever the community wants. However, it is this
very "strong" typing issue that can get carried away, and frustrates many
engineers,
who find "relief" when transitioning to Verilog. I am not saying that
Verilog is better than VHDL - so no war here. However, I see no harm in
interpreting std_ulogic in an "if" statement as a Boolean. The way that would work would
be an "implicit" call to a "to_Boolean" function defined in an IEEE package.
That function is called with the "if std_uLogic_object then ". In that case,
there is no ambiguity as to what is meant by the implicit conversion.
PSL users and LRM authors decided to make that interpretation.
I am a strong proponent of making code more readable. The "if
to_boolean(some_signal) then" is less readable than "if (some_signal) then". For the
skeptical on this, see Verilog code, and talk to Verilog users.
Note: Adding the implicit to_boolean type conversion in an "if
std_ulogic_object" does not violate the string typing of VHDL.
Ben
In a message dated 12/10/2003 7:19:42 AM Pacific Standard Time,
robert.ingham@candc.co.uk writes:
Gentlefolk,
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.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 - 10:32:49 PST