Date: Sun Jun 03 2007 - 23:18:50 PDT
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, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by <http://www.mailscanner.info/> MailScanner, 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, and is believed to be clean.
