RE: [sv-ec] Queue Methods - return status?

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Thu Jun 18 2009 - 07:51:53 PDT
Hi,

I agree that these should be treated as invalid reads and writes, but I disagree where Arturo says, "an assertion may be issued".

For invalid writes, the LRM says, "An invalid index (i.e., a 4-state expression with X's or Z's, or a value that lies outside 0...$+1) shall cause a write operation to be ignored and a run-time warning to be issued," i.e., a warning is mandatory.

For invalid reads, the LRM says, "An invalid index value (i.e., a 4-state expression with X's or Z's, or a value that lies outside 0...$) shall cause a read operation (e = Q[n]) to return the default initial value for the type of queue item," with no mention of a warning. Of course, nothing prevents a tool from issuing such a warning, but it is not in the LRM.

Regards,
Shalom

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Arturo Salz
> Sent: Wednesday, June 17, 2009 11:43 AM
> To: Clifford E. Cummings; sv-ec@eda.org
> Subject: RE: [sv-ec] Queue Methods - return status?
> 
> Hi Cliff,
> 
> Interesting question. Here are my two cents:
> 
> Calling insert() with an invalid index - either larger than 
> $+1, negative, or containing X or Z - behaves the same as any 
> other array write with an invalid, that is, no write is 
> performed and an assertion may be issued.
> 
> Calling delete() with an invalid index deletes no element and 
> an assertion may be issued. This behavior is consistent with 
> the above.
> 
> Calling pop_front() or pop_back() on an empty queue returns 
> the default uninitialized value for the queue element type, 
> and an assertion may be issued. This is consistent with an 
> array read with an invalid index.
> 
> These seem rather natural extensions from other array 
> operations. Nonetheless, it would be good to document them.
> 
>         Arturo
> 
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On 
> Behalf Of Clifford E. Cummings
> Sent: Tuesday, June 16, 2009 8:35 PM
> To: sv-ec@eda.org
> Subject: [sv-ec] Queue Methods - return status?
> 
> Hi, All -
> 
> This question has been posed to me a number of times and I am not
> 100% sure what the answer should be.
> 
> Do the queue methods return any type of status if they fail? Looking
> over the LRM (clause 7.11.2 in Ballot Draft), the methods are
> described, but unlike mailbox methods, there does not appear to be
> any return status, nor is there any description of what should happen
> if the called methods fail.
> 
> Examples:
> insert() method at an index. What happens if you try to insert into a
> queue at location 5 if there are only two entries in the queue? And
> where is the behavior described. This is a void function.
> 
> delete() method at an index. Same type of issue. Deleting an entry
> that does not exist.
> 
> pop_front() or pop_back() from an empty queue. What happens? 
> Any status?
> 
> The push_front(), push_back() and size() methods should all be okay.
> 
> Thanks for any thoughts.
> 
> Regards - Cliff
> 
> 
> ----------------------------------------------------
> Cliff Cummings - Sunburst Design, Inc.
> 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
> Phone: 503-641-8446 / FAX: 503-641-8486
> cliffc@sunburst-design.com / www.sunburst-design.com
> Expert Verilog, SystemVerilog, Synthesis and Verification Training
> 
> 
> --
> 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.
Received on Thu Jun 18 07:53:07 2009

This archive was generated by hypermail 2.1.8 : Thu Jun 18 2009 - 07:53:16 PDT