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

Erich:

In changing the capabilities of VHDL regarding names one has to 
keep in mind, or remember, the reasons why restrictions 
were in place in the previous versions of the standard.

Two important features of the VHDL semantic are: (a) the standard 
is not ambiguous (more vendors can implement it with same results), 
and (b) the simulation does not deadlock or go into hidden infinite loops.

I hope you agree that (a) and (b) above should continue to be hard design 
guidelines for the future versions of the language.

Note: So far the notable exception to (a) is the ability to define resolution 
functions that depend on the order of the drivers in the array passed to them, 
but that was well analyzed and it is known how to check RFs for that property.
Marginal exceptions to (b) are cases when the programmer specifies a while 
loop that does not reach its ending condition. 

The concern remains only with the infinite loops or ambiguities that can 
appear due to the signal value propagation. 
VHDL has a clear way to break infinite loops or ambiguous propagation 
with the at-least-one-cycle-delay for signal assignments. There are two other 
(hidden = not so obvious) mechanisms that help avoid loops and ambiguity
that are built into the language via name restrictions. 
One is the mechanism to resolve nets in an order that is uniquely defined 
(first go up the hierarchy then down, etc.), the other is the mechanism for 
propagating guard signal values from guarded expressions. 
Both these mechanisms are intra cycle propagation and do not benefit 
from the (<=) at least one cycle delay rule. Such mechanisms rely on the 
restrictions of creating some kind of names to make sure the loops are 
not specifiable, and that clear/unique values are computable during the 
immediate propagation (the propagation is acyclic, does not converge after 
it diverges, and it will terminate).
All the extras that many think are not needed as the (actual, formal, driving 
values etc) for ports are well thought mechanisms to make sure VHDL is an 
implementable standard.

If we start relaxing the restrictions for names we get into trouble if we 
do not take into account the reasons stated above. 

For example, given two blocks labeled B1 and B2
like in your example, if one can use B1.guard in the guarded expression of
B2, and B2.guard in the guarded expression of B1, a model 
that is impossible to evaluate, or requires implementer specific decisions
is created. 

With your proposed changes I can also create other troublesome examples 
using aliases. 

The conclusion (a formal proof regarding this was published
during VHDL 93 Validation) is that in relaxing name rules, we need to 
observe some older restrictions that help keeping VHDL a standard. 
Hierarchy is used in VHDL to define the partial order needed for 
correct immediate evaluation. If we break hierarchy in creating names 
we break that mechanism, that is IMHO a fundamental advantage 
of VHDL over other, more ambiguous or so called "agree-to-disagree",
"the-standard-is-my-GOLDEN-implementation" languages. 

Best regards,

Alex Zamfirescu
 
-- 
Alex Zamfirescu
azro@onebox.com - email
(877) 332-0676 - voicemail/fax

 


-----Original Message-----
From:     Erich Marschner <erichm@cadence.com>
Sent:     Thu, 4 Aug 2005 14:08:08 -0700
To:       <vhdl-200x@eda.org>
Cc:       <vhdl-200x-ft@eda.org>;"Jim Lewis" <Jim@synthworks.com>
Subject:  [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