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

Hi,

I've been on vacation and I just read through this thread. I'd like to
clarify a statement that Peter made regarding how we defined the fullname
property in VHPI. It is not true that its definition is tied intrinsically
to pathname. Indeed, we have a property for both pathname and instance_name
that are guaranteed to produce the same name as the attribute, but the
fullName property allowed us some important flexibility.

VHPI recognized this problem with ambiguity in the pre-defined name
attributes early ('pathname, 'instance_name). We decided that the
information model would have a fullName property that was similar to, but
independent of the 'pathname attribute. What we wanted to achieve was
consistency between the behavior of lookup_by_name and access to name
information. An application could retrieve the fullname of an object and
have some assurance that the object could also be looked up by that name.
An independent property allows us to deal with ambiguity in the definition
of 'pathname without causing backward compatibility problems or coordinating
standard revision. It allows us to deal with inherent ambiguity arising
from unlabelled processes by defining automatically generated names, a
concept that can be extended to form a canonical name for all instance
objects in the future, if desired (an example is the name of an arbitrary,
unlabeled statement).

One more bit of philosophy regarding ambiguity. VHPI does indeed say that
if a name is an ambiguous reference, then lookup will fail. The case being
discussed is one of pathological ambiguity and I think there are others
where library name and entity name are the same. I think this particular
one with 'pathname can be solved, but not without causing some backward
compatibility issues. It is inherent in changing a disjoint scope into a
nested scope.

I looked at Peter's proposal briefly and I don't like it. It doesn't pass
my common sense test. For an object x in the root instance whose entity and
architecture are both named top, we have :top:top:x. Most people would say
that :x or at worst :top:x should be the name, achieving a compact but
unambiguous reference for reasonable cases. If someone insists on forming a
case that has pathological ambiguity in it, I personally feel they should
reap the just reward of ambiguous references. All leaf level instances in a
pathname will now require the entity or architecture name to refer to the
appropriate scope as well. I trust the intermediate scopes between the root
and the leaf scope remain sufficiently unambiguous to not require the
architecture scope in each component of the path. It is hard to review
Peter's changes specified as incr changes in that email, so I may be missing
something.

As to VHPI thinking, we currently define fullname to be formed by the
concatenation of the simple names of the scopes from the root instance to
the object and the name of the object, using the appropriate
separator(i.e.,':' ). If entity and architecture have the same name for
some instance, it does not matter. The fullname will refer to the instance
by its label. We have not properly accounted for the
LRM revision defining 2 separate, nested scopes per 2002 LRM. We consider
them a single but disjoint scope. Therefore, as it stands today, we would
treat the situation of having 2 objects named 'x' in each scope as an
ambiguous reference and not possible to find either by lookup. We have to
fix this in some manner.

We could extend the definition to account for each scope, which would
effectively require a qualifier to distinguish whether we are referring to
the entity scope or architecture scope for a given instance. In most cases,
this would be overkill. We could leave the current specification and
specify that the lookup will search the entity scope followed by the
architecture scope or vice versa.This does not ignore the separate nested
scope issue, but treats it regularly to get the expected result in normal
cases and hides an object in the ambiguous cases. Finally, we can allow the
object name to be either its simple name or an extended name, where the
extended name serves to disambiguate. The extended name is either the
entity or architecture name followed by the simple name, with an different
separator (i.e., '.'). An object x in both the
entity and arch of the root instance could then be refered to with:

:e:x - today's definition and ambiguous or, given search rules, unambiguous
:e:e.x - possible extension to qualify the simple name of x in the entity
:e:a.x - " " " arch

I have not thought through all the cases but we do not want ambiguity caused
by a component of the fullname referring to an instance label or entity/arch
name. I can label an instance and name an entity or architecture with the
same name, no? I also do not want a burdensome canonical name that is
always unique and never convenient. This will cause user interface
conventions in tools that avoid the problem. I appreciate the need to fix
the VHDL attributes and encourage vhdl-200x to address this now rather than
later. I think VHPI will want to reserve the right to disambiguate,
simplify, and auto generate names to achieve a building block for good
application UIs. As such, 'pathname will remain a strong guideline for
vhpiFullName property, but not its foundation. Of course, IMHO, at this
point in time.

Regards, John Shields

-----Original Message-----
From: owner-vhpi-pilot@eda.org [mailto:owner-vhpi-pilot@eda.org] On Behalf
Of Francoise Martinolle
Sent: Wednesday, April 07, 2004 7:42 AM
To: johnr@model.com; SBailey@model.com; peter@ashenden.com.au
Cc: vhpi-pilot@eda.org; vhdl-200x@eda.org
Subject: 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 Thu Apr 8 13:45:05 2004