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