Arturo, I agree that allow interfaces and the like in packages would, at one level, not produce any substantive issues. I would however have very serious concerns about how to align the various rules involved with name resolution, implicit instantiation, the design unit namespace, etc, etc. For interfaces in particular, I would have much, much preferred to have those as package elements rather than design elements since that would make it much easier to deal with questions about the effective type of a virtual interface. For that reason alone, I would strongly support working towards figuring out how to deal with the namespace questions. Checkers though raise the ante quite a bit. Since they can have untyped args but also have "instantiation like" semantics, they open up serious questions about the relationship between types, instantiations, and other design relationships. This would be even more troublesome if one wanted checkers to be "design unit like" for the purposes of "bind" or similar late design unit instantiation. Gord Arturo Salz wrote: > Dave, > > > > I don’t follow your reasoning. I fail to see how restricting modules or > interfaces from having hierarchical references would render them > useless. Also, I don’t see how a allowing the definition (not > instantiation) of modules, programs, or interfaces in packages would > affect the rest of the design, the creation of events, and the like. As > a matter of fact, allowing interfaces in packages is something that > would considerably simplify things – and interfaces rarely require > hierarchical references. From that perspective, allowing checkers and > interfaces seems like a natural and desirable extension. > > > > Arturo > > > > *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of > *Rich, Dave > *Sent:* Thursday, April 17, 2008 1:33 AM > *To:* Korchemny, Dmitry; Mirek Forczek; sv-ec@eda.org > *Cc:* sv-ac@eda.org > *Subject:* RE: [sv-ec] 1900 mantis (checkers): checker in package ? > > > > There are two main reasons for the limitations of “units” in packages. > The first is to eliminate hierarchical references and declaration before > use issues needed for a well defined, orderly elaboration of the design. > By definition, every symbol in a package must be declared before > reference. I suppose you could restrict modules defined in packages to > exclude these constructs, but then they would no longer be of much use. > The other reason is that existence of a package should not matter to the > rest of the design if it is never referenced. (PLI/DPI excluded). That > is, you shouldn’t have a package creating events that might affect the > rest of the design if that package is never referenced. This is relevant > in a separate compilation environment where you would compile many > packages and only reference some of them. Whether a package is “used” or > not becomes a complex question in the presence configurations, > generates, and other library mechanisms. > > > > > > Dave > > > > > > ------------------------------------------------------------------------ > > *From:* owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] > *On Behalf Of *Korchemny, Dmitry > *Sent:* Thursday, April 17, 2008 12:11 AM > *To:* Mirek Forczek; sv-ec@server.eda.org > *Cc:* sv-ac@server.eda.org > *Subject:* RE: [sv-ec] 1900 mantis (checkers): checker in package ? > > > > Hi Mirek, > > > > I don’t know the reason why there are limitations on modules, interfaces > etc. in packages. I am not sure I understand your second suggestion. > Could you be more specific and provide an example? > > > > Thanks, > > Dmitry > > > > ------------------------------------------------------------------------ > > *From:* owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] > *On Behalf Of *Mirek Forczek > *Sent:* Wednesday, April 09, 2008 5:35 PM > *To:* Korchemny, Dmitry; sv-ec@server.eda.org > *Cc:* sv-ac@server.eda.org > *Subject:* RE: [sv-ec] 1900 mantis (checkers): checker in package ? > > > > Hi Dmitry, > > > > I'm not against allowing checker declarations in packages - in general. > > > > But still I will keep the following position: > > > > the 'checker' belongs to the 'units' category along with 'module', > 'program', 'interface', etc. > > > > > > To keep language consistent I would see only 2 possible situations: > > > > 1) let's allow checkers declarations in packages, but then other 'units' > declarations shall be allowed in package too .. > > > > 2) none of the 'units' declarations are allowed in a package, (this way > a 2005 LRM line will be kept), > > > > why 'checker' shall be exceptional here ? > > > > > > The need for organizing assertions library in a package could be > satisfied with properties and sequences declarations (already allowed in > package), if only property and sequence could contain same set of > seb-declarations as the checker can (i.e.: checkvar declaration - why > not to allow it inside property/sequence ?). > > > > Does the lack of 'module', 'program', 'interface' declarations in > package stops people from organizing their design/testbenches libraries > in a package ? > > (mayby indeed it stops them, or there is some coding pattern to take > benefit from package anyway - could it be applied with assertions and > checkers too ?) > > > > Mirek > > > > ------------------------------------------------------------------------ > > *From:* Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] > *Sent:* 9 kwietnia 2008 15:50 > *To:* Mirek Forczek; sv-ec@server.eda.org > *Cc:* sv-ac@eda.org > *Subject:* RE: [sv-ec] 1900 mantis (checkers): checker in package ? > > Hi Mirek, > > > > I think that it is natural and important to allow checker declarations > in packages. One of the main checker goales is to serve an assertion > library checker (sorry for confusion because of different use of the > word “checker”). The people will certainly want to organize their > assertion library in a package, and I don’t why this should be forbidden. > > > > Thanks, > > Dmitry > > > > ------------------------------------------------------------------------ > > *From:* owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] > *On Behalf Of *Mirek Forczek > *Sent:* Monday, April 07, 2008 3:18 PM > *To:* sv-ec@server.eda.org > *Subject:* [sv-ec] 1900 mantis (checkers): checker in package ? > > > > The "25 Package declarations" section allows to declare checker in a > package. > > > > > > Till now I've considered checker as a unit - similar to the other units > such as: module, interface, program, etc. > > > > > > Once the module, interface, program, etc. are not allowed to be declared > in a package, there should be no room for checker in a package too, IMHO. > > > > Allowing check in package seems to be inconsistent with the rest of the > package-related language rules, it constitute a special exception for > checker only, and will probably result in a chain of special exceptions > for checker only. > > The first one is already in a proposal: > > > > The 1800-2005 containes rule: > > > > Packages must not contain any processes. > > > > which will be broken now with: > > > > Packages may contain processes inside checkers only. > > > > > > As for me: the 1800-2005 statement is an one more argument for: > > > > - not to allow check declaration in package, > > > > or to: > > > > - (consider to) allow checker and other units delcarations in package ... > > > > > > > > It is also possible that the original motivation for allowing checkers > declarations in package was to allow (other than sequence and property) > declarations specific for checkers (i.e.: checkvars) - to be part of > the package encapsulated definitions. > > > > In such case a move of these definitions from checker scope to the > sequence / property scope shall be considered. > > (The sequence and property declarations are already allowed in package. > And they have full parametrization capabilities, so they can be easily > connected with checker interface at the instantiation place.) > > > > A checker itself - as a grouping construct - similar to the other > grouping constructs (module, interface, program) do not deserve to be in > a package if the other ones do not deserve the same. > > > > > > Regards, > > Mirek > > --------------------------------------------------------------------- > > Intel Israel (74) Limited > > > > This e-mail and any attachments may contain confidential material for > > the sole use of the intended recipient(s). Any review or distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. > > --------------------------------------------------------------------- > > Intel Israel (74) Limited > > > > This e-mail and any attachments may contain confidential material for > > the sole use of the intended recipient(s). Any review or distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Apr 17 07:48:31 2008
This archive was generated by hypermail 2.1.8 : Thu Apr 17 2008 - 07:50:04 PDT