[vhdl-200x] Review of FT-32

Review of FT-32 : Unification of PathName and Instance Name for PSL, VHPI, and VHDL
=====================================================================

This started out to be a review, but it has turned into a revised (or perhaps complementary?) 
approach.  

FT-32 starts with this summary:

    Enhancement/Requirements Summary:
    ============================================================
    Formulate a common notation for path [and instance] names
    within VHDL for use by PSL, VHPI and VHDL hierarchical reference

The fundamental assumption here is that it would be good to have a common syntax for 
pathnames for PSL, VHPI, and VHDL.  I think this assumption goes a bit too far.

There are two distinct perspectives from which a VHDL design may be regarded: from inside 
the design, and from outside the design.  (By 'design' I mean the elaborated hierarchy of VHDL 
design units, some of which may represent the design, and some may represent test structures 
for the design.)  I think the requirements for the structure of names are somewhat different for 
the two perspectives, although they are related.

From the outside, we can view the (elaborated) design (hierarchy) as a nesting of named items, 
most corresponding to scopes within which other names are declared.  There must be a unique 
name for the whole hierarchy (or it must be understood from the context), and given that, we 
must be able to define a unique pathname to any named element in the design, including even 
dynamically created elements whose lifetimes are transient.  This is the perspective adopted by 
VHPI, and some (all?) of the pathname attributes; it is also the perspective that needs to be used 
in external reports (e.g., log files, error messages, etc.).

From the inside - i.e., from any point in the text of a VHDL design unit - the perpsective is a bit 
different.  What is visible at that point is a function of the applicable context clauses and the 
scope and visibility rules.  In general, to avoid verbosity in the text, we do not want to use fully 
qualified, absolutely unique names here; instead we want to use minimally qualified names 
(simple names if they are directly visible; minimally qualified "expanded names" if they are not).  
In fact, the syntax defines a number of places where simple names are visible by selection, such 
as formals within a port or generic map, or entity/architecture names in a configuration, precisely 
so that the shortest possible names can be used.  

So let me restate the goal, as I see it:

    Enhancement/Requirements Summary:
    ============================================================
    Formulate a notation for fully unique, hierarchical names for all named elements
    in a VHDL design hierarchy, for use in "external perspective" situations, such that
    these "external names" are syntactically consistent with the simple and expanded
    names already in use within VHDL (the "internal perspective").  

    In the process, enable expanded names to have more global extent within VHDL,
    and in particular, ensure that expanded names support the usage required by PSL 
    vunits.

To accomplish the above, I think we need to build up from the existing expanded name syntax, 
both to leverage the existing capabilities of the language and to ensure consistency.

Expanded names already provide a means of referring to 
 - a name in a package in a library
 - a name in the same or an enclosing declarative region (for use when the name is not directly 
    visible)

The first level of extension would be to remove the restriction that the second form of expanded 
name only appear within the scope in which the final simple name is declared (1076-2002, clause 
6.3, par. 8, last sentence).  This would allow "cross block references" within an architecture, for 
example,

    architecture A of E is
    begin
        B1: block
                 signal S1:  Bit;
              begin
                 S1 <= A.B2.S2;     -- extended expanded name
              end block;
        B2: block
                 signal S2:  ...
              begin
                 S2 <= not B1.S1;     -- extended expanded name
              end block;
    end;

From the "internal perspective", such extended expanded names would only need to start with 
the innermost directly visible named scope necessary.  In the limit, this would be the name of 
the enclosing design unit.  Such expanded names would be restricted to refer only to statically 
elaborated items, and might be further restricted to avoid order of elaboration issues (e.g., 
such a name referring to a remote type declaration could not be used in an object declaration 
before the type itself is elaborated).

Note that a reference to (the name of) the enclosing design unit cannot be interpreted strictly 
as either a "compiled library unit" reference or as an "elaborated design hierarchy" reference.  
It operates as both.  In fact, I would argue that the strong distinction between library unit and 
design hierarchy contexts made in the proposal obscures more than it clarifies.  (I realize that 
this differentiation has been in place in the VHPI for a long time, so I won't suggest removing 
it, but at least from the "internal perspective" of pathnames used within the language, we 
should recognize that the strong distinction cannot always be made.)

Once we have the ability to use expanded names anywhere within (an instance of) a design unit, 
the expanded name syntax can be further extended to allow references to names elsewhere in the 
design hierarchy.  There are two issues to address here: extending an expanded name downward, 
from an already visible starting point (such as the immediately enclosing block name); and 
identifying a starting point that is not already visible.  

