Subject: RE: [sv-cc] READ API: a couple of thoughts, a new issue and a question
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Thu Dec 18 2003 - 14:18:28 PST
Francoise,
Just a quick comment regarding your issues on the information model:
note that the relations that are available from objects in a waveform database
depend *entirely* on the DB engine you are using. For example, it is not true
to state that:
"But for example the drivers and loads information of that vpiNet would not be
available in the database. "
This may apply to some databases, but certainly not all databases!
I believe it should be at the vendor's discretion how rich and complete they
want to make the model that is available through the read API. The standard
should specify a mininum baseline functionality that users can rely upon, but I do
this should not be taken as a constraint. Note that I believe most simulators
already follow a similar approach, providing differening amounts of VPI capabilities
depending on the "go fast" flags with which the model was compiled (ranging
all the way from "no VPI", to "read access", "write access", "connectivity", etc).
The two new issues you raise (representation of partial objects and of dumping
gaps) are good questions, which I hope Bassam will address.
Joao
==============================================================================
Joao Geada, PhD Principal Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
377 Simarano Drive, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org]On Behalf Of
> Francoise Martinolle
> Sent: Thursday, December 18, 2003 4:02 PM
> To: sv-cc@eda.org
> Subject: [sv-cc] READ API: a couple of thoughts, a new issue and a
> question
>
>
>
> 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 - 14:19:05 PST