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:24:42 PST
Oh, as for db handle, I think it's really not that useful, it won't be
used anywhere much (you now have a top scope handle and can do whatever
with it ...), keeping a dbhandle would be useful if the intent is to use
it (to always be explicit) in any vpi call e.g. vpi_handle(db, ...) but
that only serves to make this diverge very rapidly and needlessly from
VPI.
The goal of multiple reader libs/dbs/... And so on to clear confusion is
already addressed by Joao's proposed (load_extension...), thanks Joao
for that, Francoise/Michael for the discussion, I'll add that (almost)
verbatim in the multiple db section.
Thx.
-Bassam.
-- Dr. Bassam Tabbara Technical Manager, R&D Novas Software, Inc.http://www.novas.com (408) 467-7893
> -----Original Message----- > From: Bassam Tabbara [mailto:bassam@novas.com] > Sent: Thursday, December 18, 2003 5:17 PM > To: 'Joao.Geada@synopsys.com'; 'Francoise Martinolle'; 'sv-cc@eda.org' > Subject: RE: [sv-cc] READ API: a couple of thoughts, a new > issue and a question > > > 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:25:22 PST