ISAC: Minutes of ISAC meeting held on 17 August 2006

Note that I have held up action on IR 2100 because of a possible problem. We
can fully discuss this at the next meeting.

Chuck Swart


Minutes of ISAC meeting held via telecom on 17 August 2006

Present: Peter Ashenden, Larry Soule, Chuck Swart, Lance Thompson, Ajay Verikat

Absent: Jim Lewis

Next Meeting: Thursday, September 7, 2006, 7 pm Pacific Daylight Time
              (Friday, September 8, 2006, 2 am GMT)

TOPIC: Reviewing IRs which have been incorporated into Accellera D3.0

We discussed whether to review the VASG approved IRs which have been
incorporated into the Accellera D3.0 version of the VHDL LRM. One
issue raised was whether we should review the Accellera version,
which, of course, is not an official IEEE standard. An option would be
to wait until the Accellera version is transformed into the IEEE
version. It was argued by Chuck that if we check the earlier version,
then the final checks on the IEEE versions will be easier to
manage. There was general agreement to begin checking the Accellera
version.

ACTION: Chuck to begin to manage the preliminary review.

TOPIC: ISAC-approved IRs

All IRs voted on in the 2 June 2006 ballot were approved.  These IRs
have been incorporated into the Accellera D3.0 LRM.

ACTION: Chuck to prepare response document and update status
on website (done).

TOPIC: IR2096 Error is ambiguous

The submitter points out that the LRM requires that certain read
failures in textio be "errors" but it doesn't clearly state whether
these errors are assertion failures or simulation errors. It was noted
that if the package were implemented via VHDL code, then the only
possible errors would be assertion failures, since, in general, VHDL
code has no direct control over simulation errors. The ISAC believes
that it needs more information about what happens in practice.

ACTION: Vendors to consult with their colleagues about this. Chuck to
contact Dave and Jim to get their feedback.

TOPIC: IR2097 Operations with Array aggregates

The submitter asks whether or not the code example is legal. He then
goes on to say that he will use the ISAC answer "to encourage them
(some synthesis vendors) to fix their bug."

The ISAC's mission includes resolving issues about whether or not
certain code is legal VHDL, but it is not in the business of enforcing
conformance from tools. The success of groups like the ISAC depends on
a free discussion of ideas with no attempt to assign blame or to
identify non-conforming parties.  Consequently, the submitter will be
contacted and asked to resubmit the IR. He will also be asked to flesh
out the example.

ACTION: Chuck to contact the submitter (done).

TOPIC: IR2098 Ambiguity in definition of T'VAL for Physical types

The submitter seems to misunderstand the fact that all values of
physical types are integer values, not real values. Abstract literals
used to describe physical values can be decimal literals, such as
2.546 ms but these values alway represent an integral number of
primary units.  This is stated clearly in clause 3.1.3

ACTION: Peter to analyze.

TOPIC: IR2099 Alias declarations introduce homographs

The submitter gives two examples which raise genuine issues. These
issues affect the Accellera D3.0 version of the LRM. One fundamental
problem is that the rules for non-object aliases were written under
the assumption that the name being aliased is declared in a different
declarative region.  To give the two examples the desired semantics it
seems that we need to 1) changes the rules for implicit alias
declarations either to a) not include them if the alias declaration
occurs in the same declarative region as the thing being aliased or b)
not include them if they are already visible.  2) Allow overloading of
aliases of implicit declarations.

ACTION: Chuck to analyze.

TOPIC: IR2100 Type conversion - implicit refers to section 8.1.2 which
doesn't exist

The VHDL2002 LRM contains wording to allow overloading of protected
type methods for unary and binary operators with no or one parameters,
respectively. The submitter is incorrect in stating that this wording
is wrong. However, the LRM writers failed to specify rules for
interpreting these operator methods in operator form (in which the
object itself is used as the left or only parameter.) The feature is
less useful unless these operator forms are added. Therefore, this IR
should be forwarded to the requirements committee to be considered as
part of class enhancements. NOTE ADDED IN REVIEW I think that there
are still problems with this approach, since general rules require
that protected objects be only inout parameters. 

ACTION: Review again at next meeting.

TOPIC: IR2101 Type conversion - implicit refers to section 8.1.2 which
doesn't exist

A quick analysis shows that the index entry probably meant clause
8.1.12 instead of 8.1.2. The full analysis should do an LRM search to
see if there are any missing references to implicit type conversions
which should be added to the index.

ACTION: Larry to analyze.

TOPIC: IR2101  Typo in Section 3.2.1. Example

This is a duplicate of (part of) IR2039

ACTION: Chuck to update

TOPIC: Reviewing old IRs for VHDL2002 coverage.

This task has proved painful, so we will try a new approach.  At each
ISAC meeting we will review a few of these to decide whether or not
there are still open issues. Also, old issues which are not yet
resolved will be entered into the Bugzilla tracking system.