Manjit, I think all the naming issues you mention are addressed in VHPI with the exception of mixed language. If you disagree, let's talk about it. The mixed language problem was hard to tackle in the context of the PARs for the standards work. It was a documented rejected requirement to explicitly support it, but we agreed to do nothing to prevent mixed language interoperability that we could anticipate. It is not limited to naming problems. I agree it is important and I hope Accellera takes it on at some point. Regards, John ----------------------------------- Jim Lewis wrote: > Forwarded for Manjit whose original message bounced (issue fixed) ... > > > Few other important things to remember > > 1: How to resolve the pathname when it contains unnamed processes, > Blocks etc > > 2: For generates has an index and all vendors implicitly use index in > the name > such as gen__1, gen__2 or gen(1), gen(2) etc... > > 3: The names should follow the same rules of case insensitive names > > 4: In most practical situations Elaborated hierarchy is a Mixed > VHDL/Verilog name (with verilog case sensitive and VHD names case > insensitive). Some may say it's beyond the scope of VHDL standard. But > in my mind those are important issues to deal with. Majority of designs > are Mixed Language in nature. > > 5: Add escaped, extended identifiers in the mix to more complex > pathnames > > 6: Distinguish a Record field separator with the hierarchy separator '.' > > It would be good if the language also specifies a way to identify > pathnames which can be unique for all vendors. > > But it is all doable, and is important. The need is there form > Assertion/TB/Debug/GUI point of view. All vendors use some > implementation of pathnames already and the solutions are all messy and > non standard. We need read and write both as TB/Debug needs to drive > values. This issues is going to be a touchy and complex one. But is one > of the important one to resolve. > > Manjit > > > -----Original Message----- > From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf > Of John Ries > Sent: Friday, August 05, 2005 8:21 AM > To: Erich Marschner > Cc: vhdl-200x@eda.org; vhdl-200x-ft@eda.org > Subject: Re: [vhdl-200x] Review of FT-32 > > Thanks for the comments, I have a few responces intersersed below. > > Regards, > John > > Erich Marschner wrote: > >> John, >> >> Thanks for the feedback. See my responses interspersed below. >> >> Regards, >> >> Erich >> | -----Original Message----- >> | From: owner-vhdl-200x@eda.org | [mailto:owner-vhdl-200x@eda.org] On >> Behalf Of John Ries >> | Sent: Thursday, August 04, 2005 8:23 PM >> | Cc: vhdl-200x@eda.org; vhdl-200x-ft@eda.org >> | Subject: Re: [vhdl-200x] Review of FT-32 >> | | I have a few random questions and comments. >> | | | 1) I like the idea of using expanded names and just extending | >> them for hierarchical names. >> >> Glad to hear that. >> >> | | 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. >> >> There is no syntactic difference. This is similar to the situation > > with overloaded operators - a given symbol represents a set of > definitions. The question is how a reference is narrowed down to a > unique member of the set. For overloaded operators, it only makes sense > to refer to one member at a time, so the overload resolution rules must > always give a unique answer, or else an error occurs. In this case, one > can imagine situations in which we might want to refer to more than one > member of the set (e.g., when we are attaching assertions to a subset of > all instances of a given design unit), so the semantics may allow > multiple meanings for a given pathname in cases where that makes sense. > >> >> Note that the notion of referring to a set of objects already exists > > in the language. For example, attribute specifications can refer to a > set of entities of the same class, and set the same attribute of all > those entities to the same value in one specification. > >> >> | | 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; >> >> I believe the requirement for an elaboration-time check just goes with > > territory; it is not unique to a particular syntax for hierarchical > pathnames. Any pathname that crosses a hierarchy boundary would not be > resolvable until elaboration anyway, so any occurrence of such a > hierarchical pathname would have to be checked at elaboration time to > make sure it makes sense. > >> > I think there are two classes of error. > 1) Does the object exist and this can't be done until elaboration > time. > 2) Does the name denote a set or a single item? The context will > tell us what is > legal and this can be checked at elaboration time. My question is > it a requirement > or desirable to be able to flag the error at compile time? I don't > have a strong > opinion, but it nice to tell users errors as early as possible. > >> To make this a bit more crisp, suppose we define (by analogy to static > > expression categories) the categories "locally extended expanded names" > and "globally extended expanded names". The former would be those that > can be resolved at compile time, because they are local to a design unit > (e.g., the "cross block references" I mentioned in an example). The > latter would require resolution at elaboration time, because they cross > instance boundaries. > >> >> | | 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. >> >> If I understand your statement correctly, I would agree. >> >> In general, the object to which an extended expanded name refers must > > have been elaborated before the extended expanded name is first > evaluated. This includes use of an extended expanded name in a use > clause, in a declaration, in a statement, etc. The practical effect is > that extended expanded names would probably be most useful in statements > that are not executed until after the design is completely elaborated. > Using them in context clauses, in declarations, and in statements that > are part of functions called during elaboration would require more care > to avoid order of elaboration problems. > >> >> Again, this is true regardless of the syntax used to represent a > > hierarchical pathname. > > I agree, but I like the the ability to use the USE statement to > locate a check someplace in the hierarchy and not > have to keep typing long names over and over again. > Related to my item 5, I believe that your pathnames have enough > information in them that we can tell the > intended entity/architecture that the pathname terminates in. > For example the name Design.E(A).C3.E3(A3).x.y.z has sufficient > information to tell that x.y.z is some > object that exists within entity E3 architecture A3. At some point > prior to elaborating the design E3(A3) must > exits and the system can to things like overload resolution with out > having to actually elaborate the design. > This doesn't mean that the path will resolve at elaboration time, but > if it does, then we can know earlier at least > some of the information about the target object. > >> >> | | 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; >> >> I would be more inclined to simply prohibit use of an extended > > expanded name in a use clause. The current LRM allows only selected > names in use clauses, and it is clear from the definition that such > names must have a prefix that denotes a package. I would recommend > leaving that definition alone. > >> >> >> | 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. >> >> Let's distinguish carefully between the "internal" and "external" > > perspectives here. > >> >> Specifying the design root for elaboration is an external operation. > > (There is no place in a VHDL design unit that one can specify this.) So > the syntax for the name of the design root used in an external context > could be different from that for hierarchical references within the > language. Even if it is the same, there may be additional factors that > affect its interpretation - e.g., environment variables, tool settings, > search rules, log file headings, etc. that are part of the tool > environment. For example, in the situation you describe above, the > elaborator may have been given the work library as a separate command > line option, and that might determine how to interpret "Design.test". > >> >> On the other hand, referring to a pathname such as "test.p1" might > > occur within the language, and such a reference might be ambiguous. For > example, one might write "use test.p1;", in which case the scope and > visibility rules would need to determine whether "test" meant Library > Test or entity Test in Library Design. But this kind of potential > ambiguity is already possible in VHDL, and there are already > disambiguation rules that handle it, so I would argue that there is no > point in worrying about this. > >> >> Would it be useful to adopt a standard way of encoding semantic > > information (such as "the following name is a library name") into a > hierarchical pathname? It certainly might, for pathnames used outside > of the language. For example, if a library name were always preceded by > '@' in pathnames that are printed into log files, then a simple script > could determine that "@Design.Test" means something different from > "Design.Test". And by extension, pathname attributes that return > strings (which might be printed into log files, but are typically not > interpreted from within the design hierarchy) might adopt the same > convention. And of course, VHPI calls would benefit from such a > convention, especially if it uses different characters to distinguish > between instantiated and uninstantiated access (as proposed in FT-32). > >> >> But I wouldn't recommend adopting this mechanism for pathnames used > > within the language, for the following reasones. First, it isn't > necessary: we already have name resolution rules that suffice to > determine the meaning of a name used in a VHDL context. Second, just > adding this convention would mean that there would be two ways of > representing the same name within the language, e.g., Design.Test and > @Design.Test, which would be confusing. Third, going further and > requiring the use of '@' on library names would not be backward > compatible. So I would recommend adopting this kind of a convention > only for pathnames that do not appear as part of the syntax of the > language - those that appear in the tool environment (command arguments, > VHPI arguments, log file headers, etc., and possibly those that are > values of pathname attributes. > >> > Sorry, I didn't mean to adopt the mechanism for "internal" names. It > just that I've had a number of discussions with > people that don't see why if the "internal" name is unambigious, how can > it be ambigous as an "external" name. I had > thought you considered the @ and ! as syntax sugar to help some tools > but not really needed. > >> >> | | 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. >> >> Yes, using globally extended expanded names would definitely have the > > side effect of creating dependencies that "lock down" parts of the > design - much like configurations do, by locking down the binding of > component instances to entities (though with a different, much more > verbose syntax). (And I would argue that, if you swap alternative > architectures, the instance hierarchy HAS changed.) But again, I think > this just goes with the territory; it has nothing to do with the syntax > used to express hierarchical pathnames. > >> >> | | > > > >Received on Fri Aug 5 11:05:41 2005
This archive was generated by hypermail 2.1.8 : Fri Aug 05 2005 - 11:05:45 PDT