RE: [sv-ec] RE: [sv-champions] 5-day email vote 1723

I already opened Mantis 2007 on this.

Shalom 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Rich, Dave
> Sent: Friday, August 31, 2007 11:27 PM
> To: Brad Pierce
> Cc: sv-ec@server.eda.org
> Subject: [sv-ec] RE: [sv-champions] 5-day email vote 1723
> 
> This discussion is from the champion's rejection of mantis 1723
> 
> I do believe the text in 7.9.4 should be modified. Index 
> expressions should simply be cast to the declared index type 
> of the array. We don't need separate local definitions of 
> casting to int.
> 
> I still think the example is correct. If you sign extend an 
> unsigned literal, it gets zero filled. 7.9.4 does not 
> consider what it means to sign extend an unsigned type.
> 
> Since this mantis in now re-opened, I will try to address 
> this without opening up a new mantis item
> 
> 
> Dave
> 
> 
> P.S. The reason I changed the index type from [*] to [int] 
> was because I was hoping to discourage the use of wildcard 
> index types as I think they are no longer useful with the 
> text that was added by mantis 1457.
> 
> 
> 
> > -----Original Message-----
> > From: owner-sv-champions@server.eda.org [mailto:owner-sv- 
> > champions@server.eda.org] On Behalf Of Brad Pierce
> > Sent: Tuesday, August 28, 2007 8:49 AM
> > To: sv-champions@server.eda.org
> > Subject: RE: [sv-champions] 5-day email vote 1723
> > 
> > Dave,
> > 
> > Why do we need to open/resolve another Mantis item, just to add a
> single
> > line to the example?  That's a lot of overhead for a simple 
> editorial 
> > change.  Why not just upload an updated version of the 
> proposal with 
> > that editorial change?
> > 
> > Thanks for pointing me to the 7.9.4 text about indices.  
> According to 
> > that text, all of these unsigned integral values are sign 
> extended to
> 32
> > bits, becoming negative ints.  Was that the intent of your change?
> > 
> > That 7.9.4 text also does not say how an indexing expression such
> (1'b1
> > + 1'b1) should be handled.
> > 
> > To me it looks like the text in 7.9.4 is wrong, and the indexing 
> > expression should be implicitly static cast to integer or int, that
> is,
> > the indexing expression should be evaluated in the context of an 
> > assignment to integer or int.
> > 
> > -- Brad
> > 
> > -----Original Message-----
> > From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> > Sent: Tuesday, August 28, 2007 4:01 AM
> > To: Rich, Dave; Brad Pierce; sv-champions@eda.org
> > Subject: RE: [sv-champions] 5-day email vote 1723
> > 
> > I agree with Dave on this one.
> > 
> > Shalom
> > 
> > > -----Original Message-----
> > > From: owner-sv-champions@server.eda.org 
> > > [mailto:owner-sv-champions@server.eda.org] On Behalf Of Rich, Dave
> > > Sent: Tuesday, August 28, 2007 9:40 AM
> > > To: Brad Pierce; sv-champions@server.eda.org
> > > Subject: RE: [sv-champions] 5-day email vote 1723
> > >
> > > >
> > > >     http://www.eda-stds.org/svdb/view.php?id=1723
> > > >
> > > >         6) Needs an example of the new method.
> > > [DR] This would be another mantis item.
> > > >
> > > >         7) Not clear that that the indexing expressions 
> are still
> > > legal
> > > > after the change from [*] to [int].
> > > >
> > > [DR]From the LRM 7.9.4 Integer (or int) index
> > > - Indices can be any integral expression.
> > > - Indices are signed.
> > > - A 4-state index containing X or Z is invalid.
> > > - Indices smaller than integer are sign extended to 32 bits.
> > > - Indices larger than integer are truncated to 32 bits.
> > > - The ordering is signed numerical.
> > >
> > >
> > > What's not legal?
> > >
> > > Dave
> > >
> > >
> > > --
> > > 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.
> > 
> 
> 
> -- 
> 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.