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

From: Griffin, Brian <>
Date: Thu Apr 08 2004 - 11:02:36 PDT
Hi Peter and the rest of the VHDL community,

I humbly apologize to the community for falling asleep here and missing this issue when it was originally "analyzed" and approved.  Had I been paying attention, I would have voiced my opposition to the change at that time.  Also, given this change in the language, the proposed 'path changes are perfectly reasonable.  But, the fundamental fact remains that this change is bad and just plain wrong because of the ramifications through out the design and development process.  Not only did the "analysis" fail to address 'path, but did anyone consider the impact on SDF, C API's, and other interactions of any and all kinds with simulators such as cross probing?  What the VHPI is attempting to address here has already been addressed from the very beginning by all tools that touch anything VHDL.  To think that this LRM change has no impact on these tools and the design flow is naive.  Ignoring these issues, even though they are not formally part of the language was unfortunate, but it's not too late to take corrective action.  This change should be rescinded and the ISAC should re-evaluate the issues in LCS-3 in a manor and language that clarifies the ambiguities, identifies the limitations and, most importantly, does not drastically change the external view of a design.


Peter Ashenden wrote:
Brian and others,
The change to the scoping of architecture bodies was done during the VHDL-2002 revision.  It occurred as part of LCS-3, addressing the larger question of scope and visibility of design unit names.  Due process was followed: the change was analyzed and approved by the working group, ballotted and approved by the sponsor ballot body, and approved by the IEEE Standards Board (RevCom).  So in the language as it is currently defined, an architecture body is logically nested within an entity declarative region.
As I pointed out in my proposal, the definition of the 'path_name and 'instance_name attributes was not revised to mirror the changes from LCS-3.  I believe this was an oversight, as I do not recall nor have record of any discussion of implication of LCS-3 on the attributes.  Hence my proposal to correct the oversight.

Dr. Peter J. Ashenden              
Ashenden Designs Pty. Ltd.         
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: [] On Behalf Of Griffin, Brian
Sent: Thursday, 8 April 2004 02:07
Subject: Re: [vhdl-200x] Issue with VHDL name attributes

--flame on

Time-out.  I'd like to back up a bit.  I have serious reservations about this whole architecture scoping business.  How can you possible inject a new scope level here at all with out seriously breaking all existing vhdl models?  I just don't understand this.  The entity architecture comprise a single scope.  Period.  End of discussion.  To even pretend otherwise is a significant, fundamental change in the language that can do nothing but invalidate all existing implementations.  The only real problem here is an architecture that has the same name as it's entity, which in my book is just plain stupid and should be disallowed by all implementation.  If it was disallowed, there would be no ambiguity and no naming problems.  Even if it's allowed, the penalty is loss of access; too bad!

Please, please, please, don't make architectures a new scope, or even pretend to!

--flame off


Ajayharsh Varikat wrote:
I have some reservations about the earlier decision to nest architecture 
scopes within entity scopes.

However, given that the nested scopes has become a part of the current 
language definition, I see it as only logical that we resolve the 
inconsistencies in 'path_name and 'instance_name that Peter pointed out. 



----- Begin Included Message -----

>From Wed Apr  7 13:53 IST 2004
From: "Peter Ashenden" <>
To: "'Ries, John'" <>, "'Bailey, Stephen'" <>
Cc: <>, <>
Subject: RE: [vhdl-200x] Issue with VHDL name attributes
Date: Wed, 7 Apr 2004 17:52:20 +0930


I have to disagree with the proposal.
Adding addition scopes to the pathname raises several issues.

1) Compatibility

Yes, that needs to be considered.  What is broken by the change?  (See below
for an answer.)

2) Cross module references
    Cross module references would need to support the new 
pathname form. This raise the
    question does the old form of pathnames work if it is 
unambiguous?  Does the VHPI
    look up by name support the old form with the same restrictions?

The problem is that the old form *is* ambiguous.  Does a path name of the
form ":e:x" refer to an item x declared in entity e or in some architecture
of e?  If both the entity and an architecture declare x, ":e:x" is the path
name for both items.  If you plan to use path names for XMRs, the old form
doesn't give you a way to distinguish between the two items.

Regarding VHPI lookup by name: I don't know what prototype implmentations
do, but since I'm specifying it in the LRM, I need to ensure completeness of
definition.  If the path_name attribute remains unchanged, it cannot serve
as the basis for the vhpiFullNameP property.  I'd have to repeat a lot fo
the definitional work to specify something that is unambiguous and that can
eb used for lookup by name.  Presumably that could then be used for XMRs
instead of the broken path names.  All up, I think it would be better to fix
the problem as part of standardization than to have a collection of
inconsistent and partly broken approaches.

3) There is still a fundamental problem with the architecture 
being a scope
    inside of the entity. If you have X declared in the 
architecture and in the entity
    and the entity and architecture have the same name, say 
