Francoise, thanks for the great feedback. I will address all of it as noted below.
Replied separately to above.John,I am mostly in agreement with what is proposed here, except for the definition of vpiAllocScheme, details arewithin my comments.Also I would like to be able to get a value for a classVar. I guess we do not allow this now becausewe want to provide it along with vpi_put_value and that is not currently defined. I would like the 64 bit identifier to be returnedas a value.Another minor comment is that I would like to be able to query a lot more from within a cbEndOfFrame, cbEndOfThreadcallback.I do not see the need for cbEndOfObject callback (can someone illustrate how this is going to be usedwhich cannot be accomplished with a cbEndOfFrame, EndOfThread or CbReclaimObject?
Thanks.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 tothose objects, and to any subelement of this objects. Handles to callbacks placed on these objects
will also be released.
I'll have to re-phrase that to be clear. I meant automatics and I do not think of a static as belonging to the frame or thread. For a frame, our definition clearly only means automatics. Anyway, I think of the static variables as existing independently of the lifetime of the frame or thread.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.
Because it is long discussion already recorded, let's take this separately.
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.
vpiAllocScheme doesn't belong on the instance. It was a cut and paste mistake.
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.
The class var is automatic. The class object and any of its members are dynamic.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
The class var is static. Again, only the class object and any of its members are dynamicfunction foo();
static C fv = new; // is it staticSheme or DynamicScheme?
endfunction
endmodule
OK, we do agree on the ideas and the fact is that you could represent the information in one or 2 properties. We decided to keep the existing vpiAutomatic property and clarify its definition. We decided to add a property that answered the entire question. Your idea is to get 2 properties and recognize the answer to the entire question using both. Neither is wrong, is it?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.
Agreed.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.
Agreed.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.
Thanks, my mistake.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.
Thanks.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.
The frame and all its variables still exist until you return control. So, yes you can. I can add a clarifying comment.---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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?
I stated that you can get properties of the object and there is no inherent reason why value wouldn't continue to be available, but I did not say it. I can clarify that it will be.Can we get the value of an object for which we obtained a cbENdOfObject?
Well it is meant to mark the passing of a life. You may get properties or value. For an object that is dynamically allocated and about the be reclaimed, you cannot navigate safely. All navigation is considered erroneous. Intentionally erroneous, not an error.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?
Well, I prefer the terminology member, but SV calls its data members properties in Draft 4 so I was trying to use that terminology. VPI is not perfectly aligned in terminology with the rest of the LRM. You are right that they are considered variables in VPI. I wanted to be clear that class property variables are included. I'll try to reword it.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?
Again, I was trying too hard. If the class variable is not initialized and a new object is constructed and assigned to it, that is a VC. If it is refering to a class and an assignment is made sich that is refers to a different class that already exists, that is a VC. That is all I meant, and I guess it is obvious.
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 archive was generated by hypermail 2.1.8 : Fri Mar 21 2008 - 10:44:21 PDT