Re: [sv-ec] Re: Mailbox - null return

Dave,

My comments are below.

Neil



Rich, Dave wrote On 05/10/06 12:35,:
> Arturo,
> 
>  
> 
> OK, ‘gross /user error in/ simulation’ would have been a better choice
> of words.
> 
> 
> You, Steve, and I all seem to be in agreement that a mailbox is just a
> class and there’s no reason to treat its allocation any differently. So
> any text about *new* does not belong in the section about mailboxes (and
> I now see the same text in semaphores that should also be removed). It
> belongs in section 7.7 class constructors.

[Neil]
 I agree that a mailbox should be thought of as a built-in class. I also have
no problem moving verbiage about new() returning null to 7.7.

> 
>  
> 
> If you want *new* to return null, then you must also add the ability to
> test the result of *super.new*, which you can’t do right now.

[Neil]
I don't see the need for this. As long as the handle for the object
being constructed by the user code is set to null, aren't we ok? Users
would just need to check the handle returned for the extended class. I am
assuming that the handle returned for the extended class would be set to
null if a call to super.new() returned null. Maybe you are assuming
some other behavior.

> 
>  
> 
> And what is the point of returning null? What assurances would the user
> have in continuing to execute code beyond that point?

[Neil]
One good reason for returning null is to allow the user to check for the
null value and print out a useful message to allow the problem to be
debugged. If the LRM simply says that applications need to print
an error message, there is no guarantee that such a message would be
useful for debugging the testbench.

How would one go about debugging a memory allocation problem when we only
have the following output to go on?

ERROR: out of memory


> 
>  
> 
> Dave
> 
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> *Sent:* Wednesday, May 10, 2006 11:56 AM
> *To:* Rich, Dave; sv-ec@eda.org
> *Subject:* RE: [sv-ec] Re: Mailbox - null return
> 
>  
> 
> Dave,
> 
>  
> 
> You write in this item:
> 
> It would be a gross simulation error if there are not enough resources
> to allocate an object.
> 
> I disagree. Running out of memory is not a simulation error. A trivial
> user coding error can cause the system to run out of memory, and the
> simulator cannot guarantee that it will always have enough resources to
> satisfy the request. For example, the following snippet will eventually
> cause the system to run out of memory:
> 
>  
> 
>    mailbox m[$];
> 
>    always @(clk) begin
> 
>       mailbox m1 = new();
> 
>       m.insert( 0, m1);
> 
>    end
> 
>  
> 
> As Steve Sharp pointed out, a mailbox is a class and there is no reason
> why its allocation should be handled differently from any other
> dynamically allocated object. The only alternative would be to turn
> allocation failures into a hard error for all dynamic objects, and I’m
> not sure that is warranted.
> 
>  
> 
>             Arturo
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of
> *Rich, Dave
> *Sent:* Wednesday, May 10, 2006 9:00 AM
> *To:* sv-ec@eda.org
> *Subject:* RE: [sv-ec] Re: Mailbox - null return
> 
>  
> 
> Mehdi,  Now you do need to take action.
> 
>  
> 
> Submitted as http://www.eda.org/svdb/bug_view_page.php?bug_id=0001459
> with a proposal.
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
> *On Behalf Of *Brad Pierce
> *Sent:* Tuesday, May 09, 2006 6:38 PM
> *To:* sv-ec@server.eda.org
> *Cc:* Maidment, Matthew R
> *Subject:* [sv-ec] Re: Mailbox - null return
> 
>  
> 
> In http://www.eda.org/sv-bc/hm/4469.html , Dave explains to the SV-BC
> about an apparent mailbox erratum found by Cliff.  But mailboxes are an
> SV-EC issue.
> 
>  
> 
> Could the SV-EC please look into this issue, and if, as Dave
> convincingly argues, it is truly an erratum, take ownership of it?
> 
>  
> 
> Thanks,
> 
>  
> 
> -- Brad
> 

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Senior Staff Engineer                             Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------