RE: [vhdl-200x] Review of FT-32

John,

Thanks for the feedback.  See my responses interspersed below.

Regards,

Erich 

| -----Original Message-----
| From: owner-vhdl-200x@eda.org 
| [mailto:owner-vhdl-200x@eda.org] On Behalf Of John Ries
| Sent: Thursday, August 04, 2005 8:23 PM
| Cc: vhdl-200x@eda.org; vhdl-200x-ft@eda.org
| Subject: Re: [vhdl-200x] Review of FT-32
| 
| I have a few random questions and comments.
| 
| 
| 1) I like the idea of using expanded names and just extending 
| them for hierarchical names.

Glad to hear that.

| 
| 2) What I don't see is how a name from the design root is 
| different than a name which is a "wild card" name the 
| references multiple instances in the design.
| 
| For example the name
| 
|      Design.E(A).C2.E2.p1
| 
| Could refer to the design root if the user elaborates E(A) as 
| the root or it could be a wild card name if  Test.TB was the 
| design root.  Not know would make checks in the compiler very 
| interesting.

There is no syntactic difference.  This is similar to the situation with overloaded operators - a given symbol represents a set of definitions.  The question is how a reference is narrowed down to a unique member of the set.  For overloaded operators, it only makes sense to refer to one member at a time, so the overload resolution rules must always give a unique answer, or else an error occurs.  In this case, one can imagine situations in which we might want to refer to more than one member of the set (e.g., when we are attaching assertions to a subset of all instances of a given design unit), so the semantics may allow multiple meanings for a given pathname in cases where that makes sense.  

Note that the notion of referring to a set of objects already exists in the language. For example, attribute specifications can refer to a set of entities of the same class, and set the same attribute of all those entities to the same value in one specification.

| 
| For example
| 
| LIBRARY Design;
| use Design.all;
| 
| ENTITY Monitor IS
| END;
| 
| ARCHITECTURE  Implement OF Monitor IS
| BEGIN
| 
| P1: PROCESS ( Design.E(A).C2.E2.p1 )  -- is this an error?
|                                                               
|         -- we can't tell until the design is elaborated.
| BEGIN
|      ASSERT ( Design.E(A).C2.E2.p1 = '0'); END PROCESS;
| 
| END;

I believe the requirement for an elaboration-time check just goes with territory; it is not unique to a particular syntax for hierarchical pathnames.  Any pathname that crosses a hierarchy boundary would not be resolvable until elaboration anyway, so any occurrence of such a hierarchical pathname would have to be checked at elaboration time to make sure it makes sense.

To make this a bit more crisp, suppose we define (by analogy to static expression categories) the categories "locally extended expanded names" and "globally extended expanded names".  The former would be those that can be resolved at compile time, because they are local to a design unit (e.g., the "cross block references" I mentioned in an example).  The latter would require resolution at elaboration time, because they cross instance boundaries. 

| 
| 3)Use clause for making extended expanded names directly visible.
| 
| There would have to be a restriction on the USE clause that 
| the expanded names must already exist and be seen.  Otherwise 
| one would have problems determining visibility of names.

If I understand your statement correctly, I would agree.

In general, the object to which an extended expanded name refers must have been elaborated before the extended expanded name is first evaluated.  This includes use of an extended expanded name in a use clause, in a declaration, in a statement, etc.  The practical effect is that extended expanded names would probably be most useful in statements that are not executed until after the design is completely elaborated.  Using them in context clauses, in declarations, and in statements that are part of functions called during elaboration would require more care to avoid order of elaboration problems.  

Again, this is true regardless of the syntax used to represent a hierarchical pathname.

| 
| For example:
| 
|       architecture A of E is
|       begin
|           B1: block
|                   use A.B2.ALL;  -- We don't know what is 
| declared in B2 so it we can't determine direct
|                                             -- visibility of 
| names are and if there are any conflicts and such.
|                    signal S1:  Bit;
|                  begin
|                     S1 <= S2;     -- want this to be A.B2.S2;
|                  end block;

I would be more inclined to simply prohibit use of an extended expanded name in a use clause.  The current LRM allows only selected names in use clauses, and it is clear from the definition that such names must have a prefix that denotes a package.  I would recommend leaving that definition alone.


