Subject: Re: [vhdl-200x] To_Boolean(std_obj) vs if std_obj
From: Tim Davis (timdavis@aspenlogic.com)
Date: Wed Dec 10 2003 - 10:55:53 PST
I'd be more inclined to expand type bit to be '0', '1', 'X', and 'Z',
and permit bit types to be interpreted as booleans exactly as Verilog
does it.
If you are going to build in support for 1164 types directly into VHDL
semantics then you eliminate the need for the 1164 standard. Is that good?
Also, perhaps there could be a way to explicitly show the mapping from
the enumeration in a type definition directly to boolean. That exposes
the translation so that other "bit" implementations can take advantage
if needed.
For example:
type negative_logic is ('0' => true, '1'=>false, 'Z'=>false, 'X'=>false)
with boolean,
('0'=>1, '1'=>0, 'Z'=>-1, 'X'=>-1)
with integer,
('0' => "0", '1'=>"1", 'Z'=>"Z", 'X'
=> "X") with string;
Now if the analyzer sees an IF with a non-boolean type it can check the
unexpected type for a translation mapping and apply that transparently.
The advantage is that the mapping is explicitly present in a package or
the user's code thus documenting the intention directly without
resorting to cumbersome translation functions or new built in VHDL
semantics. Type checking is preserved and nuclear holocaust is
prevented. :-)
-- Aspen Logic, Inc. By: Tim Davis, PresidentVhdlCohen@aol.com wrote:
> 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/ <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:58:39 PST