RE: [vhdl-200x] Issue with VHDL name attributes

John,

I think the approach will have to involve:

- not making an architecture a declaration

- as a consequence, an architecture name would not denote a named entity,
and would not have a scope

- identifying all of the cases where an architecture name can be referenced

- in those places that are currently subsumed as a reference to a named
entity, make a special case for architecture names (eg, in attribute
specifications)

- in other places, make sure we explicitly refer to an architecture name as
a special kind of name, rather than as a declared name, a declaration, or a
name that denotes a named entity

Cheers,

PA

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106
> -----Original Message-----
> From: John J. Shields [mailto:jshields@ieee.org] 
> Sent: Thursday, 15 April 2004 00:26
> To: 'Peter Ashenden'; 'Erich Marschner'; 'Ries, John'; 
> 'Bailey, Stephen'
> Cc: vhpi-pilot@eda.org; vhdl-200x@eda.org
> Subject: RE: [vhdl-200x] Issue with VHDL name attributes
> 
> 
> Hi,
> 
> It is necessary to clarify the scope of the architecture 
> name, but it would have been reasonable (to me) to have the 
> name of the architecture be considered to be in separate 
> subscope of the entity, while its declarations 
> could remain an extension of the entity decl scope.  The set 
> of arch names of an entity then must remain unique, an arch 
> may have the same name as an entity, and the backward 
> compatibility of the namespace of an E/A instance would be 
> preserved.  Is there a problem with this or an additional 
> limitation that I am not considering?
> 
> Regards, John
> 
> -----Original Message-----
> From: owner-vhpi-pilot@eda.org 
> [mailto:owner-vhpi-pilot@eda.org] On Behalf Of Peter Ashenden
> Sent: Wednesday, April 07, 2004 8:14 PM
> To: 'Erich Marschner'; 'Ries, John'; 'Bailey, Stephen'
> Cc: vhpi-pilot@eda.org; vhdl-200x@eda.org
> Subject: RE: [vhdl-200x] Issue with VHDL name attributes
> 
> Erich,
> 
> A significant difference between entity/architecture pairing 
> and package/body pairing is that an architecture body has a 
> name, whereas a package body does not.  There was a need to 
> define where the architecture name is declared and to specify 
> the scope of that name.  Were we to allow alternative package 
> bodies with names to distinguish them, the same issue would 
> arise.  (That may be akin to Ada-95 child packages, which are 
> deemed to be declared within and at the end of the parent 
> package body.  Now that I come to think of it, that was 
> probably the notion that inspired deeming architecture bodies 
> to be declared within the entity region.)
> 
> Rather than tearing at the fabric of the language, the intent 
> of the change was to unify declaration of entity and 
> architecture names with the existing scope and visibility 
> rules, in order to clearly specify where those names are 
> declared and where they are visible.  That aspect was 
> ill-specified pre-2002, and different implementations assumed 
> different incompatible interpretations.
> 
> As I indicated, this has been done according to due process 
> in an earlier revision of the standard. It is what VHDL currently is.
> 
> Cheers,
> 
> PA
> 
> --
> Dr. Peter J. Ashenden                        peter@ashenden.com.au
> Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
> PO Box 640                                   Ph:  +61 8 8339 7532
> Stirling, SA 5152                            Fax: +61 8 8339 2616
> Australia                                    Mobile: +61 414 70 9106
> 
> 
> > -----Original Message-----
> > From: Erich Marschner [mailto:erichm@cadence.com]
> > Sent: Thursday, 8 April 2004 02:33
> > To: Peter Ashenden; Ries, John; Bailey, Stephen
> > Cc: vhpi-pilot@eda.org; vhdl-200x@eda.org
> > Subject: RE: [vhdl-200x] Issue with VHDL name attributes
> > 
> > 
> > 
> > Peter,
> > 
> > I sent another email earlier this morning, but I suspect that
> > email didn't get out, because Outlook crashed just after I 
> > sent it - so I'll repeat myself here, just in case.  
> > Apologies if this is a duplicate.
> > 
> > I'm intrigued by the decision to make architectures a
> > separate declarative region, nested 'inside' that of the 
> > entity.  (I wasn't aware of this until this thread started.)
> > 
> > Architectures (or "architecture bodies", as they were
> > originally refered to) are to entity (interface) declarations 
> > as package bodies are to package declarations.  The only 
> > significant difference w.r.t. scope and visibility is that we 
> > wanted to allow alternative architectures, whereas one 
> > package body was deemed sufficient.  The need to allow 
> > multiple architectures led to a requirement for names on the 
> > architectures.
> > 
> > If an architecture is now considered to be a nested
> > declarative region inside an entity, then similarly a package 
> > body should be considered a nested declarative region inside 
> > a package declaration.  If that is not the case, then the 
> > analogy between entity/architecture and package/package body 
> > has been broken.  However, I see virtually no value in 
> > adopting this nested definition, in either case.
> > 
> > If the goal was to allow an architecture to have the same
> > name as the corresponding entity, a much more natural 
> > solution would have been to simply make the architecture name 
> > optional:
> > 
> > entity E is ...
> > end;
> > 
> > architecture of E is ...
> > end;
> > 
> > There is only one name, and it is shared by the entity and
> > the architecture - which together still constitute a single 
> > declarative region.  
> > 
> > I wasn't involved in the discussions that led to the decision
> > to change the definition of declarative regions, so I may be 
> > missing something.  But on the surface, I don't see how it 
> > adds any real value, and it seems to tear a bit at the basic 
> > framework of the language.  
> > 
> > Regards,
> > 
> > Erich
> > 
> 
> 
>