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

Steve:

I thought more and realized that relaxing name restrictions
would also make possible to initialize objects (constants for 
example) to values of objects declared in a lower level block
that are initialized to the higher level object values.

Such objects would be documented as initialized but their 
initial value would be "just a guess." 

Attribute declarations could also get be in trouble.

Fixes to the proposal would therefore require:
1. Definition of the special selected name (call those "drifted 
selected names" or DSNs) because not all selected names 
should be excluded.
2. New (probably complicated) rules about where those 
DSNs could be used.
Note that languages that let you use such DSNs (like Verilog)
do not have the "declare before use" rule. However, even 
so the propagation of the parameter values in Verilog is 
still a mystery (read, under investigation by each implementer).
So to find if those DSNs are good we should not ask those 
who try to use them in Verilog, but those who try to implement 
them. 

Remember that an Ariane racquet exploded a few seconds after 
launch due to just one wrong 32 to 64 conversion. Getting more 
guessing into the standard would only increase the chances for a 
repeat. I hope it will not be on your or my car airbag system. 

Regards,

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




-----Original Message-----
From:     Bailey, Stephen <SBailey@model.com>
Sent:     Fri, 5 Aug 2005 04:49:45 -0700
To:       <vhdl-200x@eda.org>
Cc:       <vhdl-200x-ft@eda.org>
Subject:  RE: [vhdl-200x] Review of FT-32

Alex,

For us simple minded folks, can you provide an example with aliases that
creates additional problems?  I fail to see how this is different from
direct use of extended, expanded names.

You may have a point with implicit guard signals.  However:

1.  Are we going to throw the baby out with the bath water?  No one uses
guarded blocks or guarded signals.  So, why throw out this enhancement
due to that issue?  It would be better to remove guarded blocks and
signals from the next version of the language.

2.  Or, could the semantics of extended, expanded names be defined such
as to disallow their use with implicit GUARD signals?

-Steve Bailey

> -----Original Message-----
> From: owner-vhdl-200x@eda.org 
> [mailto:owner-vhdl-200x@eda.org] On Behalf Of azro@onebox.com
> Sent: Friday, August 05, 2005 2:13 AM
> To: erichm@cadence.com; vhdl-200x@eda.org
> Cc: vhdl-200x-ft@eda.org; Jim@synthworks.com
> Subject: 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
> 
> 
> 
> 
> 
>