Re: [sv-bc] extern modules

I'd be in favor of that; even if that doesn't achieve consensus,
I'd like to see an explicit restriction of "extern before .* in the
declaration".

Gord.

Jason Campbell wrote:
> Hi,
> 
>  
> 
> How about removing the usage of .* from the LRM? It doesn’t seem like a 
> useful capability.
> 
>  
> 
> Regards,
> 
>  
> 
> Jason
> 
>  
> 
> -----Original Message-----
> *From:* owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] *On Behalf Of 
> *Bresticker, Shalom
> *Sent:* Monday, July 14, 2008 9:50 AM
> *To:* Adam Krolnik; Gordon Vreugdenhil
> *Cc:* sv-bc
> *Subject:* RE: [sv-bc] extern modules
> 
>  
> 
> Adam,
> 
>  
> 
> No one is arguing about that.
> 
>  
> 
> The problem is that the LRM says that if you have an extern module 
> declaration, then the real module declaration can use .* instead of 
> re-listing the module ports there. My question is, what is that good for?
> 
>  
> 
> Regards,
> 
> Shalom
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* Adam Krolnik [mailto:adam.krolnik@verisilicon.com]
>     *Sent:* Monday, July 14, 2008 5:47 PM
>     *To:* Gordon Vreugdenhil
>     *Cc:* Bresticker, Shalom; sv-bc
>     *Subject:* Re: [sv-bc] extern modules
> 
> 
>     Good morning;
> 
>     I though external declarations were needed for systhesis tools to be
>     able to work with .* in instantiations. E.g. you read in the external
>     declaration of the module before it is instantiated with .*.
>     Unfortunately, this then requires people to know what files to read
>     first, or
>     a suffix to specify them first.
> 
> 
> 
> 
>     Gordon Vreugdenhil wrote:
> 
> 
>     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>
>     <mailto:gordonv_at_.....?Subject=Re:%20%5bsv-bc%5d%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.
> 
>      
> 
> 
> 
>     -- 
> 
>         Soli Deo Gloria
> 
>         Adam Krolnik
> 
>         Director of Design Verification
> 
>         VeriSilicon Inc.
> 
>         Plano TX. 75074
> 
>         Co-author "Assertion-Based Design", "Creating Assertion-Based IP"
> 
> ---------------------------------------------------------------------
> 
> 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.