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

Dear HDL Experts:

I share the opinion that no additional scope is needed for
architectures. I looked at this when I proposed a fix for an
ISAC issue related to visibility of entity ports in the architecture
some time ago. As far as I know that was the only issue and it was
fixed. This new one about the same name can be solved in many
other ways:

1. Forbid same name
2. Omit arch name if same
3. Consider that arch name is omitted if same
4. Create a nested scope outside the architecture scope
    just for its name

In any case do not create a nested scope inside the entity
scope.

Thanks,

Alex Z

-- 
Alex Zamfirescu
azro@onebox.com - email
(877) 332-0676 - voicemail/fax
-----Original Message-----
From:     Peter Ashenden <peter@ashenden.com.au>
Sent:     Wed, 7 Apr 2004 17:52:20 +0930
To:       "'Ries, John'" <johnr@model.com>; "'Bailey, Stephen'" <SBailey@model.com>
Cc:       <vhpi-pilot@server.eda.org>; <vhdl-200x@server.eda.org>
Subject:  RE: [vhdl-200x] Issue with VHDL name attributes
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
  signal S1 : bit;       -- third object
  signal S3 : bit;       -- fourth object
begin
  ...
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
WORK.E.E.Y.
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.
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