IR 1040 "Bailey, Stephen A (Steve)" : Yes, with comments "Serafin Olcoz" : Yes "Paul J. Menchini" : Yes cswart@analogy.com: No, with comments Peter J. Ashenden: Yes Philip Wilsey: Yes Kawarabayashi: Yes Summary: Carried, with one dissenting vote. IR 1081 "Bailey, Stephen A (Steve)" : Yes "Serafin Olcoz" : Yes "Paul J. Menchini" : Yes Peter J. Ashenden: Yes John Willis: Yes Philip Wilsey: Yes Kawarabayashi: Yes Summary: Nem con. IR 1086 "Bailey, Stephen A (Steve)" : Yes "Doug Dunlop" : Yes, with comments "Serafin Olcoz" : Yes "Paul J. Menchini" : Yes, with comments cswart@analogy.com: Yes, with comments Peter J. Ashenden: Yes Philip Wilsey: Yes Kawarabayashi: Yes Summary: Nem con, but there may be further related issues to consider. IR 1117 "Bailey, Stephen A (Steve)" : No, with comments cswart@analogy.com: Yes, with comments "Paul J. Menchini" : Yes, with comments "Serafin Olcoz" : Yes "Doug Dunlop" : Yes Peter J. Ashenden: Yes : responded, but did not enter a vote Philip Wilsey: Yes Kawarabayashi: Abstain Summary: Strenuous objection from Steve. Need to review to see if we have agreement on interpretation of current LRM, and whether we want to change it in '98 or later. IR 1124 "Bailey, Stephen A (Steve)" : Yes "Serafin Olcoz" : Yes "Paul J. Menchini" : Yes cswart@analogy.com: Yes, with comments Peter J. Ashenden: Yes Philip Wilsey: Yes Kawarabayashi: Yes Summary: Nem con. ---------------------------------------------------------------- Comments on IR1040 ------------------ From: "Bailey, Stephen A (Steve)" These thoughts are half-baked. Because of the near-universal adoption of 1164, this issue does not have the import that it once had. Because of the diminished import, it might not be worth the effort of fully exploring these half-baked thoughts. It seems that the major issue is defining a set of related subtypes that differ only in the resolution applied. It seems to me that we could consider a limited relaxation of the requirement that all elements of a composite type be constrained. Specifically, the relaxation could be made within the context of the subtype indication of the (single) parameter to a resolution function that would make the following legal: type unc_vector_type is array(Natural range <>) of my_logic_type; function my_resolve( V : array(Natural range <>) of unc_vector_type ) return unc_vector_type; subtype resolved_vector_type is my_resolve unc_vector_type; subtype resolved_vector_type8 is resolved_vector_type(7 downto 0); The reason this relaxation of the existing requirements could work is that resolution functions must have a certain "profile." The input parameter must be an unconstrained array of some element type and the function must return that element type. Also, the resolution function must be used in a subtype indication. Such a change would require that all sources to the same resolution must be of the same length to avoid potential problems. Likewise, it would be an error (or erroneous model) if the resolution function returns a value that differs in length from the length of the sources. From: cswart@analogy.com In the analysis, it is claimed that the language should be kept as is, and that generics could be used to add constraints to unconstrained ports. This IR deals with a very difficult issue. See, for example LCS-0011 for VHDL 93. The IR was carried forward to serve as a reminder that this difficult problem does not have a good solution within current VHDL semantics. The proposed "No change" recommendations do not address that fact. ---------------------------------------------------------------- Comments on IR1086 ------------------ From: "Doug Dunlop" Aren't there other outstanding issues associated with generalized aliasing? These ought to be input to the VHDL '98 group. From: "Paul J. Menchini" The proposed restrictions do not go far enough (as the analysis suggests). I would like to see stronger restrictions on aliases, but I have not yet had the time to analyze the situation to determine what they should be. From: cswart@analogy.com However, this IR was supposed to be a resting place for a number of issues involving extended aliases. I am disappointed that those issues have not been identified. ---------------------------------------------------------------- Comments on IR1117 ------------------ See separate file, IR1117-comments.txt ---------------------------------------------------------------- Comments on IR1124 ------------------ From: cswart@analogy.com the author's analysis looks good to me. However, I would like to see a non-normative note added to the LRM which shows the equivalent single association map formed by the combination of the incremental binding with the primary binding. This would make it unnecessary to follow the rather difficult logic to reach the conclusion which the author made.