Extending an expanded name downward is relatively easy - just continue the dotted name syntax 
"through" a component instantiation.  Exactly which of the names involved (component instance 
label, entity name, architecture name, configuration name) should be included in the expanded 
name syntax may be a point of discussion, but using '.' to separate names in constructing a 
pathname that extends downward through an instantiation is the obvious thing to do.

Starting an expanded name elsewhere in the design hierarchy (either at the root, or at any instance 
of a given design unit) requires some way of specifying that starting point, one that is consistent 
with the scope and visibility rules of the language.  The two cases could be unified by allowing an 
expanded name to start with any design unit name, which could be either that of the topmost 
design unit (the root of the design hierarchy) or of an entity that is instantiated one or more times 
in the design hierarchy.  This would be consistent with the existing ability to use an expanded name 
to refer to (names declared within) a statically elaborated package.  And since the language already 
defines context clauses and scope and visibility rules that enable design unit names to be referred to 
within VHDL text, nothing more elaborate is required.  For example, given the following library 
structure:

 -- in Library Design:
       package P
       package body P
       entity E
       architecture A of E -- with instances C2:E2 and C3:E3
       entity E2
       architecture A2 of E2
       entity E3
       architecture A3 of E3

 -- in Library Test:
       entity TB
       architecture One of TB  -- with instance DUT: E(A)
       architecture Two of TB  -- with instance DUT: E2(A2)

it should be possible to use the following extended expanded names within the source text of 
the above design units, assuming only that the appropriate library clauses appear to make the 
library names visible at the point at which the expanded names appear:

    Design.P  -- already allowed
    Design.E(A).C2.E2.p1   -- where p1 is declared in E2
    Design.E(A).C3.E3(A3).x.y.z   -- where x.y.z is an expanded name for z in y in x in A3
    Test.TB(One).DUT.E(A).etc.
    Test.TB(Two).DUT.E2(A2).etc.

Furthermore, if the appropriate use clauses are also present (e.g., "use Design.*; use Test.*"), and 
there are no occurrences of homographs in the two libraries that would cause one or more of the 
design units to NOT be directly visible, then the following names should be valid as well:

    P
    E(A).C2.E2.p1
    E(A).C3.E3(A3).x.y.z  
    TB(One).DUT.E(A).etc.
    TB(Two).DUT.E2(A2).etc.

Note that the PSL requirement is effectively from the "internal perspective" - especially once PSL 
vunits become VHDL design units.  The requirement is simply to allow a PSL vunit to specify the 
design unit or instance to which it applies, much like a configuration now specifies the design unit 
to which it applies.   In the simplest case, a PSL vunit should be able to do so by simply referring 
to the entity (and optionally to the architecture) to which it applies, just as a configuration refers to 
the entity to which it applies (and to its architecture, in a nested block configuration).  The more 
general case of applying a vunit to an instance within the hierarchy would be served by allowing 
extended expanded names as described above - e.g.,

    vunit V (Design.E(A).C3.E3(A3)) {
        ...
    }

Note that such an extended expanded name essentially refers to a set of instances of the specified 
design unit within the design hierarchy - the set of instances of E3(A3) that are all instantiated 
under Design.E(A) as component C3.  (This is what Peter referred to as 'wildcard' pathnames.)  
Clearly pathnames of this sort can only be used in restricted situations, in which reference to a set 
of items makes sense.  This usage in PSL is one such case.  We might also consider extending 
configurations to apply to instances in addition to design entities, in which case this kind of 
extended expanded name would also be of interest there.

So why do we need to define pathnames that begin with '@' or '!' ?  I am coming to the conclusion 
that we do not need such pathnames from the "internal perspective" point of view - the existing 
library and use clauses (along with the scope and visibility rules) give us the starting point we 
need for any pathname, and the syntax for expanded names can be extended easily to create 
pathnames relative to any starting point.  

Do "external perspective" pathnames need to start with special characters?  Perhaps they do.  
In the VHPI context, there is a need to distinguish between instantiated access and uninstantiated 
access.  Also, in external contexts, it may be useful to encode more semantic information into the 
pathname, so that readers (including simple tools such as scripts that process log files) don't need 
(as much) access to symbol table information in order to understand those pathnames.  But in any 
case, I would argue that such "external perspective" pathnames should be a simple extension of the 
"internal perspective" pathnames described above, which in turn are just an extension of the existing 
expanded names.

Regards,

Erich