Re: [sv-bc] extern modules

Shalom, the restriction only applies when you are
using .* in the *declaration* of the module in which
case .* means "pick up the formals that were defined by the
extern".  The .* use isn't related to an instantiation
of the module (for which the existence of an extern is
immaterial anyway).

Extern modules are a bit of an odd feature in SV -- you
don't need them to instantiate a separately compiled
module, nor to use .* in an instantiation.  The only
advantage is for systems that might not want to inhale
the whole world (synthesis perhaps) or for earlier checking
of port width/type constraints.  Neither of those aspects
are directly related to LRM requirements.

Gord

Bresticker, Shalom wrote:
> Then how do you do separate compilation?
> And if they're compiled together, what do you need it for?
> 
> Shalom
> 
>       _____________________________________________
>       *From:  * Bresticker, Shalom 
>       *Sent:  * Monday, July 14, 2008 12:18 PM
>       *To:    * Bresticker, Shalom
>       *Subject:       * Re: [sv-bc] extern modules
> 
>       /From: Gordon Vreugdenhil <//_gordonv_at_....._/
>       <mailto:gordonv_at_.....?Subject=Re:%20[sv-bc]%20extern%20modules>/>
>       Date: Thu Jul 10 2008 - 12:37:24 PDT/
>       Jason,
> 
>       I agree that with .*, the extern really needs to come first.
>       Since externs are a way of declaring the "type" of the module
>       and .* is similar to a dependence on that type, I don't really
>       see that restriction as being much of a reach either in
>       practice or as a matter of LRM interpretation.
> 
>       Gord.
> 
> 
>       Jason Campbell wrote:
>        > Hi,
>        >
>        > 
>        >
>        > The LRM doesn’t specify if extern can be used subsequent to the
>       module
>        > defintion. Is it
>        >
>        > correct to assume that this is permitted? Maybe this can be
>       clarified in
>        > the LRM.
>        >
>        > 
>        >
>        > If so, this makes implementation of .* in the module port list
>       quite
>        > difficult. The reason is
>        >
>        > that nets and variables can not be checked for correct usage
>       until the
>        > extern is compiled.
> 
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.