ISAC: Minutes of meeting held on 02 February 2006

Attached are the minutes.
These minutes are also on the website.
Note that there is an added note for IR 2062 Range staticness.




Minutes of ISAC meeting help via telecom on 02 February 2006

Present: Peter Ashenden, Jim Lewis, Ajay Verikat
Absent: Jim Lewis, Deepak Pant, Larry Soule

Next Meeting: Thursday March 02, 2006, 6 pm Pacific Standard Time
              (Friday March 03, 2006, 2am GMT)

TOPIC: New members.
The ISAC would like to get one or two more members.
Several names were given to Chuck.

ACTION: Chuck to contact prospects.

TOPIC IRs which passed VASG vote with no comments:

IRs 2043, 2064, 2069 and 2071 passed with no comments. These
will be marked VASG-Approved and forwarded to VASG chair/Accellera

ACTION: Chuck to forward these IRs.

TOPIC: VASG vote on IR 2028 Clarify simulation cycle.

This IR passed with several comments, but no negative votes. All
comments related to wording which was added to the LRM to support
VHPI. The ISAC has determined that the best way to address these
comments is within the context of the VHPI effort (which is scheduled
to go to ballot in the near future.) Therefore, IR 2028 is
VASG-Approved.

ACTION: Chuck to forward this IR.

TOPIC: VASG vote on IR 2050 Definition of S'Last_Value was apparently
broken in 1993

One affirmative voter commented that under the current wording it
might not be clear what the behavior of 'Last_Value is on
composites. He noted that the behavior changed between VHDL 87 and
VHDL 93, and that the proposed wording seems to follow VHDL 93 for
composites.

The ISAC agrees that the LRM intentionally follows VHDL 93 behavior
for composites: The signal as a whole is considered and a value change
to any element causes a value change to the whole. Put another way,
The Last Value of a composite is an actual (composite) value which the
signal held: it is not an aggregate of scalar Last Values.

IR 2050 is VASG-Approved.

ACTION: Chuck to forward this IR and to contact the voter and invite
him to respond (perhaps by requesting that a note or example be added
to the next version of the LRM.)

TOPIC VASG vote on IR 2065 OTHERS in aggregates too restrictive

One affirmative voter responded that the failure to remove
restrictions on OTHERS in aggregates was "a really annoying
limitation." Another asked what the purpose of the vote was, since the
IR was an enhancement request.

The ISAC agrees that this IR is really a request for change in
functionality, not a "bug fix." However, it is reasonable to analyze
the issue because of its very technical content. The proper procedure
should have been to finish the analysis, then to forward it to the
enhancements committee.

ACTION: Chuck to forward as an enhancement.

TOPIC: VASG vote on IR 2062 Range staticness 

There was one negative vote. This voter pointed out that the solution
was not as complete as one might like. It allows

for I in G'RANGE generate ...

where G is a generic, but it
doesn't allow

for I in P'RANGE generate ...

where P is a port.

One possibility discussed was to remove the restriction that the range
used in a generate statement be globally static.  

[NOTE added after meeting. One reason for keeping the globally static
restriction is that if you have..

for I in impure_function_1 to impure_function_2 generate...
You don't know the order in which the functions are called.

It was also remarked that other changes to items j) and/or k) might
accomplish the task.]

ACTION: Ajay to reconsider and possibly to reanalyze.

TOPIC: VASG vote on IR 2068 Entity instantiation with space before the
entity name

There was one negative vote which stated "Confusion may be in not that
the space is allowed, but whether or not there is consistency in tool
suites sometimes "tossing"/deleting it during parsing. He Then
mentions several examples with different spacing in "name.element".

The ISAC responds that the LRM clearly states that all of the cases he
mentions are equivalent (and legal VHDL). The IEEE and the ISAC/VASG
can only interpret the LRM: they cannot (and do not want to) certify
tools/implementations with respect to compliance. The voter's concern
about possible non-compliance of tools may be justified, but the ISAC
and VASG cannot deal with that issue.  The IR is therefore
VASG-Approved.

ACTION: Chuck to forward. Also, Chuck to prepare summary document to
give to all who voted on the IRs.


TOPIC: IR 2081 The term ancestor is used where parent is meant

The LRM defines the term "parent" for subprogram calls. Although the
definition is consistent, the word "ancestor" might be better, both
for intuitive meaning and for consistency with graph-theoretic terms.
However, this term could cause confusion with the defined term
"explicit ancestor" which applies to signal names.  So the analysis
suggests that the two incorrect uses of "ancestor" be replaced by
"parent." However, if there is significant preference to use
"ancestor" then the term "explicit ancestor" should also be renamed to
something else.

ACTION: All to vote on this IR.

TOPIC: IR 2082 Elaboration of unconstrained interface objects

The technical issue is raised by the submitter: that for an
unconstrained object, the object is "created" before it receives its
index range from the actual. This issue is valid, and can probably be
fixed by careful rewording of sections 12.2.2, 12.2.4 and 12.5b). In
addition, this rewording should be done in conjunction with LCS
2006-118 which deals with reference to generic ordering of elaboration
within generic clause and generic map aspect, since this LCS affects
the same code sections.

ACTION: Chuck to analyze and to coordinate with Accellera LRM committee.

TOPIC: IR 2083 Generate index specification should be of same subtype
as generate parameter

The submitter is correct: there are no rules requiring either type or
subtype compatibility between ranges in block configurations and
corresponding generate statements.

ACTION: Chuck to analyze.

TOPIC: IR 2080 Case expression should include parenthesized expression

The IR is ready for an ISAC vote.

ACTION: Chuck to submit for vote.

TOPIC: IR 2075 Arrays with numeric and enumeration index types are not
closely related

The analysis is accurate. The proposal for type conversions where the
target type is unconstrained seems to be very reasonable: the proposal
suggest that the direction come from the (unconstrained) target type.
An alternate proposal to take the direction from the source expression
seems less desirable, because the direction could vary for different
executions of the expression.

ACTION: Ajay to make minor revisions (done). Chuck to submit for
vote.