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

It was difficult for me to follow all the rapid e-mails on this, but my
answers to the issues are below.

Dave

 

 

________________________________

From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Daniel Mlynek
Sent: Wednesday, July 16, 2008 12:54 AM
To: sv-bc@server.eda-stds.org
Cc: 'Sergei Zaychenko'
Subject: [sv-bc] package vs packge ; package vs module override issues

 

I've doubts what should be the bahaviour in below cases:

 

 

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.

 

ISSUE 222222222222222222222222222222:

This issue is much more interesting. Package and module cannot be used
in the same cotext because its nature is different - so maybe it should
be allowed in common and separate compilation units - and in both cases
both package p and module p should exist in desing?

package p;
int a=1;
endpackage

 

module p;
int a=2;
initial $display(p.a, p::a);
endmodule

[DR] This is legal as you note that packages and modules are in
different namespaces (3.12.b) and the scope operator (::) disambiguates
them. Mantis 1214 needs to be resolved for the scope operator, but I
think this can be an easy search order rule, look for the package first,
then class

 

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.


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