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

I agree with Peter that it would be a lot simpler to fix 'path_name now.

Francoise
    '
>X-UIDL: 3m@!!:42"!B]9!!ZG)#!
>X-Authentication-Warning: server.eda.org: majordom set sender to
owner-vhdl-200x@eda.org using -f
>From: "Peter Ashenden" <peter@ashenden.com.au>
>To: "'Ries, John'" <johnr@model.com>, "'Bailey, Stephen'" <SBailey@model.com>
>Cc: <vhpi-pilot@eda.org>, <vhdl-200x@eda.org>
>Subject: RE: [vhdl-200x] Issue with VHDL name attributes
>Date: Wed, 7 Apr 2004 17:52:20 +0930
>MIME-Version: 1.0
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
>Importance: Normal
>Content-Transfer-Encoding: 8bit
>X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id
i378MM6X003639
>X-Scan-Signature: 5272c6f2bfd40cbf236efac0de2cd38c
>X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:97.3254 C:87.1726 )
>X-Received: By mailgate.Cadence.COM as BAA19833 at Wed Apr 7 01:23:19 2004
>
>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
>
>
Received on Wed Apr 7 08:42:14 2004