Eligible voters Closes 18-May-2005
Last Name First Name IR2004 IR2013 IR2032 IR2042 IR2045
Ashenden Peter 1 1 1 1 1
Aynsley John 1 1 1 1 1
Bailey Stephen
Eisenhofer Karl 1[1] 1 1 1 1
Lewis Jim
McNamara Michael
Molenkamp Bert 1 1 1 1 1
Myers Robert 1 1 1 1[2] 1
Pant Deepak
Ries John 1 1 1 1 0[3]
Shields John 1 1 1 1 1
Swart Chuck 1 1 1 1 1
Thibault Scott 1 1 1 0[4] 1
Vachoux Alain
Varikat Ajayharsh 1 1 1 1 1
TOTAL 15 10 10 10 9 9
Informative votes
Last Name First Name IR2004 IR2013 IR2032 IR2042 IR2045
Berman Victor
Bhasker J.
Brophy Dennis
Dunlop Doug
Gover Keith
Guy Charles
Guyler Andrew
Hebert Olivier
Lavelle Evan
Lawrence James (Jay)
Martinolle Francoise
Moretti Gabe
Ostler Farrell 1 1 1 - 0[5]
Perez Lopez Serafin
Roethig Wolfgang
Schneider Tim
Shankar Sukrit 1[6] 1[7]
Willis John
Wu Dongxiang
Zamfirescu Alex
TOTAL   2 1 1 0 1
[1]
I disagree that nesting of block comments is of little value in the
presence of line comment ("--").  The idea here is that a coder wishes
to remove blocks of code,  maybe for testing, or to replace blocks of
code with new blocks of code..  Disallowing nesting means that the coder
cannot do so if there are preexisting block comments within the region
that is to be removed.  This is an arcane limitation with no underlying
reason other than ease of implementation.  I am voting yes because
non-nesting block comments are better than no block comments at all, but
this is an issue that will arise again.
[2]
Question -- with a proposed solution as this, is
it necessary to add a new annex or clause area in the 2002
LRM to inform users of these type of issues and how they
will be resolved in future LRM efforts?
[3]
I like adding block comments and /*..*/
is okay, but I don't think the ISAC should be adding
language constructs.
[4]
1. The analysis does not seem to take into consideration the use of path names from the point of view of pre-elaboration tools.  The standard should provide one set of rules for path interpretation that can be used within the language and within VHDL tools.  Since the entity/architecture relationship is one to many, it is necessary to be able to distinguish between declarations of one architecture from another of the same entity.  Thus, support for E.A1.C and E.A2.C (entity E, architectures A1 and A2, constant C in each architecture) should also be a requirement for a proper solution.

2. If E.C is allowed, it must be restricted to use only within the architecture body, or there must be some rules introduced to require that every architecture of E have compatible declarations of C.
[5]
I favor adding block comments. However, the block comments should be allowed to nest. The lexical analyzer is affected anyway. The additional effort to support nesting should be manageable. I do not object to a reasonable maximum nesting level, but it should be larger than one (no nesting).
[6]
I strongly approve the VASG-ISAC recommendation in that no change is necessary in future versions. The "sla" operator returns a value that is L logically shifted shift by R index positions. Defined for types bit or boolean , if R is 0 or if L is a null array , "sla" returns L, else a basic shift operation replaces L with a value that is the result of a concatenation whose left argument is the rightmost (L'length - 1) elements of L and whose right argument is L(L'Right).I agree that the operator doesn't make any assumption of the left bit or the right bit of the bit vector being signed or unsigned , but for such puposes , the logical operator can be overloaded to achieve any desired semantic interpretation , eg. allowing or disallowing negative integers as the second argument .
[7]
I strongly vote on the approval of the recommendations regarding the issue  , which indicate a revision  in 13.8 (LRM Section on Comments) with a view to add the ability to comment an entire block in VHDL. The nesting of comments in VHDL is rather not necessary as it will only add to the complexity in the lexical analyser.