Subject: Re: [vhdl-200x-ft] Re: [vhdl-200x] Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Munden Rick (Rick.Munden@Siemens.com)
Date: Wed Dec 10 2003 - 20:59:41 PST
Jim,
Thank you. Well stated. I work in a mixed language environment. I
find it interesting that when a Verilog user is forced to read VHDL,
although they at first complain, within a day they can read it well
enough to spot bugs. Maybe not fix them, but reading VHDL they find easy.
I would not want to sacrifice that readability to save a few keystrokes.
Rick Munden
Jim Goeke wrote:
> Hi
>
> 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.
>
> *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.
>
> 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.
>
> Regards,
> J. Goeke et al.
>
This archive was generated by hypermail 2b28 : Wed Dec 10 2003 - 21:01:50 PST