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. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Jul 17 20:57:09 2008
This archive was generated by hypermail 2.1.8 : Thu Jul 17 2008 - 20:57:39 PDT