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 1st and 2nd
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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.