Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec...


Subject: Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec...
From: Andy D Jones (andy.d.jones@lmco.com)
Date: Wed Dec 10 2003 - 06:58:48 PST


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 - 07:00:36 PST