[sv-cc] RE: READ API with comments

Subject: [sv-cc] RE: READ API with comments
From: Bassam Tabbara (bassam@novas.com)
Date: Wed Jan 28 2004 - 13:48:43 PST

Thanks Francoise,
 
I think I took care of both of these in the rev I sent out (even without
receiving this email). I ended up splitting the model diagrams anyway since
some methods are specific to one and not the other. The "Belong/Inextension"
bit I think you ended up agreeing with this after the discussion with Joao
(any extension can check if the said handle belongs to it, the handle cannot
know where it came from, at least for now this is a simple way, later may be
some addition to vpi_compare_handle are in order).
 
-Bassam. 

--
Dr. Bassam Tabbara
Technical Manager, R&D
Novas Software, Inc.

http://www.novas.com <http://www.novas.com/> 
(408) 467-7893 

-----Original Message-----
From: Francoise Martinolle [mailto:fm@cadence.com] 
Sent: Wednesday, January 28, 2004 8:57 AM
To: bassam@novas.com
Cc: sv-cc@eda.org
Subject: RE: READ API with comments

Bassam,

I had found this email which I never sent to you. It has to do with some
small erratas for the DATA READ API.

Replies starting with fm.

At 03:59 PM 1/14/2004 -0800, you wrote:

Thanks a lot Francoise, I'll endeavor to accommodate all (and apologies if I
have seemed impatient at times, not my intent at all, I appreciate the
feedback...yes the deadlines are short, given we all have other work too
:-)!).

Couple of questions/comments:

1) Your comment on figure 30-3 (the one on collections and traversable), so
you mean there needs to be 2 *separate* figures (same methods/properties)
for objcollection and traversable, and then for trvsCollection and trvsObj,
correct ? Would that fix it ? If it's more work than that I'll just send you
the fm (or you can file errata later), so let me know please ASAP.

fm> What you can do is have twice the arrow which is labelled vpiMember, one
starting from objCollection and ending at traversable and the other starting
from travsCollection and ending at trvsObj.

The collection should be changed to "collections" and you should have
another bubble called collection inside to represent the general
heterogeneous collection. From a "collection" another 
arrow vpiMember should end to a new unamed class  which represents any
handle type.

2) Your comment about vpiInExtension (now I changed this name to vpiBelong,
better ?), I remember now on looking at this in detail, that my intent is
really to create a pointer (say reader_p) even if different databases case
(not just a different tool), this makes it easy to incorporate what dbs
currently do (different object ptrs for different dbs). So indeed it does
cover both scenarios (different reader extensions, and different dbs). The
database is an argument to load_extension routine. No action item here (on
my slate) on this.

fm> I still don't understand how you can figure out if a handle was created
for a given database. vpi_get(vpiBelong/InExtension, hdl) can only tell you
if that hdl was created by this extension, cannot tell you which database it
was created from because supposedly you have the same API for different
databases. 

3) Finally "optional", I had meant the user can optionally call the
vpi_load() and so on... I think you rather mean the implementors can
*optionally implement* (of course they can optionally implement anything
...). I'd rather not add "optional" in the LRM ... But I'll think about this
some more later, must fix (4) and (1) first.

4) get_time() working on converting everything to it (and removing
get_trvs_time()).

** BTW, if you do not get around to answering any of the above today then
would have to be errata for later, I'll send what I have done so Swapnajit
can meet the deadline.

Thx.
-Bassam.

--
Dr. Bassam Tabbara
Technical Manager, R&D
Novas Software, Inc.

http://www.novas.com <http://www.novas.com/> 
(408) 467-7893

> -----Original Message-----
> From: Francoise Martinolle [mailto:fm@cadence.com] 
> Sent: Wednesday, January 14, 2004 2:52 PM
> To: bassam@novas.com
> Subject: READ API with comments
> 
> 
> I annotated the data read API with some comments. I could not 
> complete the 
> entire review and I suggest that you check for appearance of 
> functions 
> which we removed. I doubt I can complete the review today.
> 
> Forget about the vpi_load_init and vpi_goto comments which we 
> discussed 
> this afternoon.
> 
> I appreciate we could come to an agreement for some of these 
> things. Thanks for working with us on this.
> ps: I am sorry if I have been annoying at times but it is 
> only on the goal 
> to get the best spec possible in the allocated time (which is 
> ridiculously 
> too short).
> Francoise
>         '
>

This archive was generated by hypermail 2b28 : Wed Jan 28 2004 - 13:55:23 PST