[sv-cc] Re: FW: Feedback on 2226

From: John Shields <John_Shields_at_.....>
Date: Fri Mar 21 2008 - 09:19:16 PDT

Hi,

Thanks for your quick review, Francoise.  I will look at the details and respond separately, but let me address one of big items for you to think about.

There is a problem to expose the value of a classVar, because the language does not, and their very different representational approaches dependent on how you do garbage collection. It is a clear abstraction to have an ID for an object that is an unique as the object memory address, but we don't want to make a guarantee that given an ID we will produce a reference to the object.  It is easy to suggest that you could, but hard to justify that you should.  There is no reason to add a risky constraint.

There is a deeper problem in representing the value in a datastructure like the vpi value struct that can be disjoint from the object.  We have no mechanism for vpi to have a first class reference to a class object.   It is not that we are waiting to provide get/put value as a pair of functions.  We may never do this because of the disjoint nature of modeling assignment as 2 separate operations vs. an atomic operation (which we don't have a api for).  To further separate the value into a datastructure that has no connection to referencing of class objects is to invite an inability to check the validity of the value and what it is being assigned to.

So, the objId is not the value and the value is not exposable separately from the class var that holds it.

As to the endOfObject, there is a lot written on this in the email thread in the past 2 weeks.  I am pretty weary of it, frankly.  I don't want to reiterate the arguments and stand on both sides in the process, nor do I want to state my personal opinions or let my biases appear in any writeup. They are all there in the email record.  We have concluded that it has good enough usability in some cases to be part of the spec.  But your question will have to be answered to your satisfaction and it may come in the future as the spec goes through a wider review.  I suggest you talk to Charlie, Jim, and Chuck about the discussions and they can point you the right emails.  After that, if it is still an issue or your opinion changes, raise it again.

In the meantime, I will try and complete the revision with all the feedback from the last 2 days. When time permits, I will write a rationale for endOfObject for future use.  I do plan on submitting a paper on the vpi dynamic object model for dvcon 09.

Regards, John

Francoise Martinolle wrote:

John,

 

I am mostly in agreement with what is proposed here, except for the definition of vpiAllocScheme, details are

within my comments.

Also I would like to be able to get a value for a classVar. I guess we do not allow this now because

we want to provide it along with vpi_put_value and that is not currently defined. I would like the 64 bit identifier to be returned

as a value.

Another minor comment is that I would like to be able to query a lot more from within a cbEndOfFrame, cbEndOfThread

callback.

I do not see the need for cbEndOfObject callback (can someone illustrate how this is going to be used

which cannot be accomplished with a cbEndOfFrame, EndOfThread or CbReclaimObject?

 

 

Here the details of  my feedback on the clause 36  
Typo   Page 2:   2) Whenever the simulator frees objects belonging to a frame or thread, it shall release all handles to

those objects, and to any subelement of this objects. Handles to callbacks placed on these objects

will also be released. 

 

What does the following note means? NOTE 3 - Currently there are no callbacks that may be placed on objects belonging to frame or thread. We cannot register callbacks for  static declared variable  in a frame or thread ? 

I understand you would not be able to do that for automatic variable declared in a frame or thread. 

Typo:   36.2.3 Handle comparision 

 

I  am not sure if cbEndOfObject  is necessary , it seems that with cbReclaim, cbEndOfFram, cbEndOFThread, we have everything we need. 

 

Page 7:

I do not think that the vpiAllocScheme property is correctly defined on an instance definition or I do not   understand what this property represents.  An instance is always

statically allocated, if you refer to the allocation of the instance, it will always be static.

On the other hand, the presence of the static or automatic keyword on a module/package/interface describes the default lifetime of variables declared within the task/functions/blocks present in the module/program/package. I think that if this property is intended to represent that default lifetime, it should rather be called vpiLifetime  or we can just use the property vpiAutomatic (FALSE would mean static) 

The current definition on the instance diagram says:

9) The property vpiAllocScheme indicates how an instance is allocated in memory and reflects the default nature ofany of its objects’ lifetimes. It is an enumeration of 3 possible values: vpiStaticScheme, vpiAutomaticScheme, and   vpiDynamicScheme. 

What is the vpiAllocScheme for a class var "v" declared as:

module automatic top;

   class C;

   endclass

initial begin

    C v = new; // is it automaticScheme or DynamicScheme?

end

function foo();

  static C fv = new; // is it staticSheme or DynamicScheme?

endfunction

endmodule

    

I argue that we only need 2 properties: vpiLifetime (static or automatic, or we can use the existing property vpiAutomatic ) and vpiDynamicAlloc .  The property vpiDynamicAlloc  indicates that the object pointed to by the handle  is dynamically allocated.  Tthe property vpiLifetime  can be applied to variables or to module/package/interface/function/tasks/procedural blocks and returns vpiAutomatic  if the object lifetime is automatic vpiStatic if the object lifetime is static. For a module, package, inerface, task, function this property would return the default lifetime.   An object has  an   automatic lifetime if  the variable is declared in an function /task/procedural block whose lifetime is automatic ,  or  is explicitly declared as automatic.

I do not see the reason for a vpiAllocScheme property.

Note that a static method is different from a method with static lifetime. The former refers to the lifetime of themethod within the class, while the latter refers to the lifetime of the arguments and variables within the task. 

A class def i nition can also have a static/automatic lifetime according to the BNF  and we should have a vpiLifetime property on a class defn. 

On Page 22, the detail describing the property vpiAutomatic is incorrect:

1) The declared lifetime property reflects source code view of the class defn and whether data members of the class

default to static or automatic. 

 The lifetime automatic/static describes the  lifetime of variables declared in task/function, it has nothing to do with the class

data members. 

On Page 25 typo: The property vpiObjId is a class object’s identifier. It is a property of a live object and guaranteed ti be unique with

respect to all other dynamic objects that support this property for as long as the object is alive. After the object is

destroyed by garbage collection, its particular vpiObjId value may be reused.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Feedback on clause 37

Do we say how much information is available at a cbEndOfFrame (resp. cbEndOfThread, cbEndOfObject)?

Typically in a debugger, if you put a break on the function return statement, you can look at every value of variables

declared in that function and go up the stack frames. Why would not this be available here?

Can we get the  value of an object for which we obtained a cbENdOfObject?

What about cbEndOfObject, this seems like a very general callback, how much can you query and traverse.Is this callback really necessary? Can someone provide an example showing how can someone uses cbEndOfObject?

In the description of cb_data_p->obj on page 5 it says:

This field shall be assigned a handle to an appropriate object, including classspec,

class property, frame, thread, variable,

however a "class property "does not appear as a class in the information model , I think it is modelled as a variable?

Page 6 says:

The cbValueChange callback may be placed on a class var and will be called when its value changes, which

indicates that it is referring to a new dynamic object, a different dynamic object, or no object. Its value is

opaque and cannot be obtained and the value field of s_cb_data structure will be NULL. Its vpiObjId property

uniquely identifies what dynamic object, if any, a class var refers to.

What is the difference between a new dynamic object and a different dynamic object? If it is new, it is different, isn't it?

Unless you mean that the contents of the dynamic object is different (such as one of the data members changed value?)

 

Page 13: typos in 37.4 vpi_release_handle

and itsassociated resources

It is erroneous to call vpi_free_object on an invalid handle and the tool may crash.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Fri Mar 21 09:23:04 2008