Re: [vhdl-200x] Issue with VHDL name attributes

All,

I have to disagree with the proposal.
Adding addition scopes to the pathname raises several issues.

1) Compatibility

2) Cross module references
    The statement
     "In proposing these changes, I note that the values of the attributes will be
      different from those produced under earlier versions of the standard. However,
      if the usage model for these attribute values is just to display them as part
      of informational messages or to use them for navigation in an interactive tool,
      the validity of existing models would not be affected."
    Cross module references would need to support the new pathname form. This raise the
    question does the old form of pathnames work if it is unambiguous? Does the VHPI
    look up by name support the old form with the same restrictions?

3) There is still a fundamental problem with the architecture being a scope
    inside of the entity. If you have X declared in the architecture and in the entity
    and the entity and architecture have the same name, say E, you can't access the entity's X.
    Because E.X refers to the architecture's X. If E.<name> referred to objects in the
    entity's scope, selected names to everything in an architecture would have to be
    E.E.<name>. This would break compatibility with older designs.

I had thought Chuck Swart had raised an issue making the architecture a nested scope in 2002 for
just this reason. To put words in Chuck's mouth he thought the only reason for adding the
nested scope was to clean up the problem of having an architecture named the same as the entity.
The 2002 change seems to raise as many issues as it fixes.

On the procedural scope, I think that it is good for VHPI team should identitfy issues like this
and propose solutions. I don't think that they should be actually changing the LRM to
implement these solutions. Ideally they would raise the issue, propose a solution, the
ISAC would comment and it would be folded into the VHDL-200x fast track changes.

Regards,
   John

