ISAC Minutes ready

The minutes from our last meeting on 05 May 2005 have been posted.
The major results from that meeting are found in the two attached documents.
Please review them as soon as possible and make suggestions regarding 
content,
style, anything.

These documents will probably receive broad release, so we don't want 
anything
stupid in them. If a statement is confusing or poorly worded we need to 
clean it up.

Note that for IR 2044 Deprecation of linkage ports affects boundary scan 
description language,
I have determined that a change would clarify things, and that the 
change is purely editorial, so that
no reballoting is necessary.
Other options are: No change
or: Change and reballot

Please read these and respond ASAP.

I'm more than willing to do the brunt of the work on this, but I really 
need you
guys to review it.

Chuck


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

The following IRs were submitted for ballot:

2000, 2001, 2002, 2008, 2020,
2029, 2030, 2036, 2037, 2039,
2047, 2048, 2051, 2052, 2053,
2055, 2059

All IRs were approved. However, in response to comments, some of
the IRs will be revised and resubmitted for approval.

IRs Approved Without Comments:

2001, 2002, 2008, 2030, 2036,
2037, 2039, 2047, 2051, 2052,
2055

IRs which received comments:

2000 Where may/must deferred constant declaration appear

In an affirmative ballot, a reviewer suggests that the context-free
grammar be used to guarantee that deferred constants occur only in
package headers.

RESPONSE: The current syntax does not have separate rules for deferred
and non-deferred constants. If we were to split the grammar for
constant declarations into two rules, the analyzer error checking
would replace a semantic error such as "Illegal deferred constant"
with a less-specific syntax error such as "Found ';' expected ':='."
It was determined that such a change would make the grammar more
complicated while providing little or no improvement in error
detection.

CONCLUSION: No change is needed. IR2000 is VASG-approved.

2020 Keyword REPORT is over-used

In a negative ballot, a reviewer suggests that we add a note to the
affect that an assertion statement in which a semicolon is
inadvertently inserted between the condition and the "report" keyword
is interpreted as an assertion statement followed by a report
statement, and is not detected as an error.

RESPONSE: The suggestion is accepted.

CONCLUSION: IR2020 will be revised and recirculated for ballot.

2029 Non-relevant words and paragraph.

In a negative ballot, a reviewer point out (in a negative ballot) that
the recommendation for 1076-2002 was left TBD.

RESPONSE: This was an editing oversight. 

CONCLUSION: IR2029 will be revised and recirculated for ballot.

2048 Miscellaneous errors

In an affirmative ballot, a reviewer suggests that each of the twelve
(or so) issues be voted separately.

RESPONSE: Voters could have called for separate votes on each issue,
but none did. In addition, any negative ballots (there were none)
would identify problems with specific issues. If some of the issues
were controversial, then it would make sense to have separate votes,
but when the expectation is that most, if not all, of the issues are
routine, then a mass vote makes more sense. Also, note that all
negative ballots are carefully considered, regardless of the vote, so
there is no risk that a negative response to a particular issue will
be lost or ignored because of votes in favor of other issues in the
IR.

CONCLUSION: No change is needed. IR2048 is VASG-approved.

2053 Minor Typos in VHDL 2002 part 2

At the time of the call for vote,the recommendations sections said
TBD.  The intention was to recommend that the current revision be
interpreted as though the corrections were made and that the next
revision implement the corrections.

RESPONSE: This was an editorial error. The IR was updated to reflect
the intent of the ISAC, but because of potential confusion the updated
IR will be re-balloted.

CONCLUSION: IR2053 will be revised and recirculated for ballot.

2059 Upper/lower case character mapping is not clear

In a negative (informational) ballot a reviewer pointed out that the
proposed resolution identifies the sharp S character as uppercase,
when, in fact, it is lower case.

RESPONSE: The reviewer is correct.

CONCLUSION: IR2059 will be revised and recirculated for ballot. 


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

The following IRs were submitted for ballot:

1044, 2010, 2018, 2023, 2031,
2040, 2044, 2049, 2056, 2057,
2058, 2061

All IRs were approved. However, in response to comments, some of the
IRs will be revised and resubmitted for approval.

IRs Approved Without Comments:

1044, 2010, 2040, 2056

IRs which received comments:

2018 Variable IN parameter should be no different than constant

In an affirmative ballot, a reviewer states that he is not convinced
that an IN variable parameter should not be allowed to have an actual
that is a general expression.

RESPONSE: The ISAC does not feel strongly about this issue. However,
there seems to be little reason to add this capability.Note that the
recommendation of "No change" to the LRM does not prevent us from
extending the semantics of IN variable parameters in the future to
allow general expressions as actuals.

CONCLUSION: IR 2018 is VASG-Approved. No change to the LRM is needed.

2023 Add predefined array types for integer, boolean, real and time

In a negative ballot, a reviewer states that adding these types breaks
backward compatibility and moves the burden of support from active
code developers to those supporting legacy designs.

