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

Erich, 

> I would say that there are 4 different issues
[...]

thanks for the clear analysis, which looks robust to me.

> However, to make this approach 
[using alias to provide a strongly-typed local name
for any out-of-scope reference]
> 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. 

Indeed, I completely agree.  In fact I think I missed an
important issue when I suggested using "alias":  When you
do an alias in VHDL today, the target of the alias is locally
known and therefore all of its characteristics are known at the
point of the alias declaration.  This is not the case if the
alias renames an out-of-scope thing.  So I think I should have 
suggested something slightly different:

<absolutely any declaration whatsoever>
   RENAMES
   <an out-of-scope (hierarchical) reference>;

In this way, the declaration captures all characteristics
of the out-of-scope thing; there is no doubt about whether
the thing is a signal, variable, entity or whatever.
Conformance between hierarchically-referenced thing
and declaration can be determined later.  I reckon
that the benefits of centralising such checking in that
way are worth fighting for.

This introduces a new keyword.  Perhaps someone can see
how to avoid that.  I don't think you could use IS, but 
you might be able to re-use ALIAS in the new context.

> 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) {
>       ...
>     }

Agreed, but surely it's PSL that's out on a limb here;
if vunit were better integrated into VHDL then the 
problem need not arise.

I am absolutely aware that what I suggested doesn't 
address all the issues that need to be fixed, but I
hoped it would remove a few undesirable degrees of 
freedom without undermining the usefulness of the
proposals.  I'm also very conscious that it 
needs much more work to make it robust.

Thanks for the discussion.
-- 
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.