Re: [vhdl-200x] Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003

Subject: Re: [vhdl-200x] Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Jim Goeke (
Date: Wed Dec 10 2003 - 10:53:17 PST


Having not attended the meeting we're working off the slides only, so we may be
missing the true intent of some of the changes.

* 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.

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.

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.

* 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.

* 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).

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.

Thanks for all your efforts and making the material available for review.

J. Goeke et al.

This archive was generated by hypermail 2b28 : Wed Dec 10 2003 - 10:55:03 PST