|            B2: block
|                    use A.B1.ALL;  -- This is okay because B1 
| has already been declared and we know the names
|                                              -- with in it.
|                     signal S2:  ...
|                  begin
|                     S2 <= not S1;     -- name references A.B1.S1;
|                  end block;
|        end;
| 
| 4) The @ and ! for external perspective names.
| 
| Unless we put the library name into the pathname, we have a 
| problem with ambiguous names unless packages are some how 
| indicated by a prefix.  Take the following libraries and design units.
| 
| Library TEST
| PACKAGE P1;
| 
| Library UTIL
| PACKAGE P2
|       library test;
|       use test.p1.all;
|       package p2 ....
|       end package;
| 
| 
| Library Design
| ENTITY TEST -- has port P1;
|      library util;
|       use util.p2.all;
|       entity test is
|           port ( p1 : bit );
|      end entity;
| 
| 
| The user now specifies Design.test as the design root for 
| elaboration.  If the pathname doesn't have specify the name  
| test.p1 could be referring the port p1 or the package p1.

Let's distinguish carefully between the "internal" and "external" perspectives here.

Specifying the design root for elaboration is an external operation.  (There is no place in a VHDL design unit that one can specify this.)  So the syntax for the name of the design root used in an external context could be different from that for hierarchical references within the language.  Even if it is the same, there may be additional factors that affect its interpretation - e.g., environment variables, tool settings, search rules, log file headings, etc. that are part of the tool environment.  For example, in the situation you describe above, the elaborator may have been given the work library as a separate command line option, and that might determine how to interpret "Design.test".

On the other hand, referring to a pathname such as "test.p1" might occur within the language, and such a reference might be ambiguous.  For example, one might write "use test.p1;", in which case the scope and visibility rules would need to determine whether "test" meant Library Test or entity Test in Library Design.  But this kind of potential ambiguity is already possible in VHDL, and there are already disambiguation rules that handle it, so I would argue that there is no point in worrying about this.

Would it be useful to adopt a standard way of encoding semantic information (such as "the following name is a library name") into a hierarchical pathname?  It certainly might, for pathnames used outside of the language.  For example, if a library name were always preceded by '@' in pathnames that are printed into log files, then a simple script could determine that "@Design.Test" means something different from "Design.Test".  And by extension, pathname attributes that return strings (which might be printed into log files, but are typically not interpreted from within the design hierarchy) might adopt the same convention.  And of course, VHPI calls would benefit from such a convention, especially if it uses different characters to distinguish between instantiated and uninstantiated access (as proposed in FT-32).

But I wouldn't recommend adopting this mechanism for pathnames used within the language, for the following reasones.  First, it isn't necessary: we already have name resolution rules that suffice to determine the meaning of a name used in a VHDL context.  Second, just adding this convention would mean that there would be two ways of representing the same name within the language, e.g., Design.Test and @Design.Test, which would be confusing.  Third, going further and requiring the use of '@' on library names would not be backward compatible.  So I would recommend adopting this kind of a convention only for pathnames that do not appear as part of the syntax of the language - those that appear in the tool environment (command arguments, VHPI arguments, log file headers, etc., and possibly those that are values of pathname attributes.  


| 
| 5) Since the names have architecture and entity in the 
| pathname, it gives the compiler enough
|     information to resolve type information and visiblity 
| without having do elaborate the design.
|     On the other hand it locks the design down so swapping 
| between alternative architectures
|     would require pathnames to be changed even if the 
| instance hierarchy hasn't changed.

Yes, using globally extended expanded names would definitely have the side effect of creating dependencies that "lock down" parts of the design - much like configurations do, by locking down the binding of component instances to entities (though with a different, much more verbose syntax).  (And I would argue that, if you swap alternative architectures, the instance hierarchy HAS changed.)  But again, I think this just goes with the territory; it has nothing to do with the syntax used to express hierarchical pathnames.

| 
| 
| 
| Erich Marschner wrote:
| > 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
| > 
| 
| 
| -- 
| -- mailto: johnr@model.com     phone: (503)685-0864
| --   http://www.model.com        fax: (503)685-0921
| --
| 
| 
| 
|