Subject: Re: [sv-bc] Proposal for extern modules
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Feb 18 2003 - 13:15:09 PST
> From: "Steven Sharp" <sharp@cadence.com>
>
> Karen,
>
> Like Adam, I don't understand why you can't use the actual module declarations.
> They are apparently available, since you mentioned using scripts to create
> external declarations from them. And you proposed a .* syntax for the module
> declaration to make it use the port list from the external declaration, again
> implying that both were available.
>
> If there is some situation where the real module declaration isn't available,
> you could always use a dummy module (AKA shell or stub). They look pretty
> much like your extern declarations; just take the word "extern" off the front
> and add the word "endmodule" to the end. And if the synthesis compiler needs
> to know that these are dummy declarations, you can put the "extern" back on
> as an attribute. Also, configs could be used to compile all of the stub
> modules into a separate library if desired.
>
> Steven Sharp
> sharp@cadence.com
Using a stub is accident prone, there's no way to tell if it's supposed to
be a stub or is just an empty module so it can slip through the design
process as an unrecognized error.
If "extern" was an officially recognized attribute it might as well be part
of the language proper.
However I would prefer to use "extern" in front of a regular module definition
so that also declare objects reachable by hierarichal reference e.g.:
extern module resistor(inout a,inout b)
real temp; // internal node for device temperature (probable)
endmodule
My only restriction on an extern module might be that you couldn't declare any
behavioral code, only structure.
Kev.
This archive was generated by hypermail 2b28 : Tue Feb 18 2003 - 13:16:34 PST