[sv-bc] RE: Mandated warnings -- was Re: [sv-ec] Mantis 2701, ballot ID #44 - Arturo's feedback

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Fri May 08 2009 - 06:58:24 PDT
 

> >The no-op semantics of Verilog out-of-bounds writes (for 
> known indices) does 
> seem weird. By analogy with the x-pessimism of much of the 
> language, I would 
> have expected maybe the entire array to be x'ed out.
> 
> 
> For known indices, this seems completely natural to me.  An array was
> originally intended to represent a memory.  If the address is fully
> decoded, an out-of-range address won't select this memory, so a write
> will have no effect.  If the address is not fully decoded (i.e. the
> upper bits that make it out-of-range are ignored), then it should have
> been represented by only applying the decoded bits to the 
> memory.  Then
> it would have the same "wrap-around" effect as the real hardware.  So
> I don't think this is at all weird.

On the contrary, in your design code, this will not occur. 

In your first case, there will be no write to the array, and in the second case, only the decoded bits will be applied, and then it will be inside the range, not outside.


> For unknown indexes, I agree that a no-op write is serious x-optimism.
> To avoid this optimism, it really should X the whole memory, or the
> addresses for every possible address considering X to be 0 or 1.  This
> presumably was not done because it would be so expensive.

The warning would come in place of X-ing the memory. The important thing is to get an indication that it occurred.

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.
Received on Fri May 8 07:01:24 2009

This archive was generated by hypermail 2.1.8 : Fri May 08 2009 - 07:01:37 PDT