I have a few random questions and comments. 1) I like the idea of using expanded names and just extending them for hierarchical names. 2) What I don't see is how a name from the design root is different than a name which is a "wild card" name the references multiple instances in the design. For example the name Design.E(A).C2.E2.p1 Could refer to the design root if the user elaborates E(A) as the root or it could be a wild card name if Test.TB was the design root. Not know would make checks in the compiler very interesting. For example LIBRARY Design; use Design.all; ENTITY Monitor IS END; ARCHITECTURE Implement OF Monitor IS BEGIN P1: PROCESS ( Design.E(A).C2.E2.p1 ) -- is this an error? -- we can't tell until the design is elaborated. BEGIN ASSERT ( Design.E(A).C2.E2.p1 = '0'); END PROCESS; END; 3)Use clause for making extended expanded names directly visible. There would have to be a restriction on the USE clause that the expanded names must already exist and be seen. Otherwise one would have problems determining visibility of names. For example: architecture A of E is begin B1: block use A.B2.ALL; -- We don't know what is declared in B2 so it we can't determine direct -- visibility of names are and if there are any conflicts and such. signal S1: Bit; begin S1 <= S2; -- want this to be A.B2.S2; end block; B2: block use A.B1.ALL; -- This is okay because B1 has already been declared and we know the names -- with in it. signal S2: ... begin S2 <= not S1; -- name references A.B1.S1; end block; end; 4) The @ and ! for external perspective names. Unless we put the library name into the pathname, we have a problem with ambiguous names unless packages are some how indicated by a prefix. Take the following libraries and design units. Library TEST PACKAGE P1; Library UTIL PACKAGE P2 library test; use test.p1.all; package p2 .... end package; Library Design ENTITY TEST -- has port P1; library util; use util.p2.all; entity test is port ( p1 : bit ); end entity; The user now specifies Design.test as the design root for elaboration. If the pathname doesn't have specify the name test.p1 could be referring the port p1 or the package p1. 5) Since the names have architecture and entity in the pathname, it gives the compiler enough information to resolve type information and visiblity without having do elaborate the design. On the other hand it locks the design down so swapping between alternative architectures would require pathnames to be changed even if the instance hierarchy hasn't changed. Erich Marschner wrote: > Review of FT-32 : Unification of PathName and Instance Name for PSL, VHPI, and VHDL > ===================================================================== > > This started out to be a review, but it has turned into a revised (or perhaps complementary?) > approach. > > FT-32 starts with this summary: > > Enhancement/Requirements Summary: > ============================================================ > Formulate a common notation for path [and instance] names > within VHDL for use by PSL, VHPI and VHDL hierarchical reference > > The fundamental assumption here is that it would be good to have a common syntax for > pathnames for PSL, VHPI, and VHDL. I think this assumption goes a bit too far. > > There are two distinct perspectives from which a VHDL design may be regarded: from inside > the design, and from outside the design. (By 'design' I mean the elaborated hierarchy of VHDL > design units, some of which may represent the design, and some may represent test structures > for the design.) I think the requirements for the structure of names are somewhat different for > the two perspectives, although they are related. > > From the outside, we can view the (elaborated) design (hierarchy) as a nesting of named items, > most corresponding to scopes within which other names are declared. There must be a unique > name for the whole hierarchy (or it must be understood from the context), and given that, we > must be able to define a unique pathname to any named element in the design, including even > dynamically created elements whose lifetimes are transient. This is the perspective adopted by > VHPI, and some (all?) of the pathname attributes; it is also the perspective that needs to be used > in external reports (e.g., log files, error messages, etc.). > > From the inside - i.e., from any point in the text of a VHDL design unit - the perpsective is a bit > different. What is visible at that point is a function of the applicable context clauses and the > scope and visibility rules. In general, to avoid verbosity in the text, we do not want to use fully > qualified, absolutely unique names here; instead we want to use minimally qualified names > (simple names if they are directly visible; minimally qualified "expanded names" if they are not). > In fact, the syntax defines a number of places where simple names are visible by selection, such > as formals within a port or generic map, or entity/architecture names in a configuration, precisely > so that the shortest possible names can be used. > > So let me restate the goal, as I see it: > > Enhancement/Requirements Summary: > ============================================================ > Formulate a notation for fully unique, hierarchical names for all named elements > in a VHDL design hierarchy, for use in "external perspective" situations, such that > these "external names" are syntactically consistent with the simple and expanded > names already in use within VHDL (the "internal perspective"). > > In the process, enable expanded names to have more global extent within VHDL, > and in particular, ensure that expanded names support the usage required by PSL > vunits. > > To accomplish the above, I think we need to build up from the existing expanded name syntax, > both to leverage the existing capabilities of the language and to ensure consistency. > > Expanded names already provide a means of referring to > - a name in a package in a library > - a name in the same or an enclosing declarative region (for use when the name is not directly > visible) > > The first level of extension would be to remove the restriction that the second form of expanded > name only appear within the scope in which the final simple name is declared (1076-2002, clause > 6.3, par. 8, last sentence). This would allow "cross block references" within an architecture, for > example, > > architecture A of E is > begin > B1: block > signal S1: Bit; > begin > S1 <= A.B2.S2; -- extended expanded name > end block; > B2: block > signal S2: ... > begin > S2 <= not B1.S1; -- extended expanded name > end block; > end; > > From the "internal perspective", such extended expanded names would only need to start with > the innermost directly visible named scope necessary. In the limit, this would be the name of > the enclosing design unit. Such expanded names would be restricted to refer only to statically > elaborated items, and might be further restricted to avoid order of elaboration issues (e.g., > such a name referring to a remote type declaration could not be used in an object declaration > before the type itself is elaborated). > > Note that a reference to (the name of) the enclosing design unit cannot be interpreted strictly > as either a "compiled library unit" reference or as an "elaborated design hierarchy" reference. > It operates as both. In fact, I would argue that the strong distinction between library unit and > design hierarchy contexts made in the proposal obscures more than it clarifies. (I realize that > this differentiation has been in place in the VHPI for a long time, so I won't suggest removing > it, but at least from the "internal perspective" of pathnames used within the language, we > should recognize that the strong distinction cannot always be made.) > > Once we have the ability to use expanded names anywhere within (an instance of) a design unit, > the expanded name syntax can be further extended to allow references to names elsewhere in the > design hierarchy. There are two issues to address here: extending an expanded name downward, > from an already visible starting point (such as the immediately enclosing block name); and > identifying a starting point that is not already visible. > > Extending an expanded name downward is relatively easy - just continue the dotted name syntax > "through" a component instantiation. Exactly which of the names involved (component instance > label, entity name, architecture name, configuration name) should be included in the expanded > name syntax may be a point of discussion, but using '.' to separate names in constructing a > pathname that extends downward through an instantiation is the obvious thing to do. > > Starting an expanded name elsewhere in the design hierarchy (either at the root, or at any instance > of a given design unit) requires some way of specifying that starting point, one that is consistent > with the scope and visibility rules of the language. The two cases could be unified by allowing an > expanded name to start with any design unit name, which could be either that of the topmost > design unit (the root of the design hierarchy) or of an entity that is instantiated one or more times > in the design hierarchy. This would be consistent with the existing ability to use an expanded name > to refer to (names declared within) a statically elaborated package. And since the language already > defines context clauses and scope and visibility rules that enable design unit names to be referred to > within VHDL text, nothing more elaborate is required. For example, given the following library > structure: > > -- in Library Design: > package P > package body P > entity E > architecture A of E -- with instances C2:E2 and C3:E3 > entity E2 > architecture A2 of E2 > entity E3 > architecture A3 of E3 > > -- in Library Test: > entity TB > architecture One of TB -- with instance DUT: E(A) > architecture Two of TB -- with instance DUT: E2(A2) > > it should be possible to use the following extended expanded names within the source text of > the above design units, assuming only that the appropriate library clauses appear to make the > library names visible at the point at which the expanded names appear: > > Design.P -- already allowed > Design.E(A).C2.E2.p1 -- where p1 is declared in E2 > Design.E(A).C3.E3(A3).x.y.z -- where x.y.z is an expanded name for z in y in x in A3 > Test.TB(One).DUT.E(A).etc. > Test.TB(Two).DUT.E2(A2).etc. > > Furthermore, if the appropriate use clauses are also present (e.g., "use Design.*; use Test.*"), and > there are no occurrences of homographs in the two libraries that would cause one or more of the > design units to NOT be directly visible, then the following names should be valid as well: > > P > E(A).C2.E2.p1 > E(A).C3.E3(A3).x.y.z > TB(One).DUT.E(A).etc. > TB(Two).DUT.E2(A2).etc. > > Note that the PSL requirement is effectively from the "internal perspective" - especially once PSL > vunits become VHDL design units. The requirement is simply to allow a PSL vunit to specify the > design unit or instance to which it applies, much like a configuration now specifies the design unit > to which it applies. In the simplest case, a PSL vunit should be able to do so by simply referring > to the entity (and optionally to the architecture) to which it applies, just as a configuration refers to > the entity to which it applies (and to its architecture, in a nested block configuration). The more > general case of applying a vunit to an instance within the hierarchy would be served by allowing > extended expanded names as described above - e.g., > > vunit V (Design.E(A).C3.E3(A3)) { > ... > } > > Note that such an extended expanded name essentially refers to a set of instances of the specified > design unit within the design hierarchy - the set of instances of E3(A3) that are all instantiated > under Design.E(A) as component C3. (This is what Peter referred to as 'wildcard' pathnames.) > Clearly pathnames of this sort can only be used in restricted situations, in which reference to a set > of items makes sense. This usage in PSL is one such case. We might also consider extending > configurations to apply to instances in addition to design entities, in which case this kind of > extended expanded name would also be of interest there. > > So why do we need to define pathnames that begin with '@' or '!' ? I am coming to the conclusion > that we do not need such pathnames from the "internal perspective" point of view - the existing > library and use clauses (along with the scope and visibility rules) give us the starting point we > need for any pathname, and the syntax for expanded names can be extended easily to create > pathnames relative to any starting point. > > Do "external perspective" pathnames need to start with special characters? Perhaps they do. > In the VHPI context, there is a need to distinguish between instantiated access and uninstantiated > access. Also, in external contexts, it may be useful to encode more semantic information into the > pathname, so that readers (including simple tools such as scripts that process log files) don't need > (as much) access to symbol table information in order to understand those pathnames. But in any > case, I would argue that such "external perspective" pathnames should be a simple extension of the > "internal perspective" pathnames described above, which in turn are just an extension of the existing > expanded names. > > Regards, > > Erich > -- -- mailto: johnr@model.com phone: (503)685-0864 -- http://www.model.com fax: (503)685-0921 --Received on Thu Aug 4 17:30:12 2005
This archive was generated by hypermail 2.1.8 : Thu Aug 04 2005 - 17:30:33 PDT