Subject: RE: [sv-cc] READ API: a couple of thoughts, a new issue and a question
From: Bassam Tabbara (bassam@novas.com)
Date: Thu Dec 18 2003 - 17:17:06 PST
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 : Thu Dec 18 2003 - 17:17:55 PST