[vhdl-200x] Issue with VHDL name attributes

From: Peter Ashenden <peter@ashenden.com.au>
Date: Mon Apr 05 2004 - 22:10:47 PDT

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:10:37 2004

This archive was generated by hypermail 2.1.8 : Mon Apr 05 2004 - 22:11:40 PDT