Re: [sv-ec] parameters in classes

I hadn't noticed Brad's comments earlier; I disagree about $unit
subroutine parameters being able to be targets of defparam.  A
defparam only admits a hierarchical identifier.  The $unit
(or other package) prefix of such identifiers are explicitly
handled in other rules.  So one cannot explicitly defparam
$unit::foo.p .  In addition, in 22.9.1 (merged draft) the LRM
says:
    Using the defparam statement, parameter values can be changed
    in any module, interface, or program instance...
$unit is none of those and its parameters (even if inside a tf) may
not be targets of a defparam.

Gord.

Bresticker, Shalom wrote:
> But 6.20.4 says, “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.”
> 
> Now I am confused.
> 
> Is there a distinction in overridability of parameters in $unit and in a 
> $unit subroutine?
> 
> Thanks,
> 
> Shalom
> 
> 
>     ------------------------------------------------------------------------
>     *From:* owner-sv-ec@server.eda.org
>     [mailto:owner-sv-ec@server.eda.org] *On Behalf Of *Brad Pierce
>     *Sent:* Monday, June 04, 2007 9:19 AM
>     *To:* sv-ec@server.eda.org
>     *Subject:* Re: [sv-ec] parameters in classes
> 
>     Probably that should have only been two contexts, not three. 
>     The BNF allows a parameter in a $unit subroutine to be the target of
>     a defparam. 
>      
>     -- Brad
> 
>     ------------------------------------------------------------------------
>     *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf
>     Of *Brad Pierce
>     *Sent:* Sunday, June 03, 2007 11:10 PM
>     *To:* sv-ec@eda.org
>     *Subject:* Re: [sv-ec] parameters in classes
> 
>     Three other contexts in which the 'parameter' keyword is a synonym
>     for 'localparam' are within a class method, within a subroutine
>     declared in a package, and within a subroutine declared in
>     $unit.  The Verilog way to override a parameter declared in a
>     subroutine is with a defparam, but defparam has not been extended in
>     SystemVerilog.  This is the topic of
>      
>        http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0001542
>      
>     -- Brad
> 
>     ------------------------------------------------------------------------
>     *From:* Brad Pierce
>     *Sent:* Sunday, June 03, 2007 11:03 AM
>     *To:* sv-ec@eda.org
>     *Subject:* Re: [sv-ec] parameters in classes
> 
>     Yes, I should have added classes to the sentence in 6.20.4 as part
>     of 1515.
>      
>     Some users strongly dislike 'localparam'.  I don't know why, but
>     they do, especially in contexts where only local parameters are
>     allowed, such as in $unit and packages.
>      
>     -- Brad
> 
>     ------------------------------------------------------------------------
>     *From:* Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
>     *Sent:* Sunday, June 03, 2007 10:50 AM
>     *To:* Brad Pierce; sv-ec@eda.org
>     *Subject:* RE: [sv-ec] parameters in classes
> 
>     I myself pointed to that Mantis. So should classes be added to
>     6.20.4 as well as deleted from 6.20.1?
> 
>     I will also take the opportunity to repeat my displeasure at using
>     the parameter keyword to mean local parameter when there was no need
>     for it because the localparam keyword already exists. It just makes
>     for confusion. It is a sign of bad language design.
> 
>     It is what Stu calls a gotcha. It looks like a parameter, but isn’t.
> 
>     Shalom
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* owner-sv-ec@server.eda.org
>     [mailto:owner-sv-ec@server.eda.org] *On Behalf Of *Brad Pierce
>     *Sent:* Sunday, June 03, 2007 7:29 PM
>     *To:* sv-ec@server.eda.org
>     *Subject:* Re: [sv-ec] parameters in classes
> 
>      
> 
>     >So is every parameter declared in a class a local parameter,
> 
>     >or only if there are parameters defined in the class header?
> 
>      
> 
>     Everyparameter declared as a class_item is always already local,
>     regardless of whether thereis a #(...) after the class_identifier.  See
> 
>      
> 
>        http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0001515
> 
>      
> 
>     Sothe word 'class' should be removed from that 6.20.1 sentence. 
>     (However, 'interface' and 'program' should be retained.)
> 
>      
> 
>     -- Brad
> 
>      
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf
>     Of *Bresticker, Shalom
>     *Sent:* Saturday, June 02, 2007 11:34 PM
>     *To:* sv-ec@eda.org
>     *Subject:* [sv-ec] parameters in classes
> 
>     Hi,
> 
>     In Draft 3, Stu wrote in 6.20.1, “If any /param_assignments /appear
>     in a /parameter_port_list/, then any /param_assignments /that appear
>     within the module, interface, program or class shall become local
>     parameters and shall not be overridden by any method.” Here Stu
>     added “interface, program, or class”.
> 
>     6.20.4 says, “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.”
> 
>     BNF footnote 39 (Mantis 1515) says, “39) In a parameter_declaration
>     that is a class_item, the *parameter *keyword shall be a synonym for
>     the *localparam *keyword.”
> 
>     So is every parameter declared in a class a local parameter, or only
>     if there are parameters defined in the class header?
> 
>     What about interfaces and programs?
> 
>     Thanks,
> 
>     Shalom
> 
>     Shalom Bresticker
> 
>     Intel Jerusalem LAD DA
> 
>     +972 2 589-6852
> 
>     +972 54 721-1033 
> 
>      
> 
> 
>     -- 
>     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 <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 <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. *
> 
> *
> -- 
> 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.