As Daniel wrote, although the package declaration is "physically" located in the compilation unit, its name is not part of the compilation-unit scope name space, but rather in the package name space. From 3.12: b) The package name space unifies all the package identifiers defined among all compilation units. Once a name is used to define a package within one compilation unit, the name shall not be used again to declare another package within any compilation unit. c) The compilation-unit scope name space exists outside the module, interface, package, program, and primitive constructs. It unifies the definitions of the functions, tasks, parameters, named events, net declarations, variable declarations, and user-defined types within the compilation unit scope. Shalom ________________________________ From: Surya Pratik Saha [mailto:spsaha@cal.interrasystems.com] Sent: Wednesday, July 16, 2008 12:30 PM To: Bresticker, Shalom Cc: Daniel Mlynek; sv-bc@eda.org; Sergei Zaychenko Subject: Re: [sv-bc] package vs packge ; package vs module override issues But, I think this is an 'redefinition error' case, as class 'P' and package 'P' are declared in same name space, i.e. compilation unit scope. Regards Surya -------- Original Message -------- Subject: Re:[sv-bc] package vs packge ; package vs module override issues From: Bresticker, Shalom <shalom.bresticker@intel.com> <mailto:shalom.bresticker@intel.com> To: Daniel Mlynek <daniel.mlynek@aldec.com> <mailto:daniel.mlynek@aldec.com> , Surya Pratik Saha <spsaha@cal.interrasystems.com> <mailto:spsaha@cal.interrasystems.com> Cc: sv-bc@eda.org, "Sergei Zaychenko" <Sergei.Zaychenko@aldec.com> <mailto:Sergei.Zaychenko@aldec.com> Date: Wednesday, July 16, 2008 2:56:14 PM Yes, that issue is mentioned in Mantis 1214. I don't know whether the issue was ever resolved, but the Mantis is still open. Thanks, Shalom ________________________________ From: Daniel Mlynek [mailto:daniel.mlynek@aldec.com] Sent: Wednesday, July 16, 2008 12:21 PM To: Bresticker, Shalom; 'Surya Pratik Saha' Cc: sv-bc@eda.org; 'Sergei Zaychenko' Subject: RE: [sv-bc] package vs packge ; package vs module override issues Yes, but LRM allows to use :: for both class and package and put both into different name spaces - what are the searching rules for case like below - I cannot find them neither in compilation unit scope chapter neither in scope rules chapter package P; typedef reg T; endpackage class P; typedef reg T; endclass module M; P::T r; // which definition is referred here ? is there any way to refer the other one in such situation ? endmodule DANiel ________________________________ From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] Sent: 16 lipca 2008 11:12 To: Surya Pratik Saha Cc: Daniel Mlynek; sv-bc@eda.org; Sergei Zaychenko Subject: RE: [sv-bc] package vs packge ; package vs module override issues Why is it a problem? The reference in test is clearly to the module top. References to contents of top are disambiguated by whether top is followed by a period or a double colon. Shalom ________________________________ From: Surya Pratik Saha [mailto:spsaha@cal.interrasystems.com] Sent: Wednesday, July 16, 2008 12:06 PM To: Bresticker, Shalom Cc: Daniel Mlynek; sv-bc@eda.org; Sergei Zaychenko Subject: Re: [sv-bc] package vs packge ; package vs module override issues Hi, Consider the following case: module top; endmodule package top; endpackage module test; top t(); endmodule Is it a valid case? I think package and module should share same name space, LRM needs correction here. Regards Surya -------- Original Message -------- Subject: Re:[sv-bc] package vs packge ; package vs module override issues From: Bresticker, Shalom <shalom.bresticker@intel.com> <mailto:shalom.bresticker@intel.com> To: Daniel Mlynek <daniel.mlynek@aldec.com> <mailto:daniel.mlynek@aldec.com> , sv-bc@eda-stds.org Cc: "Sergei Zaychenko" <Sergei.Zaychenko@aldec.com> <mailto:Sergei.Zaychenko@aldec.com> Date: Wednesday, July 16, 2008 1:40:52 PM Hi, In Draft 6, 3.12 says, "The package name space unifies all the package identifiers defined among all compilation units. Once a name is used to define a package within one compilation unit, the name shall not be used again to declare another package within any compilation unit." So the first case should be illegal. Module and package names are in different name spaces, so I think it is legal to have a package and a module with the same name. The LRM does not explicitly say whether a user-defined package can have the name std. I would expect it to be illegal. Shalom ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Daniel Mlynek Sent: Wednesday, July 16, 2008 10:54 AM To: sv-bc@server.eda-stds.org Cc: 'Sergei Zaychenko' Subject: [sv-bc] package vs packge ; package vs module override issues I've doubts what should be the bahaviour in below cases: ISSUE 111111111111111111111111111111: 1st compilation unit: package p; int a=1; endpackage 2st compilation unit package p; int a=2; endmodule Above packages compiled in single compilation - is clearly for me tool dependend, but compiled as shown above? should it behave the same module overriden in separate compaltion- i mean package defined in 2nd compilation will override 1st one in whole design? ISSUE 222222222222222222222222222222: This issue is much more interesting. Package and module cannot be used in the same cotext because its nature is different - so maybe it should be allowed in common and separate compilation units - and in both cases both package p and module p should exist in desing? package p; int a=1; endpackage module p; int a=2; initial $display(p.a, p::a); endmodule ISSUE 333333333333333333333333333333333: what about overriding std package - with user defined module or package with "std" name? rules should be the same as in above cases? so defining package std; should override predefined std package which will be no longer avaible? -- 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. --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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, and is believed to be clean.Received on Wed Jul 16 02:44:18 2008
This archive was generated by hypermail 2.1.8 : Wed Jul 16 2008 - 02:44:56 PDT