I don't see any reason that these need to match.
Noticing that they don't match might make a nice optional warning, but
that's as far as I'd push this idea.
Nor do I see why "both package items should be visible".
There is certainly an error on the line out1 = p1;
We don't require the external declaration to be read-in before
the module definition.
Making the module's semantics depend on whether or not its
extern
has been read is
Dysfunctional.
In practice, there is no way to add
pk::p1 to
mod1's
scope without seeing the
extern.
Using (
::*) wildcard imports to shadow
$unit
names, I can make
1s and
0s depend on
whether or not
the extern's import statement applies in the module definition.
The extern declaration and the definition of
mod1 are
two
distinct scopes.
They are required to agree on the number, position, name and types of
the ports and parameters (the API),
but not on how any localparams arrive or whether or not they are
relevant to port/parameter definitions.
These package imports only supply localparams within these scopes.
I hope this user does not think that
mod1 becomes
parameterized by this syntax!
BTW, the text here says "equivalent types", where clearly "
matching
types" is intended, right?
I don't believe differences in array bound values or direction are
tolerable in this application of the type system.
Since these
types can be used to produce
data values
resulting from type comparisons,
assignment patterns, and perhaps other exotic things I prefer that the
caller and the author of
the module be in full agreement rather than just "structural
conformity".
I also note that there is no statement here requiring
default input
port values or
default parameter values to agree.
That seems like an oversight, and if it is not, then some extra text is
needed to indicate which of the unequal
default values will be used, and which will be ignored. Agreement
about which ports can be omitted and which
parameters cannot seems an essential job of an extern (API)
declaration. Agreement on the values to
use when these optional things are omitted seems like a Good Coding
Practice to avoid bad logic
Any constants used to build up port or parameter data types need to
match in value, but they need not
come from the same RTL source code or syntax. Granted:
not
having a common ancestry for these
is Poor Software Engineering Practice. It is always nice when
implementations can warn us about this,
but it isn't a requirement like it is for strongly-typed
structs,
for example.
Greg Jaxon
Rich, Dave wrote:
I believe this was an oversight when package import was added to the
module header. They should match.
-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Dhiraj Kumar Prasad
Sent: Friday, June 25, 2010 4:32 AM
To: sv-bc@server.eda.org
Cc: Surya Pratik Saha; Dhiraj Kumar Prasad
Subject: [sv-bc] Query related with package import in extern module
declaration.
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 Fri Jun 25 13:32:57 2010