Brad,
There is another possibility. Since a module's formal argument are
really part of that module's scope. Would it be too crazy to simply
make the import statements within the scope of the module visible
to its ports? For example, using Stu's example:
module ( input [WIDTH-1:0] data,
input instruction_t a,
output [WIDTH-1:0] result
);
import shared_decls::* // this defines WIDTH and instruction_t above
...
endmodule
The reason I thought of this is because an import within the module
that conflicts with the proposed parameter import construct will have
to result in an error (for example importing WIDTH from a different
package inside the module). Then, why not use this to the user's
advantage and allow imports inside the module's scope to affect its
port declarations. While this is a departure from declaration-before-use
guidelines, the language of the LRM currently supports the notion that
an import statement affects declarations in the scope that contains the
import, regardless of the relative order of the declarations and imports
statements (I believe the end of Section 18.2 supports this notion).
I understand that this may complicate the parser, but it does require no
additional syntax. Just a thought.
Arturo
----- Original Message -----
From: "Brad Pierce" <Brad.Pierce@synopsys.COM>
To: <sv-bc@eda.org>
Sent: Wednesday, December 01, 2004 1:26 PM
Subject: Re: [sv-bc] Proposal to make it easier to use packages with port declarations
Stu,
Requiring the ::* here is kind of annoying, because that's the
typical case. Also, although the imports are somewhat like
parameters, they are not really parameters. They deserve
their own list, just like parameters and ports. A natural way
to do this would be to use the 'import' keyword. So, how about
module m import(pkg1,pkg2) #(...) (...) ; ... endmodule
in which pkg1 would be shorthand for pkg1::*?
-- Brad
Received on Wed Dec 1 14:38:50 2004
This archive was generated by hypermail 2.1.8 : Wed Dec 01 2004 - 14:38:57 PST