Re: [sv-bc] Query related with package import in extern module declaration.

From: Greg Jaxon <Greg.Jaxon@synopsys.com>
Date: Mon Dec 13 2010 - 08:18:28 PST
IMO, systems that behave as you've described (way below) are providing a consistent interpretation of the current LRM.
I think they've been "generous" in case (2), since the LRM only obliges them to carry forward the ports and
parameters:
"If an extern declaration exists for a module, it is possible to use .* as the ports of the module. This usage
shall be equivalent to placing the ports (and possibly parameters) of the extern declaration on the module."
In the case of (2), the name c1 has been explicitly imported into the extern module scope, so there is a definite entity
to be carried over into the full definition.  Whereas in (1), the wildcard import option expired without being exercised,
and left nothing in the module scope to be carried-forward.  There is certainly no obligation to re-instate the potential for
further wildcard importations.   Although, given the very suggestive copy and paste pattern:
     extern module m (a,b,c,d);
     extern module a #(parameter size = 8, parameter type TP = logic [7:0])
                         (input [size:0] a, output TP b);
     module m (.*);
         input a,b,c;
         output d;
     endmodule
     module
a (.*);
         ...
     endmodule


is equivalent to writing

     module m (a,b,c,d);
         input a,b,c;
         output d;
     endmodule
     module
a #(parameter size = 8, parameter type TP = logic [7:0])
                  (input [size:0] a, output TP b);
         ...
     endmodule


... it's easy to see where the expectation arises that a wildcard import in the header would be copied and re-activated.
If that's a desirable mode of use, it would make an understandable extension to the current specification.

Greg Jaxon
Disclaimer: I am not a voting member of SV-BC at present,
my opinions are not product commitments or voting positions of my employer.

On 12/13/2010 6:51 AM, Kakoli Bhattacharya wrote:
Hello,

Consider the following egs:

1) package pack1;
    const int c1 = 3;
   endpackage

   extern module static prog1 import pack1::*;(output shortint out1); // Wild card import

   module static prog1 (.*);

    assign out1 = 8'b10011001 >>> c1; // c1 is not visible
   endmodule

2) package pack1;
    const int c1 = 3;
   endpackage

   extern module static prog1 import pack1::c1;(output shortint out1); // Explicit import

   module static prog1 (.*);

    assign out1 = 8'b10011001 >>> c1; // c1 is visible
   endmodule

 Many tools are passing the 2nd case while giving error for the 1st one.
 Which one is correct? Or are they both wrong ??

 Earlier there were some mails related to a similar issue but I am not able to clearly relate them to
 this issue of mine. 
 Maybe I am missing some points from those mails ...

Regards,
Kakoli

Dhiraj Kumar Prasad wrote:
Hello,

I have a query regarding package import in extern module  declaration.

Consider the following testcase
----------------------------------------

package pack1;
   parameter p1 = 10;
   parameter p2 = 20;
endpackage

extern module mod1 import pack1::p1;(out1, out2);

module mod1 import pack1::p2;(out1, out2);
output int out1;
output int out2;

initial
begin
   out1 = p1;
   out2 = p2;
end
endmodule

Both package items p1 and p2 should be visible ??  AS LRM say only about parameter and port list and said nothing
about the package import.

Regards,
dhiRAj






--
This message has been scanned for viruses and
dangerous content by MailScanner, 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 Mon Dec 13 08:19:26 2010

This archive was generated by hypermail 2.1.8 : Mon Dec 13 2010 - 08:20:21 PST