E, you can't access the entity's X.
    Because E.X refers to the architecture's X.  If E.<name> 
referred to objects in the
    entity's scope, selected names to everything in an 
architecture would have to be
    E.E.<name>.  This would break compatibility with older designs.

I had thought Chuck Swart had raised an issue making the 
architecture a nested scope in 2002 for just this reason. To 
put words in Chuck's mouth he thought the only reason for 
adding the nested scope was to clean up the problem of having 
an architecture named the same as the entity. The 2002 change 
seems to raise as many issues as it fixes.

The problem addressed in the 2002 rev was that application of scope rules to
entity an architecture names was ill specified, and so different
implementations did different things.  It wasn't clear that an architecture
name could be the same as the entity name; it depended on which bits of the
LRM you read.  Some examples (non-normative) in the LRM had the architecture
name the same as the entity name, suggesting that the intent was to allow
it.  Hence, it seemed appropriate to fix the application of scope rules to
those names and to names of design units in library and root regions in the
way that we did.  Since the LRM was inconsistent/incomplete, whichever way
we fixed it was bound to break someone's interpretation.

Returning to the issue of referring to X declared in E from within
architecture E of E that also declares X: you can refer to WORK.E.X.

Looking at a more complete example, consider the following VHDL model:

entity E is
  signal S1 : bit;       -- first object
  signal S2 : bit;       -- second object
end entity E;

architecture E of E is
  signal S1 : bit;       -- third object
  signal S3 : bit;       -- fourth object
end architecture E;

Within the entity, you can refer
- to the first object as WORK.E.S1, E.S1, S1
- to the second object as WORK.E.S2, E.S2, S2

Within the architecture, you can refer to
- to the first object as WORK.E.S1
- to the second object as WORK.E.S2, S2
- to the third object as WORK.E.E.S1, E.S1, S1
- to the fourth object as WORK.E.E.S3, E.S3, S3

Under the pre-2002 rules, you couldn't have two items of the same name, one
in the entity and the other in the architecture, since the two declarative
parts formed a discontinguous single declarative region.

Under the pre-2002 rules, if you have entity E declaring X and architecture
A declaring Y:

- within the entity you could refer to X as WORK.E.X, E.X or X
- within the architecture you could refer to X as WORK.E.X, E.X or X
  and to Y as WORK.E.Y, A.Y or Y.

All of these are still valid under the 2002 rules except for referring to
WORK.E.Y in the architecture.  Under the old rules you could not in the
architecture refer to Y as WORK.A.Y, but under the new rules you can refer
to it as WORK.E.A.Y or E.A.Y.

Under the pre-2002 rules, if you have entity E declaring X and architecture
E declaring Y:

- within the entity you could refer to X as WORK.E.X, E.X or X
- within the architecture you could refer to X as WORK.E.X or X
  but not as E.X
- within the architecture you could refer to Y as WORK.E.Y, E.Y or Y

All of these are still valid under the 2002 rules except for referring to
WORK.E.Y in the architecture.  Under the new rules you can refer to it as

So the only incompatibility is with a pre-2002 model that, within an
architecture, refers to an item Y declared in the architecture as WORK.E.Y,
where E is the entity name.  Given the unlikelyhood of that, the benefit of
fixing the scope and visibility issues seemed like a good choice.

On the procedural scope, I think that it is good for VHPI 
team should identitfy issues like this and propose solutions. 
 I don't think that they should be actually changing the LRM 
to implement these solutions.  Ideally they would raise the 
issue, propose a solution, the ISAC would comment and it 
would be folded into the VHDL-200x fast track changes.

I certainly seek ISAC comment - and have got it!  The procedural question
here is that without the proposed change, defining an aspect of VHPI is made
more difficult and internal inconsistency is introduced.  We could just
suffer that for now and revise the VHPI definition when the path name
attribute is eventually fixed by FT, but I think it would simplify life for
all concerned to address it now.



Dr. Peter J. Ashenden              
Ashenden Designs Pty. Ltd.         
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106

----- End Included Message -----


--                 Model Technology Inc.                   --
-- 8005 SW Boeckman Road                  503.685.7000 tel --
-- Wilsonville, OR 97070 USA              503.685.0921 fax --
-- Technical support ............ --
-- Sales and marketing info ....... --
-- Licensing .................... --
-- Home Page ........................ --
-- AIM ........................................ bgriffin42 --

--                 Model Technology Inc.                   --
-- 8005 SW Boeckman Road                  503.685.7000 tel --
-- Wilsonville, OR 97070 USA              503.685.0921 fax --
-- Technical support ............ --
-- Sales and marketing info ....... --
-- Licensing .................... --
-- Home Page ........................ --
-- AIM ........................................ bgriffin42 --
Received on Thu Apr 8 11:02:41 2004

This archive was generated by hypermail 2.1.8 : Thu Apr 08 2004 - 11:03:15 PDT