ISAC: minutes of meeting held on 11 August 2005

Attached are the minutes. Please let me know of any mistakes, etc.
The minutes are also available on the website.

Chuck Swart



Minutes of ISAC meeting held via telecom on 11 August 2005

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

Absent: Jim Lewis, Deepak Pant

Next Meeting: Wednesday August 31, 2005, 7 pm Pacific Daylight Time
              (Thursday September 1, 2005, 2 am GMT)

TOPIC: Status of Web Based IR System

Chuck reports that:

I'm still playing around with the system. Its almost ready to be
publicly accessible. I'll send email to the group when its ready to be
tested.

ACTION: Chuck to email ISAC when the system is accessible.

TOPIC: IR 2070 Support for floating point denormal numbers

The IEEE 754 (and 854) standards require support for +,-,*,/ and
square root, but not exponentiation. This means that exponentiation is
a function. Also, the LRM technically states that VHDL uses IEEE 754
representation. It does not state that it uses 754 arithmetic. This
was intentional, since VHDL does not give access to INF, NAN, etc.

ACTION: Peter to analyze.

TOPIC: IR 2065 OTHERS in aggregates too restrictive

The analysis is accepted and the IR is ISAC-Approved.

ACTION: Chuck to forward to VASG

TOPIC: IR 2069 Visibility of generics in block configurations

Ajay reported that the issue involves the interpretation of section
10.2. The main point is that the section extending scope/visibility of
the block into the configuration does not extend scope/visibility into
the entire configuration. There are "holes" specifically listed, which
are external blocks. Also, the recommendation for future revisions
could include a statement that it would be helpful to have a use case
which identifies an enhancement requirement.

ACTION: Chuck to revise and then submit for vote.
Ajay to contact originator to ask him to submit an enhancement request.

TOPIC: IR 2054 Individual. assoc. rules for array formal are not valid

Part 1) The analysis says that the directions of the index ranges are
taken from the association elements. The most common form of
association is an indexed name, which does not have a direction.
Perhaps a better solution is to state that the directions of the index
range(s) of the formal generic or formal port is/are that of the index
subtype(s) of the formal.

Part 2) The analysis is correct.

Part 3) type conversions.

The issue is the two paragraphs which mention type conversions and
requires that the appropriate subtype be constrained. This statement
is confusing when applied to subelements, which are already
constrained (if they are arrays).

Perhaps the cleanest solution is to break up the two existing
paragraphs into two pairs of paragraphs: One paragraph for association
in whole, and a second paragraph for subelement association which
states that when subelement association is used the result type or the
parameter type must match the type of the subelement.

ACTION: Larry to revise his analysis.

TOPIC: Process for analyzing old IRs

It was agreed that the ISAC needs to review the VHDL93 IRs to identify
those which have unresolved issues for VHDL2002. Chuck will divide the
issues among the team members, and we will try to address a few of
these at each meeting.

ACTION: Chuck to work out assignments.

TOPIC: IR 2038 Minor semantic errors


Issue 1. Missing semantics for block configurations of generate statements

The issues are valid. Possible solutions are:

Make the discrete range (globally) static by changing discrete_range
to <static_>discrete_range in the index_specification grammar rule.

State that the type of the discrete_range or static_expression must be
the same as the type for the FOR GENERATE parameter.

State that it is a range constraint error if the subtype of the
discrete_range or static_expression is not compatible with the subtype
of the generate parameter.

State that a null discrete range is allowed and such a range does not
configure any of the blocks.

Issue 2. Section 3.2.1.1 Index constraints and discrete ranges

It was agreed that the flat paragraph structure is very hard to read
and that listing/indenting paragraphs would be useful. Peter
experimented and discovered a practical nesting level of depth 3,
which seems sufficient.  Chuck reported that there are other parts of
the LRM which would also benefit by ordering/indenting paragraphs.

ACTION: 

Issues 1 and 2: Peter to analyze. 

Issue 2: Chuck to provide more examples where ordering/indenting of
paragraphs would be helpful.

(Added after meeting by Chuck: The only other example I could easily
find is in clause 1.3.1 Block Configuration

Following the sentence/paragraph which reads: "The block specification
identifies the internal or external block to which this block
configuration applies " there are three paragraphs, each of which
begins: "If a block configuration appears immediately within..." These
paragraphs are mutually exclusive and independent of the following
paragraphs. indenting/numbering these would make the LRM much
clearer.)