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
>