Re: [sv-bc] nested modules under generate construct

danielm wrote:
> Maybe better approach is to forbid both classes and modules under 
> generate - this feature is worthless. 

That is a matter of opinion.  Classes that directly relate to
specific aspects that are being iterated upon could be useful.
In addition since that is already in the spec,  removing classes
would be removing existing functionality.  Since there is no
compelling reason to do so, I would object to such a
proposal.


 > Classes and modules may use type
> parameters to became a template.
> What are the benefits of allowing such constructs under generate?

In particular for classes, there is a higher level of type
safety since different generated classes form different types.
Particularly for parameterized classes, this allows another
level of type isolation for portions of the design.

Gord.

>  
> DANiel 
>  
> PS:
> Why dont allow only localparams in packages, generate blocks and 
> compilation scopes, and print errors for parameters?
>  
> 
> ------------------------------------------------------------------------
> *From:* owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] 
> *On Behalf Of *Bresticker, Shalom
> *Sent:* Thursday, February 21, 2008 10:50 AM
> *To:* Arturo Salz; sv-bc@server.eda.org
> *Subject:* RE: [sv-bc] nested modules under generate construct
> 
> Aha, the old "describe parameters in the local parameter subclause" trick!
>  
> (The idea of parameters that aren't, is a crime against humanity of 
> inconsistent and poor language design started by 1364-2001 and made much 
> worse in SV!)
>  
> Unfortunately, even after Mantis 1851, the LRM still does not say there 
> that parameters in generate blocks and compilation scopes are local 
> parameters. Even in 6.20.4, the wording should have been "shall be 
> synonyms". I'll file a Mantis issue on that.
>  
> Going back to my original points:
>  
> I think  26.2 should be revised to include module/program/interface 
> declarations and timeunits declarations in the list of constructs that 
> may not appear in generate blocks.
>  
> Regarding parameter declarations, that should be removed from the list, 
> since they can appear even if their meaning is like localparams. 
> Similarly, Clause 25 mentions parameter declarations in packages. 
> Remember that the forbidden construct list came from 1364, where they 
> indeed could not appear.
>  
> Shalom
> 
>     ------------------------------------------------------------------------
>     *From:* Arturo Salz [mailto:Arturo.Salz@synopsys.com]
>     *Sent:* Thursday, February 21, 2008 6:06 AM
>     *To:* Bresticker, Shalom; Brad Pierce; sv-bc@eda.org
>     *Subject:* RE: [sv-bc] nested modules under generate construct
> 
>     In the last sentence of section 6.20.4:
> 
>      
> 
>     Unlike nonlocal parameters, local parameters can be declared in a
>     *generate *block, in a package, or in a
> 
>     compilation-unit scope. In these contexts, the *parameter *keyword
>     can be used as a synonym for the
> 
>     *localparam *keyword.
> 
>      
> 
>                 Arturo
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] *On Behalf
>     Of *Bresticker, Shalom
>     *Sent:* Wednesday, February 20, 2008 7:42 PM
>     *To:* Brad Pierce; sv-bc@eda.org
>     *Subject:* RE: [sv-bc] nested modules under generate construct
> 
>      
> 
>     Where does the LRM say that?
> 
>      
> 
>     Shalom
> 
>          
> 
>         Recall that within generate the 'parameter' keyword is a synonym
>         for the 'localparam' keyword.
> 
>     ---------------------------------------------------------------------
> 
>     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. *
> 
> *---------------------------------------------------------------------
> 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 <http://www.mailscanner.info/>**MailScanner* 
> <http://www.mailscanner.info/>*, and is
> believed to be clean. *
> -- 
> 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.