Bailey, Stephen wrote:
> All,
>
> The proposed correction looks good. I do believe it is within the scope of 1076b. Hopefully, the scope issue will be irrelevant as the plan still is for a new revision PAR to include the VHDL 200x (fast-tracked), 1164, 1604 and VHPI capabilities all within the next revision. But, even if that doesn't happen (whatever the reason), the existing 1076b PAR scope would cover this correction due to the dependency with VHPI.
>
> -Steve Bailey
>
>
>>Folks,
>>
>>The VHPI team proposes to specify a property, called
>>vhpiFullNameP, that
>>provides a string representation of the path name to an item in a VHDL
>>model. The proposal is to define the property in terms of
>>the 'path_name
>>predefined attribute.
>>
>>An issue is that there is a deficiency in the definition of
>>'path_name (and
>>also 'instance_name) in the 1076-2002 LRM. We revised the
>>definition of
>>declarative regions to specify that an architecture body
>>declarative region
>>is logically nested within the entity declaration declarative
>>region. This
>>allows you, among other things, to declare architecture e of e without
>>breaking the scope rules.
>>
>>It also allows you to declare an object x in entity e and a
>>second object x
>>in a corresponding architecture, say a. The architecture's x
>>hides the
>>entity's x, but you can get at the entity's x within the
>>architecture using
>>an expanded name (e.x). However, both x's have the same 'path_name
>>attribute. If e(a) is instantiated with label c in
>>architecture top_a of
>>top_e, then
>>
>> e.x'path_name = ":top_e:c:x"
>> e.a.x'path_name = ":top_e:c:x"
>>
>> e.x'instance_name = ":top_e(top_a):c@e(a):x"
>> e.a.x'instance_name = ":top_e(top_a):c@e(a):x"
>>
>>I believe this is an oversight. When we added the rule covering the
>>declarative region of an architecture body, we overlooked the
>>implication
>>for these attibutes.
>>
>>I propose to correct this oversight in the P1076b amendment
>>specifying the
>>VHPI. That will allow us to specify the vhpiFullNameP
>>property in terms of
>>the 'path_name attribute correctly.
>>
>>My proposed correction is to treat the entity and
>>architecture as separate
>>elements in the path names. This corresponds properly to the
>>nesting of
>>declarative regions. The changes in Clause 14.1 are as follows:
>>
>>In the description of the 'instance_name attribute:
>>
>>- Change the BNF rules for full_path_instance_element to
>>
>> full_path_instance_element ::=
>> [ component_instantiation_label @ ]
>> entity_simple_name
>> | architecture_simple_name
>> | block_label
>> | generate_label
>> | process_label
>> | loop_label
>> | subprogram_simple_name signature
>>
>>- In the fourth paragraph after the BNF rules, insert
>>"architecture body, "
>> after the words "component instantiation, ".
>>
>>- Replace the fifth paragraph after the BNF rules with
>>
>> A full path instance element in the form of an architecture
>>simple name
>> must be immediately preceded by a full path instance
>>element in the form
>> that includes an entity simple name. In that case, the architecture
>> simple name must denote an architecture associated with the entity
>> declaration designated by the entity simple name. A full path
>> instance element in the form that includes an entity simple
>>name must
>> also include the component instantiation label (and the
>>commercial at
>> following it) unless the entity simple name denotes the entity
>> declartion of the root design entity.
>>
>>In the description of the 'path_name attribute:
>>
>>- Change the BNF rules for path_instance_element to
>>
>> path_instance_element ::=
>> component_instantiation_label
>> | entity_simple_name
>> | architecture_simple_name
>> | block_label
>> | generate_label
>> | process_label
>> | subprogram_simple_name signature
>>
>>- In the third paragraph after the BNF rules, insert
>>"architecture body, "
>> after the words "component instantiation, ".
>>
>>In the Examples declaration of entity e, change the values
>>shown in comments
>>as follows:
>>
>>-- e'instance_name = ":e:"
>>
>>-- g'instance_name = ":e:g"
>>
>>-- p'instance_name = ":e:p"
>>
>>In the Examples declaration of architecture a of e, add the following
>>comments to the end of the first line of the architecture body:
>>
>>-- a'path_name = ":e:a:"
>>-- a'instance_name = ":e:a:"
>>
>>Also in the Examples declaration of architecture a of e,
>>change the values
>>shown in comments as follows:
>>
>>-- S'PATH_NAME = ":e:a:s"
>>-- S'INSTANCE_NAME = ":e:a:s"
>>
>>-- Proc1'PATH_NAME = ":e:a:proc1[natural,integer]:"
>>-- Proc1'INSTANCE_NAME = ":e:a:proc1[natural,integer]:"
>>
>>-- C'PATH_NAME = ":e:a:proc1[natural,integer]:c"
>>-- C'INSTANCE_NAME = ":e:a:proc1[natural,integer]:c"
>>
>>-- max'PATH_NAME = ":e:a:proc1[natural,integer]:max"
>>-- max'INSTANCE_NAME = ":e:a:proc1[natural,integer]:max"
>>
>>-- T'PATH_NAME = ":e:a:p1:t"
>>-- T'INSTANCE_NAME = ":e:a:p1:t"
>>.
>>.
>>.
>>-- T'PATH_NAME = ":e:a::t"
>>-- T'INSTANCE_NAME = ":e:a::t"
>>
>>Change the Examples declaration of architecture bottomarch of
>>bottom to:
>>
>>architecture BottomArch of Bottom is
>> signal SBottom : INTEGER;
>>begin
>> ProcessBottom : process
>> variable V : INTEGER;
>> begin
>> if GBottom = 4 then
>> assert V'Simple_Name = "v"
>> and V'Path_Name = ":top:top:b1:b2:g1(4):b3:l1:processbottom:v"
>> and V'Instance_Name =
>>
>>":top:top:b1:b2:g1(4):b3:l1@bottom:bottomarch:processbottom:v";
>> assert GBottom'Simple_Name = "gbottom"
>> and GBottom'Path_Name = ":top:top:b1:b2:g1(4):b3:l1:gbottom"
>> and GBottom'Instance_Name =
>> ":top:top:b1:b2:g1(4):b3:l1@bottom:bottomarch:gbottom";
>> elsif GBottom = -1 then
>> assert V'Simple_Name = "v"
>> and V'Path_Name = ":top:top:l2:processbottom:v"
>> and V'Instance_Name =
>> ":top:top:l2@bottom:bottomarch:processbottom:v";
>> assert GBottom'Simple_Name = "gbottom"
>> and GBottom'Path_Name = "top:top:l2:gbottom"
>> and GBottom'Instance_Name =
>> ":top:top:l2@bottom:bottomarch:gbottom";
>> end if;
>> wait;
>> end process ProcessBottom;
>>end architecture BottomArch;
>>
>>Change the Examples declaration of architecture Top of Top to:
>>
>>architecture Top of Top is
>> component BComp is
>> generic (GComp : INTEGER)
>> port (PComp : INTEGER);
>> end component BComp;
>> signal S : INTEGER;
>>begin
>> B1 : block
>> signal S : INTEGER;
>> begin
>> B2 : block
>> signal S : INTEGER;
>> begin
>> G1 : for I in 1 to 10 generate
>> B3 : block
>> signal S : INTEGER;
>> for L1 : BComp use entity Work.Bottom(BottomArch)
>> generic map (GBottom => GComp)
>> port map (PBottom => PComp);
>> begin
>> L1 : BComp generic map (I) port map (S);
>> P1 : process
>> variable V : INTEGER;
>> begin
>> if I = 7 then
>> assert V'Simple_Name = "v"
>> and V'Path_Name = ":top:top:b1:b2:g1(7):b3:p1:v"
>> and V'Instance_Name=":top:top:b1:b2:g1(7):b3:p1:v";
>> assert P1'Simple_Name = "p1"
>> and P1'Path_Name = ":top:top:b1:b2:g1(7):b3:p1:"
>> and P1'Instance_Name = ":top:top:b1:b2:g1(7):b3:p1:";
>> assert S'Simple_Name = "s"
>> and S'Path_Name = ":top:top:b1:b2:g1(7):b3:s"
>> and S'Instance_Name = ":top:top:b1:b2:g1(7):b3:s";
>> assert B1.S'Simple_Name = "s"
>> and B1.S'Path_Name = ":top:top:b1:s"
>> and B1.S'Instance_Name = ":top:top:b1:s";
>> end if;
>> wait;
>> end process P1;
>> end block B3;
>> end generate;
>> end block B2;
>> end block B1;
>> L2 : BComp generic map (-1) port map (S);
>>end architecture Top;
>>
>>
>>In proposing these changes, I note that the values of the
>>attributes will be
>>different from those produced under earlier versions of the standard.
>>However, if the usage model for these attribute values is
>>just to display
>>them as part of informational messages or to use them for
>>navigation in an
>>interactive tool, the validity of existing models would not
>>be affected.
>>
>>Correcting the description of the attributes will enable
>>simplification of
>>definition of the vhpiFullNameP property and will ensure that
>>the property
>>and the attributes are mutually consistent. VHPI programs
>>will make use of
>>the property for more than just information display, so it is
>>important that
>>the property's description is done correctly and consistently from the
>>outset, as future changes to the description will affect backward
>>compatibility for VHPI programs.
>>
>>
>>As an incident further correction, the third sentence of Note
>>9 at the end
>>of Clause 14.1 is no longer correct, since signatures were
>>added to path
>>instance elements and full path instance elements. I propose
>>to delete the
>>sentence.
>>
>>
>>VHPI Task Team: Comments? Could you please discuss and
>>eventually approve
>>(or otherwise)?
>>
>>Steve, I'm posting this to the VHDL-200x list for information
>>because it's
>>not simply a matter of definition of VHPI functionality. Rather, it's
>>correction of base functionality in order to facilitate VHPI
>>definition.
>>Hence, I would argue that it's still in scope for the P1076b
>>amendment.
>>Would you care to comment?
>>
>>Of course, comments for all quarters welcome. Thanks.
>>
>>Cheers,
>>
>>PA
>>
>>--
>>Dr. Peter J. Ashenden peter@ashenden.com.au
>>Ashenden Designs Pty. Ltd. www.ashenden.com.au
>>PO Box 640 Ph: +61 8 8339 7532
>>Stirling, SA 5152 Fax: +61 8 8339 2616
>>Australia Mobile: +61 414 70 9106
>>
>>
>

-- 
-- mailto: johnr@model.com     phone: (503)685-0864
--   http://www.model.com        fax: (503)685-0921
--