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:15:07 PST
Aside from fixing the information model to include everything that has a value,
the other point I was trying to make is what do we specify if the reader
application attempts to traverse a object which only has a partial dump in
the database?
At 05:17 PM 12/18/2003 -0800, Bassam Tabbara wrote:
>Hi All,
>
>Thanks Joao and Francoise,
>
>Yes Francoise I agree with Joao in that the intent is to specify the
>minimal support, there are many other data/relationships.
>
>As for the 2 issues you raise:
>1) The proposal allows for anything you can associate a value with, so
>there is no restriction. In the description I say "anything that has a
>value obtained from vpi_get_value() including .... " unfortunately the
>model diagrams are merciless in terms of explicitness.
>
>** Francoise, I did not know you were not aware of this, you were
>supposed to beef that up if I forgot anything while drawing the model
>diagram ... !!! :-)! I thought the only one that was missing is
>parameter (initially I did not want to enforce keeping this, but I would
>like to add it). Isn't all the var/net/reg selects included in
>"nets/regs/variables ..." classes ??? If not then this model diagram
>business is really lousy (forgive me :-)!! But I'm fed up with drawing
>with frame so forgive my outburst !! :-)! Why not just create a new
>class with everything that has a value ???? I'm tempted now to throw in
>expr too :-)! No no just kidding.
>
>** Bottom line if anything is missing it is editorial, not a
>limitation...
>
>2) Dump on/off: Yes this came to my attention after your feedback
>Francoise, I'll clarify that.
>
>Thx.
>-Bassam.
>
>P.S. Please help on (1) let me know what to add, so far I have:
> - parameter in Bold.
> - memory word does not need to be there, right ?
> - what else from above ???
>
>
>--
>Dr. Bassam Tabbara
>Technical Manager, R&D
>Novas Software, Inc.
>
>http://www.novas.com
>(408) 467-7893
>
> > -----Original Message-----
> > From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
> > Behalf Of Joao Geada
> > Sent: Thursday, December 18, 2003 2:18 PM
> > To: Francoise Martinolle; sv-cc@eda.org
> > Subject: RE: [sv-cc] READ API: a couple of thoughts, a new
> > issue and a question
> >
> >
> > 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:18:24 PST