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

Hi,

I've replied separately concerning the issues with VHPI name properties and
their relationship to

'pathname, and this new nested scoping issue. I also think the change to
nest these scopes was

ill considered and should be reverted. I would appreciate some
clarification on the original problem

that it was meant to solve. I am specifically referring to the question of
what problems are caused

by having the arch decl scope be regarded as an extension of the entity decl
scope? Does this cause

a problem with separate compilation in some way? Are there specific cases
of name resolution problems

that are ambiguously specified?

In general, I am adverse to solving pathological problems in a manner that
penalizes normal, reasonable

use. The discussion of how to fix 'pathname to conform to the nested scope
model of E and A decl regions is

a good example of that.

Thanks, John Shields

  _____

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of
Griffin, Brian
Sent: Thursday, April 08, 2004 10:03 AM
To: Peter Ashenden
Cc: vhdl-200x@eda.org; vhpi-pilot@eda.org
Subject: Re: [vhdl-200x] Issue with VHDL name attributes

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.

-Brian

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.

Regards,

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: owner-vhdl-200x@server.eda.org [mailto:owner-vhdl-200x@server.eda.org]
On Behalf Of Griffin, Brian
Sent: Thursday, 8 April 2004 02:07
To: vhdl-200x@server.eda.org
Cc: vhpi-pilot@server.eda.org
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
-Brian
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. 
 
Regards,
 
-ajay
 
----- Begin Included Message -----
 
>From owner-vhdl-200x@eda.org Wed Apr  7 13:53 IST 2004
From: "Peter Ashenden"  <mailto:peter@ashenden.com.au>
<peter@ashenden.com.au>
To: "'Ries, John'"  <mailto:johnr@model.com> <johnr@model.com>, "'Bailey,
Stephen'"  <mailto:SBailey@model.com> <SBailey@model.com>
Cc:  <mailto:vhpi-pilot@eda.org> <vhpi-pilot@eda.org>,
<mailto:vhdl-200x@eda.org> <vhdl-200x@eda.org>
Subject: RE: [vhdl-200x] Issue with VHDL name attributes
Date: Wed, 7 Apr 2004 17:52:20 +0930
 
John,
 
  
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