Subject: RE: [sv-cc] READ API: a couple of thoughts, a new issue and a question
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Dec 19 2003 - 07:10:02 PST
Agreed but this makes it hard for an application to find out what is
supported by a database tool. That is the reason why I wanted to make the
minimum subset required by the standard explicit and different from the
regular VPI information model.
A desirable enhancement would be the capability for an application to
inquire the VPI support available.
At 05:18 PM 12/18/2003 -0500, Joao Geada wrote:
>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 : Fri Dec 19 2003 - 07:11:13 PST