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

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
>
>
Received on Mon Apr 5 22:46:45 2004