| Number | 217
|
| Category | errata
|
| Synopsis | Note that task/func params can only be overridden by defparams
|
| State | lrmdraft
|
| Class | errata-discuss
|
| Arrival-Date | Dec 11 2002
|
| Originator | Shalom.Bresticker@motorola.com
|
| Release | 2001b
|
| Environment |
|
| Description |
Named blocks, tasks, and functions can define parameters, but the parameters can not be redefined in instantiations because they are not instantiated. They can be redefined only by defparams. The LRM should note this. |
| Fix |
Add the following paragraph to the end of 12.2.2: "A parameter declared in a named block, task or function can only be directly redefined using a defparam statement. However, if the parameter value is dependent on a second parameter, then redefining the second parameter will update the value of the first parameter as well (see 12.2.3)." |
| Audit-Trail |
From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/217: PROPOSAL - Note that task/func params can only be overridden by defparams Date: Tue, 17 Jun 2003 14:19:16 +0300 > Add the following text to section 12.2.1: > Parameters defined in named blocks and inside tasks and functions can only be redefined using defparams. > http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&pr=217 I think it is better to add this text to 12.2 or 12..2.2. Shalom From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/217: PROPOSAL - Note that task/func params can only be overridden by defparams Date: Thu, 4 Sep 2003 16:47:09 +0300 (IDT) ---------- Forwarded message ---------- Date: Sat, 23 Aug 2003 08:08:37 -0700 From: Karen Pieper <Karen.Pieper@synopsys.com> To: sv-bc@eda.org Subject: [sv-bc] defparam I'm forwarding bounced mail from Guillermo Maturana <maturana@sbcglobal.net>] K >In the 3.1 LRM under 25.2, first paragraph it says "The defparam >statement does >not provide a capability that can not be done by another method, ...". > >I think this is incorrect: I don't think it is possible to override >parameters >declared in subscopes of a module this way, as in the following somewhat >contribed example: > >module a; >parameter p; >task t; >parameter p; >begin :n >parameter p; >end >endtask >endmodule > >I don't think instance overrides can cause t.p or t.n.p to be overriden. > >Of course a module could have parameters in arbitrarily nested named blocks. >The named parameter overrides can only refer to the module level parameters, >but they are incapable of overriding parameters in nested scopes. > >One solution to this would be to extend the name to be full hierarchical >name >of parameters in any subscope, with a single '.' representing the module >level, >and successive tokens refering to the path to any subscope. > >So for the example above, an instance a1 of a one could override "p" at >top level, "p" under task t, and "p" under task t's named block n as >follows: > >a #(.p(1), .t.p(2), .t.n.p(3)) a1; > >Oh well, I don't like defparams either, but without some way to override >nested parameters the argument in 25.2 is not solid. > > _Matute From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: <etf-bugs@boyd.com> Cc: Subject: Re: errata/217: PROPOSAL - Note that task/func params can only be overridden by defparams Date: Tue, 9 Sep 2003 18:37:54 -0700 Does the 2nd paragraph of 3.11.1 disallow the overriding of parameters defined in named blocks and inside tasks and functions when 2001-style parameter declarations, e.g., #(parameter P=2), are used? It seems like, within the body of a module, there is no difference between 'parameter' and 'localparam' in such cases because -- "If any param_assignments appear in a module_parameter_port_list, then any param_assignments that appear in the module become local parameters and shall not be overridden by any method." -- Brad From: Shalom.Bresticker@motorola.com To: Brad Pierce <Brad.Pierce@synopsys.com> Cc: etf-bugs@boyd.com Subject: Re: errata/217: PROPOSAL - Note that task/func params can only be overridden by defparams Date: Wed, 10 Sep 2003 10:08:08 +0300 (IDT) > Does the 2nd paragraph of 3.11.1 disallow the overriding of parameters > defined in named blocks and inside tasks and functions when 2001-style > parameter declarations, e.g., #(parameter P=2), are used? > > It seems like, within the body of a module, there is no difference > between 'parameter' and 'localparam' in such cases because -- > > "If any param_assignments appear in a module_parameter_port_list, then > any param_assignments that appear in the module become local parameters > and shall not be overridden by any method." Do you mean the following? module m #(parameter P=2) (); task t ; parameter t_p = 3 ; endtask function f ; parameter f_p = 3 ; endfunction initial begin :n parameter n_p = 1 ; end endmodule -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: <etf-bugs@boyd.com> Cc: Subject: Re: errata/217: PROPOSAL - Note that task/func params can only be overridden by defparams Date: Wed, 10 Sep 2003 09:21:35 -0700 Exactly. module m #(parameter P=2) (); parameter Q = 3 ; // definitely a localparam task t ; parameter t_p = 3 ; // localparam or parameter? endtask ... endmodule A possibility is that 3.11.1 was only intended to treat top-level 'parameter' declarations as 'localparam' declarations, and was not intended to apply to lower-level 'parameter' declarations. It would have been nicer if it were simply illegal to use the 'parameter' keyword in contexts where it is currently an alias for 'localparam'. This would have been analogous to the approach taken with ANSI-style port declarations in 12.3.4 -- "Each module shall either be declared entirely with the list of ports syntax as described in 12.3.2 or entirely using the list_of_port_declarations as described in this section." -- Brad From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Brad Pierce <Brad.Pierce@synopsys.com> Cc: etf-bugs@boyd.com Subject: Re: errata/217: PROPOSAL - Note that task/func params can only be overridden by defparams Date: Thu, 11 Sep 2003 16:52:57 +0300 It seems to me that the difference between the placement of the parameter declarations has only minor effects. For example, if you declare a parameter in the module header, then you can use it in an ANSI port declaration. I don't see a strong justification for making the parameters declared inside into local params. So I would be inclined not to force that restriction on parameters in the inner scope as well. Can anyone explain the reason? Shalom > A possibility is that 3.11.1 was only intended to > treat top-level 'parameter' declarations as 'localparam' > declarations, and was not intended to apply to lower-level > 'parameter' declarations. -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/217: PROPOSAL - Note that task/func params can only be overridden by defparams Date: Fri, 19 Sep 2003 11:43:29 +0300 (IDT) Although we have passed this proposal, maybe we should reword it to exclude automatic tasks and functions. Shalom > Add the following text to section 12.2.2: > > Parameters declared in named blocks and inside tasks and functions can only be > redefined using defparams. > > http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&pr=217 -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 Fix replaced by Shalom.Bresticker@motorola.com on Wed Nov 26 05:24:21 2003 Add the following paragraph to the end of 12.2.2: "A parameter declared in a named block, task or function can only be directly redefined using a defparam statement. However, if the parameter value is dependent on a second parameter, then redefining the second parameter will update the value of the first parameter as well (see 12.2.3)." |
| Unformatted |
|
Hosted by Boyd Technology