ISAC minutes for meeting held June 17, 2005

Enclosed are the minutes for the ISAC meeting held 17 JUNE 2005.
Please review them.

Minutes of ISAC meeting help via telecom on 17 June 2005

Present: Peter Ashenden, Jim Lewis, Chuck Swart, Larry Soule

Absent: Deepak Pant, Ajay Verikat

Next Meeting: Thursday July 7 2005, 8 pm Pacific Daylight Time
              (Friday July 8 2005, 3 am GMT)

TOPIC: Review ballots on difficult issue reports.

See included document.

Note: The proposed review documents are included instead of being
attached, so that they will provide useful minutes. Separate
documents will be sent to the ISAC for review and critique.

ACTION: Described in included document.

TOPIC: IR2068 Entity instantiation with space before the entity name

Peter's analysis is accepted. Entity instantiations may have a space
before the entity name.

ACTION:  IR2068 is ISAC approved, subject to review by Deepak and Ajay.

DOCUMENT response_difficult.txt:

This is the response document to the ballots for the Difficult
ISAC-Approved Issue Reports.

The following IRs were submitted for ballot:

2004, 2013, 2032, 2042, 2045

All IRs were approved.

IRs Approved Without Comments:

2013, 2032

IRs which received comments:

2004 Definition of SLA doesn't make sense

In an informative affirmative ballot, a reviewer strongly supports the
decision that no change is necessary in the definition of SLA

CONCLUSION: IR2004 is VASG-approved.

2042 Architecture as a block causes problems

In an affirmative ballot, a reviewer asks if it is necessary add a new
annex or clause in the 2002 LRM to inform users of these issues.

RESPONSE: The ISAC will mention this possibility to the VASG. However,
the effort involved in making any official change to the 2002 LRM is
virtually the same as re-balloting the LRM. Also, the ISAC knows of no
implementation which has treated the architecture as a separate block,
so in practice, this should not be a problem.

In a negative ballot, a reviewer states two issues (quoted in full):

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

RESPONSE:

The names discussed in the analysis are expanded names (see LRM clause 6.3),
not path names.  Specifically, the names Work.E.C, E.C, and A.C can only be
used within the declarative region where C is declared.  This form of name
is distinct from path names (either pre- or post-elaboration), which address
an item from an external view, that is, from a root name space external to
the enclosing construct.

Formation of paths names is a separate issue from that addressed in IR2042.
Path names are addressed elsewhere, including:

- VHPI: A pre-elaboration path name for the constant C in the example would
  be Work.E:A.C

- Cross-Module Reference (XMR) proposal described in VHDL-200x-FT proposal
FT07

- PSL

There is an ongoing discussion to unify the form of path names among these
specifications, the 'path_name and 'instance_name specifications, and
expanded names.  See
http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/ft32_pathname.pdf and
http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/ft32_pathname_issue_roll
up.html.


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

RESPONSE:

Since C is declared within the architecture body, it cannot be referenced
within the entity declaration.  The scope and visibility rules (LRM clauses
10.2 and 10.3) specify that the scope of the declaration of C starts at the
declaration and extends to the end of the architecture body.  In this case,
C is only visible within its scope, which does not extend to the entity
declaration.  So the existing rules already address the commenter's
requirement.

CONCLUSION: IR2042 is VASG-approved.

2045 Add the ability to comment an entire block of code

In one affirmative ballot and one informative negative ballot, two
reviewers state that nested block comments should be allowed.

In an informative affirmative ballot, a reviewer supports the prohibition on
nested block comments.

RESPONSE: Some nesting of comments is allowed, since -- comments can
be present within a block comment. Since the affirmative vote was for a
construct in which nested block comments are not allowed, there is no
change to the existing issue solution. Notice however, that if it is
later determined that nested block comments should be allowed, this
capability can be added without affecting backward compatibility.

In a negative ballot, a reviewer supports the solution but states that the
ISAC should not be adding language constructs.

RESPONSE: The ISAC is technically not adding language constructs. The ISAC
has made a recommendation to the VASG, which can accept, reject, or modify
the recommendation. Also, historically, the ISAC has made proposals for
language changes, particularly in areas which require careful language
analysis. For this particular issue it was decided that the fastest way to
resolve it was to make a specific recommendation.

CONCLUSION: IR2045 is VASG-approved.