Subject: Re: [sv-cc] READ API: a couple of thoughts, a new issue and a question
From: Swapnajit Mittra (mittra@juno.com)
Date: Thu Dec 18 2003 - 16:55:14 PST
Team,
I will track these. Bassam, please cc the team if you have any
comment on these.
-- Swapnajit Mittra Project VeriPage ::: http://www.angelfire.com/ca/verilog-- Francoise Martinolle <fm@cadence.com> wrote:
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.
________________________________________________________________ The best thing to hit the internet in years - Juno SpeedBand! Surf the web up to FIVE TIMES FASTER! Only $14.95/ month - visit www.juno.com to sign up today!
This archive was generated by hypermail 2b28 : Thu Dec 18 2003 - 16:57:00 PST