Subject: [vhdl-200x-ft] RE: [vhdl-200x] Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Bailey, Stephen (SBailey@model.com)
Date: Wed Dec 10 2003 - 14:25:47 PST
A few responses to Jim's comments:
> * Context Clause
> We're not sure what benefit was intended here other than
> saving a few keystrokes
> (if that's it please don't bother). But if context clauses
> are created as
> separate design units we would recommend not making the
> default set too large.
> Keep the default small (perhaps leave as is) and allow it to
> be enlarged on a
> design specific basis. We often don't need (or want) the
> tools to have to load
> up all these packages if they aren't referenced. We would
> prefer building what
> we need from a small base rather than being forced to
> override a default because
> it gives us more than we want.
As proposed, you will have what you are asking for. (The default
context clause is the same as today: library STD, library WORK and use
STD.STANDARD.all. The only question is whether IEEE.std_logic_1164 is
so commonly used as to whether it is worth adding library IEEE and use
IEEE.std_logic_1164.all clauses as well.)
Since context clauses can reference other context clauses, you can build
up such clauses.
> *to_string
> This seems to partially overlap 'image and write. 'image
> will give us strings
> for many (but we realize not all) objects, and write already
> has "justified" and
> "field". It may be better to extend/rework what we have than
> to add something
> new that overlaps. Too many different ways to accomplish a
> similar task often
> leads to more confusion than anything else.
I think Jim Lewis has done a great job of identifying the benefits of
defining To_Str[ing] as a function:
1. It can be overloaded. Attributes cannot and, therefore, are a dead
end.
2. It can be used as an expression. write is a procedure and cannot be
used in an expression context (e.g., concatenating a larger string).
> The bottom of the slide references using shorter names. Why?
> Please don't.
> The savings of a few keystrokes is not worth the loss of
> readability. We often
> have to work with non-HDL people and they comment on how easy
> it is to read
> VHDL. Overly terse syntax may make expert developers happy
> but it puts up a
> barrier for everyone else.
I just replied to this issue separately. I'm sorry, but if someone is
reading VHDL code then there needs to be some minimal level of VHDL
competency. You wouldn't expect someone who doesn't know French to get
anything meaningful from (attempting to) read a French novel.
> * Sequential usage of Conditional and Selected Signal Assignment
> * Add "if else" for conditional signal
> These just seem to be alternate ways to write something that
> we can already do.
> Changing the language to add options may not be worthwhile.
> Attempting to
> eliminate confusion in one situation will often create as
> much or more confusion
> in other areas.
>
> * Read Output Ports
> If this only gives you the locally driven value isn't this
> what 'driving_value
> already gives you? If this implies something more than maybe
> 'driving_value
> should be extended. This would make it clear we are only
> looking at the
> contribution from this driver, where reading an output
> doesn't make it clear if
> it is this driver or the resolved value.
This is the driving value of the OUT port (that is if there are multiple
drivers/sources in the architecture, it is the value after resolution).
This requirement comes from the needs of assertion based verification.
Not providing it will significantly hamstring any effort to provide
support for ABV in VHDL.
> * Boolean Equivalence
> Please don't. This opens the door to too much confusion.
> Especially when
> working with active high and active low signals together.
> Depending on object
> naming conventions people could easily be lead astray.
>
> object = '1' or object = '0' is much clearer. Where we have
> different active
> levels we often go one step further and define what is an
> active and an inactive
> state and then write object = object_active_state or object =
> object_inactive_state. This eliminates all confusion and has
> the benifit of
> allowing us to define the active state in a package (and
> change it in one
> location if necessary).
I will send comments in a separate email on this one.
> Here is the bottom line after several of us reviewed the
> slides. Real
> functionality additions are helpful, thanks keep up the good
> work. Tweaking the
> language to open up new ways to do something we can already
> accomplish is
> generally not worthwhile. Trying to make the language overly
> terse and compact
> is a bad thing to do, there are many tools that will help
> with syntax and auto
> expansion of long names if too many keystrokes are the
> issues, readability and
> making the designer intent clear are more important. Some
> may argue that terse
> compact code is clearer, we don't subscribe to that camp.
None of the proposed changes are driven by a requirement to make VHDL
code "overly terse or compact." If those were the requirements driving
any proposed changes, I would whole-heartedly agree.
The changes are driven by the following general requirements:
- Designer productivity: Sure verification may take 70% of the design
cycle time, but unlike verification, 100% of the remaining 30% is spent
intimately tied to the language. Changes that increase designer
productivity are good as long as they do not compromise other quality
considerations (such as readability and maintainability). I have not
seen an objection to shorter names that addresses the points I made in
my separate email. Why is "str" inferior to "string"? Why would "sl"
be inferior to "std_logic" or "slv" inferior to "std_logic_vector" if
"int" has not been shown to be an inferior choice of names for C's
"integer".
(If we replaced "std_logic" with "ted", then that would be problematic!)
In fact, the corporate world frequently experiences companies that were
formerly known as Kentucky Fried Chicken or American Association of
Retired People changing their names to KFC and AARP. The economy has
not fallen apart or their revenue/membership hurt as a result.
- Design intent: In some cases, "terser" code has the benefit of
better capturing design intent. For example, "process(all)" is terser
than "process(<laundry list of every signal read in a complex
combinatorial process>)", but it more accurately captures design intent
and avoids the situation when a process algorithm changes but the
designer forgets to update the sensitivity list.
- We also seek to make VHDL more acceptable to a broader range of
users than the current user base, but in a way that does not alienate
the current user base by eliminating the reasons why they chose VHDL.
Please note that nothing we have proposed would not be backward
compatible. If you love typing "std_logic_vector" hundreds of times a
day, you can continue to do so ;-)
Personally, I see no value that:
variable L : line;
...
write(L, now);
assert FALSE report "I love all the extra typing VHDL forces on me " &
l.all;
has over:
assert FALSE report "No information has been lost" & to_str(now);
(I know you can use Time'Image(Now)! But, 'image doesn't work for
everything! It is just an example to communicate that there is
absolutely no readability or accuracy or anything else lost with the
terser form!)
Finally, I'm damn tired of hearing the comments that users need to get
better editors/tools to work-around the verbosity of VHDL. The success
of VHDL should NEVER be dependent on requiring users to use such tools.
It is clear that many people lack enough marketing awareness to realize
how terrible a situation it is to tie your product's success to
something outside your control or to require added expense in the form
of purchasing 3rd party products/solutions in order to use a product.
I'm a fast typist. Such tools get in my way. And, I hate typing over
and over again "library IEEE; use IEEE.std_logic_1164.all;" I also hate
the fact that "_1164" in "std_logic_1164" adds no value or clarity to
what I'm using.
And this is from a very long time VHDL user and tool implementor.
All of us long-time VHDL users need to be careful that we do not love
this language death!
If any proposed change violates anything of tangible value in VHDL, we
definitely want to know about it. Shorter names and more concise
descriptions, in the abstract, violate nothing.
-Steve Bailey
This archive was generated by hypermail 2b28 : Wed Dec 10 2003 - 14:26:11 PST