Minutes of ISAC meeting held via telecom on 10 November 2005 Present: Peter Ashenden, Larry Soule, Chuck Swart, Ajay Verikat Absent: Jim Lewis, Deepak Pant Next Meeting: Thursday December 1, 2005, 6 pm Pacific Standard Time (Friday December 2, 2005, 2 am GMT) TOPIC: Newly voted IRs: 2020, 2053 2059 These IRs were approved without comments. ACTION: Chuck to update website and forward to VASG chair, VHDL-Accellera chair. TOPIC: IR 2029 Non-relevant words and paragraph. One dissenting vote pointed out that the phrase "composite type with a subelement that is an access type" is not correct and should be changed, because a subelement is an access type. The ISAC concluded that the proposed new wording is consistent with the current wording, and that the reviewer's comment is really a new issue. There may be many cases of similar wording in the LRM. Therefore, we will accept IR 2029 as currently worded, issue a new IR on the element subtype issue, and identify IR 2029 as related to the new IR.(Note: new IR is 2077 "Incorrect wording on some language constructs".) ACTION: Chuck to update website and forward IR 2029 to VASG chair and VHDL-Accellera chair. Chuck to issue new IR on submitter's issue. TOPIC: IR 2031 "mod" function needed for TIME There was one dissenting vote which pointed out some wording inconsistencies. ACTION: Chuck to edit IR 2031 to fix these inconsistencies, then forward the IR to VASG chair and VHDL-Accellera chair. TOPIC: IR 2061 Default actions on severity flags is different between simulators One dissenting vote pointed out two issues. First, the proposed solution mentions that the simulator "should continue execution of a model after displaying..." This should be reworded to respond to the execution of the statement, not the display of information. The ISAC agrees. It was also noted that for some reason the LRM mentions the "evaluation" of assert and report statements instead of the "execution" of these statements. This problem will be raised in the new IR mentioned in discussion of IR 2029. Second, the dissenting voter gives a rephrasing of the proposed wording in the IR which the ISAC feels is less clear than the original IR wording. Therefore, the suggested rewording will not be adopted. ACTION: Chuck to edit IR2061 and to add issues to the new IR. Chuck to forward IR 2061 to VASG chair and VHDL-Accellera chair. TOPIC: Forwarding ISAC-approved IRs to the VASG for VASG-approval. We decided not to submit ISAC-approved IRs as they become available, but instead to batch them together. We will forward them about once a quarter. There are now several IRs which should be voted on by the VASG. Peter is no longer willing to handle the VASG voting. Chuck will work with the VASG chair to resolve this. Most likely either Jim Lewis will handle this (in anticipation of becoming VASG chair) or Chuck will do the work. ACTION: Chuck to work this out with VASG chairs (current and future). TOPIC: IR 2075 Arrays with numeric and enumeration index types are not closely related The submitter asks that we relax the restrictions on type conversions to allow conversion of two arrays with the same dimensionality and the same element type, even though the index types are not closely related. The general idea is that it makes sense if the arrays have the same "sizes" and the same element types: there is no fundamental reason to require the index subtypes be related. This argument is persuasive when the target type mark denotes a constrained array subtype. There is, however, a technical problem when the type mark denotes an unconstrained array type. Currently, in this case there is a check that "the bounds of the result belong to the corresponding index subtype of the target type." This check does not make sense when the index types are not closely related. One solution is to allow type conversions with unrelated index types only for targets which are constrained array subtypes. Another solution is to allow such conversions and to choose the bounds (and perhaps direction) as in concatenation. An alternative would be to choose direction from the expression being converted. ACTION: Ajay to analyze. ITEM: IR 2076 A member attribute for records The utility of a record iterator is far from clear, since the iterator index would range over various types. A more complete use case is needed to understand just what problem is being solved. This request would require significant language changes and is beyond the scope of the ISAC. ACTION: Chuck to contact submitter for clarification and to forward IR as an enhancement. TOPIC: IR2038 Minor semantic errors Ajay has agreed to take over the analysis from Peter. ACTION: Ajay to analyze. TOPIC: IR 2054 Individual assoc. rules for array formal are not valid Larry's analysis was reviewed. It was agreed that the words "or member..." should be removed from the suggested solution to issue 2. This is a complicated IR which needs careful review. ACTION: Chuck to make agreed upon revision, then to submit to ISAC for review. ALL to review. We will discuss and vote on this at the next meeting. TOPIC: IR 2070 Support for floating point denormal numbers It was suggested that a note be added to the LRM to remind language users that exact comparison of floating point values is dangerous and that all such comparisons should be performed within some epsilon value. (Added in review, Annex C identifies several uses of floating point values as nonportable. This should suffice.) It is believed that the submitter wants to compare mathematical simulation results with results obtained by his VHDL packages which implement fixed and floating point arithmetic. If this is the case, then he would probably do better to prepare golden files for comparison, since the operations he performs are nonportable. ACTION: Chuck to revise the IR, send it to submitter for review, then send to ISAC for email vote. TOPIC: IR 2071 Indexed name in case expression The submitter is essentially correct. The indexing expressions need not be locally static, but the element subtype must be locally static. ACTION: Chuck to analyze, then ALL to vote. TOPIC: IR 2072 Allow static operations on "ranges" The submitter was asked for clarification and has not yet responded.