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

Jonathan,

You say (below) that your suggestion about using aliases is only about syntax.  I disagree with that characterization.  I think your suggestion is more about localizing (some of) the semantic checks that relate to a hierarchical name, not about syntax. 

I would say that there are 4 different issues, each of which need to be addressed:

1. What syntax we use to express the path from some root to some named item, anywhere in the design hierarchy.

2. How we avoid the possibility of such references creating elaboration order issues.  (I.e., does the specified hierarchical name designate something that exists.)

3. How we enable application of static semantic checks (e.g., type-checking) to contexts in which such references appear.  (I.e., does the thing designated by the hierarchical name satisfy static semantic requirements.)

4. How we avoid the possibility of such references creating cycles in zero-time evaluation.  

(There may be others, but I think this captures the issus that have been raised so far.)

Obviously the first is a syntax issue.  I would argue that the others are semantic issues.

In my previous comments, I've suggested addressing the syntax issue by building upon the existing expanded name syntax, to create "extended expanded names".  Whether we use that syntax, or some other syntax, the semantic issues remain.

Your suggestion, to allow hierarchical names (e.g., extended expanded names) to appear only in an alias declaration, addresses a part of item 3 above - how we enable type-checking during analysis, when a hierarchical name reference is involved.

I like the idea of using aliases in this manner.  It has the potential of simplifying the problem by localizing all elaboration time checks associated with hierarchical references to objects, where the alias declaration provides the type (and subtype) information required for some analysis-time static semantic checks.  

However, to make this approach fully general, we would have to allow an alias declaration for any kind of declaration, including entity/architecture/configuration declarations, type declarations, subtype declarations, etc.  Also, it would be difficult to use an alias declaration to address the PSL requirement, which involves specifying the pathname of an instance (of an entity/architecture) in the design hierarchy as part of the header of a vunit - e.g.,

    vunit V (top.a.b) {
      ...
    }

So, while your suggestion seems to help ensure that type-checking can be done during analysis time, even in the context of hierarchical references, it does not appear to address other kinds of static semantic checks, for other kinds of named declarations.

Regards,

Erich


| -----Original Message-----
| From: owner-vhdl-200x@eda.org 
| [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jonathan Bromley
| Sent: Friday, August 12, 2005 9:00 AM
| To: tgingold@free.fr; John Ries
| Cc: vhdl-200x@eda.org; vhdl-200x-ft@eda.org
| Subject: RE: [vhdl-200x] Review of FT-32
| 
| > I don't think this is possible.  If it is not possible to detect 
| > wether
| > Design.E(A).C2.E2.p1 is an error, then you don't know its 
| type too.  
| > Then you can't analyze any expression containing such an expanded 
| > name.
| 
| [and similar interesting comments on how the analyzer can or 
| cannot determine the type of an expanded name]
| 
| It occurs to me that there may be a rather attractive 
| solution to this.  Suppose we forbid any use of hierarchical 
| names EXCEPT in an alias definition, thus:
| 
|   alias hier_ref: std_logic is TB.design(D).block(A).sig;
| 
| Now we can use "hier_ref" with confidence in the current 
| design unit, its (sub??)type being fully defined.  Analysis 
| is then not an issue.  At elaboration time, all required 
| checking is clearly determined by the alias definition.
| 
| The more I look at this the more I like it.   Only rarely
| will it be more verbose than the Verilog-like "use a 
| hierarchical name anywhere" equivalent, and it nicely 
| separates analysis-time and elaboration-time checking in the 
| same way that components do.
| 
| It also opens the door to the clean encapsulation of a 
| collection of such out-of-scope references by means of 
| something akin to SystemVerilog's interface or clocking constructs.
| 
| Alex's concerns about unresolvable cycles and nondeterminism 
| are unaffected by this idea, as it's only about syntax.
| Also, I still believe that out-of-scope objects should be 
| read-only, but that opinion is orthogonal to this idea of 
| using alias to tidy up the syntax.
| --
| Jonathan Bromley, Consultant
| 
| DOULOS - Developing Design Know-how
| VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
| 
| Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, 
| Hampshire, BH24 1AW, UK
| Tel: +44 (0)1425 471223                   Email: 
| jonathan.bromley@doulos.com
| Fax: +44 (0)1425 471573                           Web: 
| http://www.doulos.com
| 
| This e-mail and any  attachments are  confidential and Doulos 
| Ltd. reserves all rights of privilege in  respect thereof. It 
| is intended for the use of the addressee only. If you are not 
| the intended recipient please delete it from  your  system, 
| any  use, disclosure, or copying  of this  document is 
| unauthorised. The contents of this message may contain 
| personal views which are not the views of Doulos Ltd., unless 
| specifically stated.
| 
| 
|