Re: [sv-bc] package vs packge ; package vs module override issues

Shalom,

In practice, large customers will generally require library
based packages.  Yes, this gets to be a serious problem in terms
of overall name resolution rules (similar to library based modules
with configurations in play).  I don't think that there will be
agreement on what "should" happen until SV actually looks at
formalizing some knowledge of libraries and more carefully examines
how to reason about sub-design encapsulation.  $unit is a big
issue here as well.  Right now there are many vendor specific
decisions that make some of this, well, interesting.

I would be very careful about what language we use in dealing
with compilation versus elaboration.  Tools already have
approaches for dealing with "re-compilation" of design elements.
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.

-- 
--------------------------------------------------------------------
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.