RESPONSE: First, this issue was raised because of incompatibility with
VHDL-AMS packages. So there is an inherent conflict between
portability and backward compatibility. Second, the ISAC surveyed the
VHDL community by contacting active IEEE VHDL groups and by sending
email to comp.lang.vhdl about possible problems with compatibility
caused by adding these types. The overwhelming consensus was in favor
of adding them. Third, every implementation that we are aware of
allows compilation and simulation using non-current VHDL versions. It
is already quite common for legacy code to use older versions for file
compatibility, rules for concatenation, size of CHARACTER type,and
other differences.

CONCLUSION: IR 2023 is VASG-Approved.

2031 "mod" function needed for TIME

In three affirmative ballots and one negative (informative) ballot,
reviewers noted the typos for negative time values.

RESPONSE: These will be fixed.

In the same negative(informative) ballot, the reviewer asks for an
example with mixed time units.

RESPONSE: Such an example will be added.

In an affirmative ballot, the reviewer asks that we also provide
versions of the mod and rem functions in which the left operand is a
physical type and the right operand is of type INTEGER.

RESPONSE: This was not part of the original request. There is an
obvious definition of A rem B in which A is a physical type and B is
an integer type. However, it is very difficult to cleanly define A mod
B under the same circumstances, since modular arithmetic has an
inherent notion of an integer number of cycles. Specifically, the
defining equation:

A = B*N+(A mod B)

fails for B of type INTEGER. In addition, it is hard to envision a
realistic use case for which this version of mod or rem is needed.
However, there is nothing to prevent someone from supplying a
practical use case and requesting such an enhancement.

Therefore, at this time, mod and rem for right operand of type INTEGER
will not be added.

CONCLUSION: IR2031 will be revised and  recirculated for ballot.

2044 Deprecation of linkage ports affects boundary scan description language

In an affirmative ballot, a reviewer suggests that we remove the
linkage ports feature from Annex E (Features under consideration for
removal) to prevent potential confusion.

RESPONSE: 

The proposed resolution states in part: "Remove the feature from the
list in Annex E and remove the notes in 1.1.1.2 and 4.3.2." Although
it doesn't state it explicitly, the intent of the ISAC recommendation
was to adopt the Proposed Resolution.

CONCLUSION: IR2044 will be revised to reflect this minor editorial
change and then will be VASG-Approved.

2049 Circular definition of an event on a signal

In a negative (informative) ballot, the reviewer complains that the
recommendation for change does not precisely define how the specific
relevant paragraph is modified.

RESPONSE: The ISAC interprets this IR as an intended specification.
The exact wording is deliberately left to the LRM writer. Note that
for IRs for VHDL-93 it was very common to indicate intent in the IR
without dictating specific language. Also, note that the LRM writer's
response to this IR will be a specific LCS (or similar document) with
proposed wording for the LRM change, so there will be an opportunity
to vote on the specific wording.

CONCLUSION: IR2049 is VASG-Approved.

2057 Access-typed parameters to predefined "=" and "/="

In an affirmative (informative) ballot, the reviewer points out that
the proposed solution is a short-term fix and asks if there is a
proposed long-term solution?

RESPONSE: Both the ISAC and the Data Types and Abstraction (DTA)
working group are aware of the issues in this complicated area. A
long-term solution can best be formulated with knowledge of intended
enhancements of data types.

CONCLUSION: IR2057 is VASG-Approved.

2058 Does USE of type name make operators and literals visible?

In a negative ballot, the reviewer states that he is worried about
compatibility for systems that didn't make the operators or enums
visible. He also suggests a new syntax such as

    use type_name.all;

to make all the implicit operators and enums for that type or subtype
visible.

RESPONSE: This is a very difficult issue. (It was originally intended
to go on the "difficult issues" list [as commented on by one
affirmative reviewer] but, due to an editorial mix up, was added to
the "moderate issues" list.)

With regard to compatibility, one of the major roles of the ISAC is to
identify areas in which implementations have different interpretations
and to produce the best technical solutions in these areas. If we
never resolve these issues, then our tools will forever be
incompatible.

As far as the

    use type_name.all;

suggestion, Ada has a similar:

    use type type_name;

The ISAC considered these unnecessary to solve the question raised by
IR2058, but the DTA working group may well add a similar syntax to
deal with new visibility issues for extended data types which may be
added.

CONCLUSION: IR2058 is VASG-Approved. 


2061 Default actions on severity flags is different between simulators

In an affirmative ballot, the reviewer states that the same issue
arises in the SystemC LRM, and that the choice of the term "warning"
versus "error" should be taken as a hint to the implementation, but is
not a strict obligation.

RESPONSE: As the reviewer suggested, the SystemC recommendation is
similar in spirit to the VHDL recommendation.

In a negative ballot, the reviewer states the term "default" is
outside of the scope of the LRM.

RESPONSE: 

The words "by default" will be removed from the Recommendation.  A
note will be added, stating that an implementation may perform
different actions from those recommended, and it may give users
ability to control simulator actions via mechanisms not specified by
the LRM.

CONCLUSION: IR2061 will be revised and  recirculated for ballot.