Subject: [sv-cc] READ API: a couple of thoughts, a new issue and a question
From: Francoise Martinolle (fm@cadence.com)
Date: Thu Dec 18 2003 - 13:01:31 PST
A couple of thoughts:
-------------------------------
I think that one thing that is missing from the READ api proposal is the
ability from an application which uses the READ API is to be able to figure
out which database these trvs obj handles acquired are coming from.
Right now, section 29.9 of the proposal states that it is the
responsibility of the application to keep track of which database the
handles are coming from.
If we had a database handle returned by the function vpi_read_init, it
could be used and passed back for example to vpi_read_close.
Also It should be possible to access the database handle of any trvsobj.
Another property of the database would be the ability to inquire about the
min and max time of its recorded data.
I have discussed this with Bassam before and he feels that it is not
necessary; however I wanted to get the opinion of others on this subject.
Another philosophical difference of opinion I had during my discussion with
Bassam is around the vpi types of the handles acquired when accessing the
simulation design and the vpi types of the handles acquired when accessing
the database.
Currently the proposal uses the same underlying VPI information model for
accessing a vpiNet of a simulated design and a vpiNet stored in a database.
However, it is obvious that a limited amount of information about that
vpiNet will be stored in the database. At the least, I can see its name,
full name, data type and upper scope recorded in the database. But for
example the drivers and loads information of that vpiNet would not be
available in the database. Secondly, the proposal states that handles
obtained from the simulator will not be inter -operable with handles
obtained from the database.
In my opinion, keeping the handle types the same is confusing as the
supported VPI functionality will be different and the handles are not inter
changeable.
That is the reason why I would favour a completely separate information
model for accessing objects stored in a database. I would have for example
a new vpiType vpiDbObject from which
I could obtain the vpiTrvsObj. The name and fullname of that vpiDbObject
handle would be the same as the corresponding vpiNet in the simulation design.
Additionally I could have a property on a vpiDbObject which would
characterize the original type of the object in the simulation design. For
example the property vpiOrigType would return me vpiNet for that
vpiDbObject. The only things which would be the same are the name and
fullname of the dbObject and net, which would logically suggest that the
only means of traversing from a vpiNet of the design to its recorded object
data (vpiDbObject) in the database is to do vpi_handle_by_name.
I think that database must record instance/scope information and store the
objects by scope; the same approach can be followed to represent scopes in
the database. A dbScope object type would have a name and fullname
corresponding to the original scope in the Verilog design
(vpiOrigType). From a dbScope object, one could iterate over all the
dbObjects belonging to that scope which have been recorded in the database.
If someone is interested I can send out a VPI diagram showing the database
access I have in mind.
New Issue:
----------------
There is another issue which came to my mind just recently.
Consider a design which has a vector net and for which only a bit of that
vector has been probed and is present in the database. The current proposal
does not allow to access a trvs obj for a var select (a sub-element of a
variable array or variable struct).
In fact more generally, you don't know how information was probed and you
may want to read it back in a different way: in case the vector was probed
but was expanded, the database will have a record for each one of the
vector bits, another scenario is that only selected bits of the vectors
where probed. What can we read from the database in these cases?
A question:
--------------------
It is not clear in my mind how gaps in the data recorded for a trvsobj are
handled.
If a probe for a particular object was disabled, is this considered a VC?
I think it should and vpi_control should be specified accordingly.
This archive was generated by hypermail 2b28 : Thu Dec 18 2003 - 13:02:25 PST