Subject: Re: [sv-bc] Proposal for extern modules
From: Kevin Cameron (sv-xx@grfx.com)
Date: Tue Feb 18 2003 - 01:00:43 PST
>
> I don't understand the need for this. I can see that it makes .* easier
> to implement, because the tool can expand the .* during parsing, and then
> doesn't have to worry about it any more. But the purpose of this is to
> be easier for the user, even if it requires extra effort from the tool.
>
> Separate compilation can just record that there was a .* on the port.
> Then during elaboration, when the instance is bound to a particular
> module definition, the ports will be known and the appropriate connections
> can be made. It isn't like you really know what is going on in a design
> until it is elaborated anyway. Are there tools that can do something
> useful with the partial information that is available before elaboration?
>
> Note that even if the modules are compiled together, you can't necessarily
> figure out the port connections for .* until elaboration. Verilog-2001
> configs allow an instance to be bound to different module declarations
> based on where the instance is in the hierarchy. I don't think there is
> any requirement that all the possible bindings for an instance have
> identical ports and port names.
I asked for extern declaration back when .* was introduced. The reason
you need it is not specifically for seperate compilation (as in doing
a whole design incrementally) but for recognizing that you have a complete
subset of a design. If some module included in the design are "black box"
and only the simulator knows their interface you need some mechanism to
inform other tools about how those modules are connected. For AMS this is
needed because most analog simulators have a bunch of different device
models, and without extern module declarations you can't tell if you
have a complete netlist when it used with other tools (you just have
dangling references).
> Different software architectures may give some tools a harder time in
> handling .* than others, and require a lot more work from the implementors.
> But I don't see anything inherently impossible about handling .* with
> separate compilation. It is just a matter of delaying yet another thing
> until elaboration.
>
> Steven Sharp
> sharp@cadence.com
>
It's inherently impossible to analyze the downward connections of a module
if it uses .* unless you also know the connected modules' ports - it's not
"seperate compilation" if you just wait until you have both.
Kev.
This archive was generated by hypermail 2b28 : Tue Feb 18 2003 - 01:01:24 PST