RE: [sv-bc] E-mal Vote: Respond by 8am PDT, Sunday Sep 30, 2007

Doug,

Removing "or class" is precisely what I suggested.

There should be a comma after "contained within the declaration".

Regarding your suggested addition, didn't you suggest "class body"
instead of "class"?  

Also, note that the preceding sentence says, "The
list_of_param_assignments can appear in a module, interface, program,
class or package or in the parameter_port_list of a module (see 22.2),
interface, program or class." This mentions packages as well. In
packages, too, 'parameter' is a synonym for 'localparam', and also in
generate blocks and in $unit.

At a minimum, "or class" should be removed, and the ambiguity about
non-implicit instantiation should be clarified.

Regards,
Shalom

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Warmke, Doug
> Sent: Sunday, September 30, 2007 11:26 PM
> To: Bresticker, Shalom; Rich, Dave; Maidment, Matthew R; 
> sv-bc@server.eda.org
> Subject: RE: [sv-bc] E-mal Vote: Respond by 8am PDT, Sunday 
> Sep 30, 2007
> 
> Shalom,
> 
> Do you think removing the "or class" would take care of your concern?
> As in
> 
> "If the declaration of a design element uses a 
> parameter_port_list (even an empty one), then in any 
> parameter_declaration directly contained within the 
> declaration the parameter keyword shall be a synonym for the 
> localparam keyword (see 6.20.4)."
> 
> We might want to add an extra sentence, something like
> 
> "NOTE - all parameter_declarations inside classes are also 
> considered localparam's.  See A.1.8 and associated footnote 39."
> 
> This is not necessary, of course, but it could be a nice 
> informative gesture for completeness in this part of the LRM.
> 
> So, will this take care of your concern and result in you 
> changing your vote to a YES? :)
> 
> Thanks,
> Doug
> 
> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Sunday, September 30, 2007 1:07 PM
> To: Rich, Dave; Warmke, Doug; Maidment, Matthew R; 
> sv-bc@server.eda.org
> Subject: RE: [sv-bc] E-mal Vote: Respond by 8am PDT, Sunday 
> Sep 30, 2007
> 
> First, see http://www.eda.org/sv-ec/hm/4362.html .
> 
> Second, the proposal changes 6.20.1 to say,
> 
> "If the declaration of a design element or class uses a 
> parameter_port_list (even an empty one), then in any 
> parameter_declaration directly contained within the 
> declaration the parameter keyword shall be a synonym for the 
> localparam keyword (see 6.20.4)".
> 
> (There should be a comma after "contained within the declaration".)
> 
> This implies that 'parameter' is a synonym for localparam 
> only "if the declaration of a design element or class uses a 
> parameter_port_list".
> Since in classes, it is *not* dependent on the presence of a 
> parameter_port_list, as opposed to design elements, the words 
> "or class"
> should be stricken.
> 
> Note that 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."
> 
> Shalom
> 
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org
> > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Rich, Dave
> > Sent: Sunday, September 30, 2007 9:49 PM
> > To: Bresticker, Shalom; Warmke, Doug; Maidment, Matthew R; 
> > sv-bc@server.eda.org
> > Subject: RE: [sv-bc] E-mal Vote: Respond by 8am PDT, Sunday Sep 30, 
> > 2007
> > 
> > Shalom,
> > 
> > Can you please explain your conflict in terms of proposed 
> wording that 
> > alleviates the conflict? I fail to see the problem as well.
> > 
> > Dave
> > 
> > 
> > > -----Original Message-----
> > > From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org]
> > On
> > > Behalf Of Bresticker, Shalom
> > > Sent: Sunday, September 30, 2007 12:40 PM
> > > To: Warmke, Doug; Maidment, Matthew R; sv-bc@server.eda.org
> > > Subject: RE: [sv-bc] E-mal Vote: Respond by 8am PDT, 
> Sunday Sep 30,
> > 2007
> > > 
> > > Doug,
> > > 
> > > > Second, I fail to see how this violates Mantis 1851.
> > > > Can you please explain why you think that, Shalom?
> > > > I studied both proposals carefully.  If you consider that
> > it's only
> > > > legal to omit default values of parameters specified in 
> parameter 
> > > > port lists, the rest of the sentences make sense and are
> > consistent
> > > > with 1851, in my opinion.
> > > 
> > > The conflict between 907 and 1851 is that 907, which is based on
> > current
> > > text, says/implies that internal parameter declarations are
> > localparams
> > > only if there is a parameter port list, as with modules. 
> 1851, which
> > is
> > > based on Mantis 1515 and other LRM text, says that internal
> > parameter
> > > declarations in a class are always localparams, even if 
> there is no 
> > > parameter port list at all, and so also says the proposal 
> for 1851.
> > > 
> > > Regards,
> > > Shalom
> > > 
> > 
> ---------------------------------------------------------------------
> > > 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, and is believed to be clean.
> > > 
> > 
> > 
> > --
> > This message has been scanned for viruses and dangerous content by 
> > MailScanner, 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 MailScanner, 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 MailScanner, and is
believed to be clean.