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

From: Daniel Mlynek <daniel.mlynek_at_.....>
Date: Wed Jul 16 2008 - 02:21:14 PDT
Yes, but LRM allows to use :: for both class and package and put both into
different name spaces - what are the searching rules for case like below - I
cannot find them neither in compilation unit scope chapter neither in scope
rules chapter
 
package P;
    typedef reg T;
endpackage
 
class P;
    typedef reg T;
endclass
 
module M;
    P::T r; // which definition is referred here ? is there any way to refer
the other one in such situation ?
endmodule
 
 
DANiel

  _____  

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: 16 lipca 2008 11:12
To: Surya Pratik Saha
Cc: Daniel Mlynek; sv-bc@eda.org; Sergei Zaychenko
Subject: RE: [sv-bc] package vs packge ; package vs module override issues


Why is it a problem? The reference in test is clearly to the module top.
References to contents of top are disambiguated by whether top is followed
by a period or a double colon.
 
Shalom


  _____  

From: Surya Pratik Saha [mailto:spsaha@cal.interrasystems.com] 
Sent: Wednesday, July 16, 2008 12:06 PM
To: Bresticker, Shalom
Cc: Daniel Mlynek; sv-bc@eda.org; Sergei Zaychenko
Subject: Re: [sv-bc] package vs packge ; package vs module override issues


Hi,
Consider the following case:
module top;
endmodule

package top;
endpackage

module test;
        top t();
endmodule

Is it a valid case? I think package and module should share same name space,
LRM needs correction here.

Regards

Surya


-------- Original Message  --------
Subject: Re:[sv-bc] package vs packge ; package vs module override issues
From: Bresticker, Shalom  <mailto:shalom.bresticker@intel.com>
<shalom.bresticker@intel.com>
To: Daniel Mlynek  <mailto:daniel.mlynek@aldec.com>
<daniel.mlynek@aldec.com>, sv-bc@eda-stds.org
Cc: "Sergei Zaychenko"  <mailto:Sergei.Zaychenko@aldec.com>
<Sergei.Zaychenko@aldec.com>
Date: Wednesday, July 16, 2008 1:40:52 PM


Hi,
 
In Draft 6, 3.12 says,
 
"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."


So the first case should be illegal.
 
Module and package names are in different name spaces, so I think it is
legal to have a package and a module with the same name.
 
The LRM does not explicitly say whether a user-defined package can have the
name std. I would expect it to be illegal.
 
Shalom


  _____  

From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Daniel Mlynek
Sent: Wednesday, July 16, 2008 10: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

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

 
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 avaible?

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, 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  <http://www.mailscanner.info/> MailScanner, 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 Wed Jul 16 02:22:15 2008

This archive was generated by hypermail 2.1.8 : Wed Jul 16 2008 - 02:22:30 PDT