Well, I try to spread good humor, but I'm not being facetious. I agree with your concern here: we have to set some minimums. How about saying "... two are global within bounds that span multiple compilation units, but are otherwise unspecified by this standard" Since the sentence is getting rather long, and (at its top level) is an enumerated list, it could be formatted as a bulleted list. Bresticker, Shalom wrote: > That's being facetious. > > The globality of the name spaces for modules and packages is necessary > so that a module/package from any compilation unit can be > instantiated/imported from any other compilation unit, except that > packages have the additional restriction that a package declaration has > to precede its import, either in the same compilation unit or in a > preceding compilation unit. > > That requirement still holds. > > You can specify something new as long as it will still be > back-compatible with 1800-2005. But "global within bounds not specified" > is a backwards step, not a forwards one. > > As I said, the whole concept of libraries is not specified well. > > Shalom > >> -----Original Message----- >> From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com] >> Sent: Friday, July 18, 2008 6:56 AM >> To: Bresticker, Shalom >> Cc: Greg Jaxon; Gordon Vreugdenhil; Daniel Mlynek; Rich, >> Dave; sv-bc@eda-stds.org; Sergei Zaychenko >> Subject: Re: [sv-bc] package vs packge ; package vs module >> override issues >> >> 3.12: >>> SystemVerilog has eight name spaces for identifiers: two are global >>> (definitions name space and package name space), two are >> global to the >>> compilation unit (compilation unit name space and text >> macro name space), and four are local. >> >> We could say "... two are global within bounds not specified >> by this standard" >> >> In 1976, a fellow student advised me to give up Computer >> Science because all the algorithms had already been written. >> For a moment as I read this name space description, I thought >> I was hearing the same argument, and I had a vision of all >> regression tests failing due to the design names already >> being taken - all bug reports closed as unreproducible! >> >> Greg >> >> Bresticker, Shalom wrote: >>> It nevertheless explicitly contradicts what is already in >> the LRM. If >>> you think it is wrong, then propose to either remove it or >> redefine it. >>> Maybe you want to distinguish between libraries and non-libraries. >>> >>> Shalom >>> >>>> -----Original Message----- >>>> From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com] >>>> Sent: Friday, July 18, 2008 3:05 AM >>>> To: Gordon Vreugdenhil >>>> Cc: Bresticker, Shalom; Daniel Mlynek; Rich, Dave; >>>> sv-bc@eda-stds.org; Sergei Zaychenko >>>> Subject: Re: [sv-bc] package vs packge ; package vs module >> override >>>> issues >>>> >>>> I have to agree with Gord. Especially since packages p and q are >>>> defined in section 25.3 and then redefined in section 25.5 :-) >>>> >>>> Greg >>>> >>>> Gordon Vreugdenhil wrote: >>>> >>>>> Whether a tool views a package compilation as a >> re-compilation or a >>>>> conflicting declaration is currently undefined in the LRM >>>> and I would >>>>> likely object to defining it. It is clear that you can't >>>> overload a >>>>> package name, but in practice, that already occurs across >>>> libraries, >>>>> so I don't think that further restricting things in the LRM >>>> will reach >>>>> consensus nor would it likely be respected in >>>> implementations due to >>>>> existing flows. >>>>> >>>>> Gord. >>>>> >>>>> >>>>> Bresticker, Shalom wrote: >>>>>> I can't accept Dave's position. As Daniel has quoted, >>>>>> >>>>>> >>>>>> "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.*" >>>>>> >>>>>> and also >>>>>> >>>>>> "Once a name is used to define a module, primitive, program, or >>>>>> interface within one compilation unit, the name shall >> not be used >>>>>> again (in any compilation unit) to declare another >>>> non-nested module, >>>>>> primitive, program, or interface outside all other declarations." >>>>>> >>>>>> I think the LRM is as explicit as it can be that you >>>> cannot elaborate >>>>>> together one or more compilation units that contain two package >>>>>> declarations with the same name or two module declarations >>>> with the >>>>>> same name. >>>>>> >>>>>> (Though how that squares with the use of configurations >> to select >>>>>> different versions of the same module for different >>>> instantiations is >>>>>> a question I've never gotten an answer to, and there is >>>> also an open >>>>>> Mantis on that issue.) >>>>>> >>>>>> Regarding overriding std, I agree that it is not allowed. >>>> However, I >>>>>> don't think it is obvious from the LRM, and therefore I think it >>>>>> needs to be more explicit. In fact, using the reverse of Dave's >>>>>> logic, I could claim that since in other places, the LRM >>>> bothers to >>>>>> explicitly forbid overriding of a name, then it >> implicitly implies >>>>>> that it *is* allowed where such a statement does not appear. >>>>>> >>>>>> Shalom >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> -------------------------------------------------------------- >>>> ---------- >>>>>> *From:* Daniel Mlynek [mailto:daniel.mlynek@aldec.com] >>>>>> *Sent:* Thursday, July 17, 2008 10:06 AM >>>>>> *To:* 'Rich, Dave'; Bresticker, Shalom; >>>> sv-bc@server.eda-stds.org >>>>>> *Cc:* 'Sergei Zaychenko' >>>>>> *Subject:* RE: [sv-bc] package vs packge ; package vs module >>>>>> override issues >>>>>> >>>>>> */>[DR] std is a built-in package and cannot be >>>> overridden. It is >>>>>> not a reserved keyword, but just like any other >>>> built-in name, you >>>>>> cannot override a built-in name within the namespace it is >>>>>> defined. /* >>>>>> >>>>>> */>You should be able to extend the classes defined in std. >>>>>> However there is no way represent the mailbox class >>>> using SV syntax >>>>>> (mantis 1714) or the presence of arguments to randomize./* >>>>>> >>>>>> />[DR] /This is a tool issue. In a separate >>>> compilation model, how >>>>>> does one distinguish between two compilation units, and a >>>>>> re-compilation of the same unit? >>>>>> >>>>>> >>>>>> The idea in LRM is rather clear that it should be >>>> forbidden - if it >>>>>> cannot be implemented - as you claim then maybe it >>>> should be changed >>>>>> - and overriding described in this place: >>>>>> >>>>>> "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.*" >>>>>> The issue commes when we have: >>>>>> 1st compilation: >>>>>> package p; >>>>>> int a; >>>>>> endpackage >>>>>> module top; >>>>>> initial $display(p::a); >>>>>> initial $display(p::r);// this would be visible after 2nd >>>>>> compilation - but here should trigger syntax - unknown >>>>>> endmodule >>>>>> 2nd compilation: >>>>>> package p; >>>>>> int r; >>>>>> endpackage //after this was compiled p gets overriden >>>> and there is >>>>>> no more p::a in the design - elaboration failure? >>>>>> module top1; >>>>>> initial $display(p::r); >>>>>> endmodule >>>>>> DANiel >>>>>> >>>>>> >>>>>> >>>> -------------------------------------------------------------- >>>> ---------- >>>>>> *From:* Rich, Dave [mailto:Dave_Rich@mentor.com] >>>>>> *Sent:* 16 lipca 2008 21:28 >>>>>> *To:* Bresticker, Shalom; Daniel Mlynek; >>>> sv-bc@server.eda-stds.org >>>>>> *Cc:* Sergei Zaychenko >>>>>> *Subject:* RE: [sv-bc] package vs packge ; package vs module >>>>>> override issues >>>>>> >>>>>> >>>>>> >>>>>> ISSUE 111111111111111111111111111111: >>>>>> >>>>>> 1st compilation unit: >>>>>> >>>>>> package p; >>>>>> int a=1; >>>>>> endpackage >>>>>> >>>>>> 2st compilation unit >>>>>> >>>>>> package p; >>>>>> int a=2; >>>>>> endmodule*/[DR] /* endpackage - right? >>>>>> >>>>>> 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? >>>>>> */[DR] Yes, the second package declaration should >>>> override the >>>>>> first; same as for modules. But if there were any >>>> compilation >>>>>> units in between 1^st and 2^nd that imported >>>> package p, those >>>>>> would need to get re-compiled, like in VHDL./* >>>>>> >>>>>> >>>>>> >>>>>> [SB] If it is the same as for modules, it is >>>> illegal. You can't >>>>>> compile two modules with the same name.*/[DR] >>>> /*This is a tool >>>>>> issue. In a separate compilation model, how does >>>> one distinguish >>>>>> between two compilation units, and a >>>> re-compilation of the same >>>>>> unit? >>>>>> >>>>>> >>>>>> >>>>>> 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 availed? >>>>>> >>>>>> */[DR] std is a built-in package and cannot be >>>> overridden. It is >>>>>> not a reserved keyword, but just like any other >>>> built-in name, >>>>>> you cannot override a built-in name within the >>>> namespace it is >>>>>> defined. You should be able to extend the classes >>>> defined in >>>>>> std. However there is no way represent the mailbox >>>> class using >>>>>> SV syntax (mantis 1714) or the presence of arguments to >>>>>> randomize./* >>>>>> >>>>>> >>>>>> [SB] This is not clear. For example, you can >>>> override built-in >>>>>> system tasks and functions by defining them in the >>>> PLI.*/[DR] >>>>>> /* That is allowed because it is explicitly >>>> defined. There is no >>>>>> mechanism defined for methods and packages. Whether it >>>>>> **should** be allowed may not be clear, but it's >>>> clear to be >>>>>> that it is currently not allowed since there is no >>>> mechanism to >>>>>> do so. >>>>>> >>>>>> Shalom >>>>>> >>>>>> >> --------------------------------------------------------------------- >>>>>> 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* <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. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Jul 18 08:23:19 2008
This archive was generated by hypermail 2.1.8 : Fri Jul 18 2008 - 08:24:03 PDT