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" <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 John,I have to disagree with the proposal. Adding addition scopes to the pathname raises several issues. 1) CompatibilityYes, 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 ----- End Included Message -----
-- ------------------------------------------------------------- -- Model Technology Inc. -- -- 8005 SW Boeckman Road 503.685.7000 tel -- -- Wilsonville, OR 97070 USA 503.685.0921 fax -- ------------------------------------------------------------- -- Technical support ............ mailto:support@model.com -- -- Sales and marketing info ....... mailto:sales@model.com -- -- Licensing .................... mailto:license@model.com -- -- Home Page ........................ http://www.model.com -- -- AIM ........................................ bgriffin42 -- -------------------------------------------------------------Received on Wed Apr 7 09:36:55 2004
This archive was generated by hypermail 2.1.8 : Wed Apr 07 2004 - 09:37:05 PDT