Peter, I am reading LCS 113 in connection with IR2054 as well as some parts of IR2038. The wording of the new bullet added on page 6 of the LCS (version 1.5) caused some confusion for me initially. The way it is written, this bullet has several sub-bullets that address different cases, and it was difficult for me to verify any overlap or holes in the coverage. One of the items from IR2038 mentions exactly such issues in this section of the LRM. I have a suggestion for a slightly different organization. Please see if this makes any sense. The current organization appears to be on the following lines. - For array type interface object or array type subelement - Formal declared with index constraints - Formal declared without index constraints - Multiple association elements OR Single association element, and formal a slice - Associated in whole OR Single association element, and formal not a slice Is this right? If so, I was wondering whether this would be better organized as follows, where the complementory cases are grouped together: - For array type interface object or array type subelement - Formal declared with index constraints - Formal declared without index constraints a) Single association element i) Associated in whole ii) Formal not a slice iii) Formal a slice b) Multiple association elements The description about how to address these cases would remain more or less unchanged. Items (a)(i) and (a)(ii) could share the description, while (a)(iii) and (b) could have the same description. Regards, -ajay ----- Original Message ----- From: "Chuck Swart" <cswart@model.com> To: <isac@eda.org> Sent: Wednesday, April 19, 2006 5:18 AM Subject: ISAC: updates for Thursday's ISAC meeting > IRs 2074 and 2086 have been updated. > LCS 113 supersedes IR 2054. > This LCS has deep consequences, so I would like > you to read it carefully. But if you don't have time > the area aroung page 6 deals most closely with IR 2054. > > If you can't get access to LCS 2006-113, let me know and I'll > send you a copy (The isac mailing list won't accept it because > it places a Draconian limit on file sizes) > > Also, in my notes for IR 2074 I have a statement: > > "There was also confusion about wording regarding actuals. The > visibility rules favoring select names are intended to > apply to local parameters used as actuals, not to all actuals." > > Can anyone speak to the reason for this? I thought that clauses h) > through m) were pretty clear about this. > > > -------------------------------------------------------------------------------- > > > VHDL Issue Number: 2074 > > Language_Version: VHDL-2002 > Classification: Language Definition Problem > Summary: Problem with direct/select visibility in formal part > Relevant_LRM_Sections: 4.3.2.2, 10.3 > Related_Issues: 0006 > Key_Words_and_Phrases: > Authors_Name: Chuck Swart > Authors_Phone_Number: 503.685.0846 > Authors_Fax_Number: 503.685.0921 > Authors_Email_Address: cswart@model.com > Authors_Affiliation: Model Technology > Authors_Address1: 8005 SW Boeckman Road > Authors_Address2: Wilsonville, OR 97070 > Authors_Address3: > > Current Status: Analyzed > > Superseded By: > > ------------------------ > Date Submitted: 12 September 2005 > Date Analyzed: 10 November 2005 > Author of Analysis: Chuck Swart and Ajayharsh Varikat > Revision Number: 3 > Date Last Revised: 18 April 2006 > > Description of Problem > ---------------------- > Consider the following two VHDL code fragments: > > A) > > LIBRARY ieee; > USE ieee.std_logic_1164.ALL; -- X01 becomes visible as a subtype > ENTITY e1... > ... > ARCHITECTURE a1 OF e1 IS > COMPONENT c1 IS > PORT(X01: IN std_logic); > BEGIN > instance1: c1 PORT MAP ( X01(X01)=> s1); > END a1; > > B) > > PACKAGE p2 IS > constant X01: integer := 1; > subtype bv1 is bit_vector(1 TO 1); > END p2; > > LIBRARY ieee; > USE work.p2.ALL; --X01 and bv1 become visible > ENTITY e2... > ... > ARCHITECTURE a2 OF e2 IS > COMPONENT c1 IS > PORT(X01: IN bv1); > BEGIN > instance1: c1 PORT MAP ( X01(X01)=> s2); > END a2; > > Are either of these legal VHDL? > > In example A) there are two possible interpretations: > > 1. The leftmost X01 is a type mark (with direct visibility) and the > X01 inside the parentheses is a formal designator. This expression is > legal. > > 2. The leftmost X01 is a port name (with visibility by selection) > indexed by a subtype, which in this case is illegal. > > In example B) there are also two possible interpretations, with the > legal/illegal cases reversed from example A) with respect to direct > visibility and visibility by selection: > > 1. The leftmost X01 is a constant name (with direct visibility) and > the expression inside the parentheses is a port name. This construct > is clearly illegal. > > 2. The entire term is a formal designator, which reduces to an indexed > name. The leftmost X01 is a port name (with visibility by selection) > and the X01 inside the parentheses is an index expression. > > The grammar allows > formal_part ::= > formal_designator > |<function>_name ( formal_designator) > | type_mark ( formal_designator ) > > The name of the formal designator is visible by selection while the > name of the type_mark (and the index expression in example B) are > directly visible. > > So the question reduces to what visibility rules are used to analyze: > > X01(X01) > > which can be interpreted syntactically as either type_mark ( > formal_designator) or simple formal_designator? > > Given the visibility rules of 10.3, it is hard to tell if directly > visible names take priority over names visible by selection, or > vice-versa. If direct visibility has priority then interpretation 1 > applies to both examples, making example A) legal and example B) > illegal. If selected visibility has priority, then interpretation 2 > applies, making example B) legal and example A) illegal. > > If one were to argue that interpretation 1 applies to example A) and > interpretation 2 applies to example B) then the visibility rules would > be context dependent (or even more context dependent than current > rules). > > The syntactic ambiguity in the formal_part rule is the major area (if > not the only area) in which the rules for direct visibility conflict > with those for visibility by selection. The closest analogy is the > potential conflict between selected names and expanded names described > in IR0006. This conflict is resolved by adopting the expanded name > interpretation. > > I believe that different simulators interpret the two test cases in > different ways, so this issue should be resolved to improve > portability of the language. > > Proposed Resolution > ------------------- > > Adopt a rule stating that in formal parts selected names hide directly > visible names ( or vice-versa). This would make both examples illegal. > Other solutions are possible, but the important thing is to not make > the visibility rules context sensitive. In particular, interpretations > A 1 and B 2 should not both be legal. > > VASG-ISAC Analysis & Rationale > ------------------------------ > > The specific places at which such a conflict could occur are (from > clause 10.3 of the LRM) > > "h) For a formal parameter declaration of a given subprogram > declaration: at the place of the formal designator in a formal > part (before the compound delimiter =>) of a named parameter > association element of a corresponding subprogram call. > > i) For a local generic declaration of a given component declaration: > at the place of the formal designator in a formal part ( before the > compound delimiter =>) of a named generic association element of a > corresponding component instantiation statement: similarly, at the > place of the actual designator in an actual part (after the > compound delimiter =>, if any) of a generic association element of a > corresponding binding indication. > > j) For a local port declaration of a given component declaration: at > the place of the formal designator in a formal part (before the > compound delimiter =>) of a named port association element of a > corresponding component instantiation statement; similarly, at the > place of the actual designator in an actual part (after the > compound delimiter =>, if any) of a port association element of a > corresponding binding indication. > > k) For a formal generic declaration of a given entity declaration: at > the place of the formal designator in a formal part (before the > compound delimiter =>) of a named generic association element of a > corresponding binding indication; similarly at the place of the > formal designator in a formal part (before the compound delimiter > => of a generic association element of a corresponding component > instantiation statement when the instantiated unit is a design > entity or a configuration declaration. > > l) For a formal port declaration of a given entity declaration: at the > place of the formal designator in a formal part (before the > compound delimiter =>) of a named port association element of a > corresponding binding specification; similarly, at the place of the > formal designator in a formal part (before the compound delimiter > =>) of a port association element of a corresponding component > instantiation statement when the instantiated unit is a design > entity or a configuration declaration. > > m) For a formal generic declaration or a formal port declaration of a > given block statement: at the place of the formal designator in a > formal part( before the compound delimiter =>) of a named > association element of a corresponding generic or port map aspect." > > The ISAC agrees that there should be a clear rule to determine > visibility when there is a potential conflict between direct > visibility and visibility by selection. It is preferable to choose > visibility by selection over direct visibility because a declaration > which is no longer directly visible can often be accessed by other > mechanisms. > > In conclusion, the ISAC recommends that the syntactic ambiguity > indicated in the problem description be resolved in favor of > formal_designator, with a similar interpretation for actual_designator. > > Note that the above LRM sections apply visibility by selection to > formal and actual designators, not to formal or actual parts. If > visibility is to be used to distinguish the cases under discussion it > is beneficial to extend select visibility to the entire formal or > actual parts. > > With this interpretation the leftmost X01 in example A) is interpreted > as a port name, so the example is illegal. > > Example B) is also illegal: Both references to X01 refer to the port > name, so the example is semantically illegal. > > > VASG-ISAC Recommendation for IEEE Std 1076-2002 > ----------------------------------------------- > > Interpret the LRM as if the Recommendation for Future Revisions were > in effect. > > VASG-ISAC Recommendation for Future Revisions > --------------------------------------------- > > In items h) through m) in clause 10.3 replace each occurrence of > > "at the place of the formal designator in a formal part" > > with > > "at the place of the formal part" > > and replace each occurrence of > > "at the place of the actual designator in an actual part" > > with > > "at the place of the actual part". > > Add wording similar to the following to clause 10.3 immediately > after the existing paragraph that begins with "A declaration is > said to be hidden...": > > "At a place in which a declaration is visible by selection every > declaration with the same designator which would otherwise be directly > visible is hidden." > > > > -------------------------------------------------------------------------------- > -------------BEGINNING OF IR---------------- > > VHDL Issue Number: 2086 > > Language_Version VHDL-2002 > Classification Language Definition Problem > Summary Incorrect description of type mark in disconnection > specification > Relevant_LRM_Sections 5.3 Disconnection specification, page 85 > Related_Issues > Key_Words_and_Phrases disconnection specification, type mark > Authors_Name Peter Ashenden > Authors_Phone_Number +61 414 709 106 > Authors_Fax_Number > Authors_Email_Address peter@ashenden.com.au > Authors_Affiliation Ashenden Designs > Authors_Address1 > Authors_Address2 > Authors_Address3 > > Current Status: Analyzed > > Superseded By: > > ------------------------ > Date Submitted: 8 February 2006 > Date Analyzed: 13 March 2006 > Author of Analysis: Chuck Swart > Revision Number: 2 > Date Last Revised: 18 April 2006 > > Description of Problem > ---------------------- > > In the last paragraph of page 85, the first sentence reads: > > If the guarded signal is a declared signal or a slice thereof, > the type mark must be the same as the type mark indicated in the > guarded signal specification (see 4.3.1.2). > > Since the paragraph describes a guarded signal specification, it > appears that the first type mark referred to in the sentence is the > type mark in the guarded signal specification. Thus, the sentence > appears to state, tautologically, that the type mark must be the same > as itself. > > Subsequent sentences in the paragraph state that, for other forms > of signal name, the type mark must be the same as the type mark in a > declaration of the signal. Thus, it would appear that the first > sentence should say that the type mark be the same as the type mark in > the declaration of the signal, not the same as itself. > > A further problem is that the paragraph only deals with a declared > signal, a slice of a declared signal, an element of a declared array > signal, and an element of a declared record signal. It does not deal > with other members of a composite signal. > > Proposed Resolution > ------------------- > > Amend the tautological description to refer to the type mark of the > subtype indication in the signal declaration. > > Revise the case analysis to cover the cases: > > - A declared signal or a slice of a declared signal: the type mark > must be the same as that in the signal's declaration; > > - A slice of an array subelement of a composite signal: the type > mark must denote the same subtype as the array element's > subtype; > > - An element of an array subelement of a composite signal: the > type mark must denote the same subtype as the element subtype > indication in the declaration of the array type; > > - An element of a record subelement of a composite signal: the > type mark must denote the same subtype as the element subtype > indication in the declaration of the record type. > > VASG-ISAC Analysis & Rationale > ------------------------------ > > The submitter is essentially correct. However, the LRM seems to impose > a more stringent requirement involving type mark matching instead of > subtype matching. So the wording in the proposed solution should be > changed as indicated below. In addition, for consistency, on page 86, > the first sentence should also be changed in a similar manner > (indicated below). > > VASG-ISAC Recommendation for IEEE Std 1076-2002 > ----------------------------------------------- > > Interpret the LRM as if the Recommendation for Future Revisions were > in effect. > > VASG-ISAC Recommendation for Future Revisions > --------------------------------------------- > > Clause 5.3 Disconnection specification > > The paragraph beginning: > > "If the guarded signal is a declared signal or a slice thereof..." > > Should read: > > "If the guarded signal specification denotes a declared signal or > a slice thereof then the type mark in the specification must be > the same as the type mark in the subtype indication of the guarded > signal declaration (see 4.3.1.2). > > If the guarded signal specification denotes an index value of a > declared signal then the type mark in the specification must be > the same as the type mark of the element subtype indication in the > declaration of the array type of the guarded signal declaration. > > If the guarded signal specification denotes a slice of an array > subelement of a composite signal then the type mark must be the > same as the type mark in the subtype indication of the array > subelement declaration. > > If the guarded signal specification denotes an element of an array > subelement of a composite signal then the type mark must be the > same as the type mark of the element subtype indication in the > declaration of the array type. > > If the guarded signal specification denotes a record element of a > composite signal then the type mark must be the same as the type > mark of the element subtype indication in the declaration of the > record type. > > Each signal must be declared in the declarative part enclosing the > disconnection specification." > > The paragraph beginning: > > "Subject to the aforementioned rules, a disconnection > specification applies to the drivers of a guarded signal S of > whose type mark denotes the type T..." > > Should read: > > "Subject to the aforementioned rules, a disconnection > specification applies to the drivers of a guarded signal S > specified with type mark T..." > > > > > -------------END OF IR---------------- >Received on Thu Apr 20 07:20:20 2006
This archive was generated by hypermail 2.1.8 : Thu Apr 20 2006 - 07:20:22 PDT