Minutes of ISAC meeting held via telecom on 20 October 2004. Present: Peter Ashenden, Deepak Pant, Chuck Swart, Ajay Varikat Absent: Jim Lewis Next Meeting: 04 November 2004 7pm Pacific Time (8:30 am in India) TOPIC: IR2028: Clarify Simulation Cycle Peter presented his analysis. There is some ambiguity in the description of the initialization phase which under step c) lists: 1... 2... 3... These steps are not intended to be ordered, and the wording could be clarified to clearly indicate which actions are sequential and which are non-sequential. ACTION: Peter to update the analysis reflecting these suggestions. TOPIC: IR2039: Minor typos This was approved. ACTION: Chuck to forward to VASG. TOPIC: IR2040: Problems with OTHERS in aggregates More discussion of assigning a subtype to a slice. Doug Dunlop was contacted and he didn't see any obvious problems with doing this. However, it was determined that we should solve the issues in this IR without assuming that a subtype has a slice ACTION: Ajay to complete analysis TOPIC: IR2041: Association of members is too restricted A fast track item has been issued which deals with this. A basic problem with partial open mapping for signals which are resolved at the composite level is that initial values don't supply a source, and composite resolved signals must have sources for all subelements. One possible way around this is to view the default value as the initial value for an implicitly declared signal. Also, note that section 1.1.1.2 has restrictions which affect this. ACTION: Chuck to reanalyze. TOPIC: IR2042: Architecture as a block causes problems Peter supplied documentation on the history of this problem. A fundamental issue is whether the architecture name denotes a subregion of the declarative region indicated by the entity, or whether the architecture name is, in effect, an alias for the entity name. ACTION: Peter to continue analysis. Chuck to research ancient IR which deals with this. TOPIC: IR2043: Numeric VALUE attribute parameter can't have sign There was general agreement that this is an unintended defect. It was also noted that IMAGE is incompletely specified, since it doesn't state whether or not positive integers may or must have a sign. It was agreed that IMAGE and VALUE should be inverses of each other in general, although IMAGE has non-unique representations of numeric values. ACTION: Deepak was drafted to analyze. TOPIC: IR2044: Deprecation of linkage ports affects boundary scan description language It was agreed that since BSDL uses linkage ports, they should not be removed from the language. A note could be added to the VHDL LRM stating that BSDL uses these. ACTION: Peter to update the IR, Chuck to analyze. TOPIC: IR2045: Add the ability to comment an entire block of code It was agreed that this feature is useful. As a practical matter /*...*/ are probably the best choices. ACTION: Peter to update the IR, ALL to vote. TOPIC: IR2000: Where may/must deferred constant declaration appear The wording for deferred constants is not completely correct. It should be replaced by something like: "It is an error if such a declaration appears other than..." ACTION: Chuck to analyze. TOPIC: IR2001: Resize not working in numeric_std.vhd (1076.3 IR2002: Resize(R.2) function in numeric_std.vhd does improper array length check These issues are appropriate for WG 1076.3, which no longer exists. There is a general question about the role of the ISAC for packages, VHPI, and other "non-core" areas. Will there be other technical committees to address these issues, or will the ISAC import experts, or is there some other approach which we should take. As far as the specific issues raised by these IRs, Peter will look at the code, and Chuck will contact Dave Bishop to get his opinion. For the general issues, Chuck will communicate with VASG chair about these concerns. ACTION: Peter to look at source code, Chuck to communicate with Dave Bishop and Steve Bailey. TOPIC: IR2003: Specification of multi-cycle paths This is an enhancement request and is not an ISAC issue. It may be related to IR2035. ACTION: Chuck to forward to VHDL 200x steering committee. TOPIC: IR2004: Definition of SLA doesn't make sense The submitter correctly states that the semantics of SLA don't match any existing RTL design. The operator was included for symmetry, and it was intended that it either not be used by current designs or that it be overloaded to provide intended behavior. ACTION: Chuck to analyze.