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.