[sv-cc] New revision for VPI read/write doc

Subject: [sv-cc] New revision for VPI read/write doc
From: Bassam Tabbara (bassam@novas.com)
Date: Wed Nov 05 2003 - 15:05:37 PST

Here it is, my fault, I sent it twice to ac list, sorry... mixup in my
aliases.
 
-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: Bassam Tabbara [mailto:bassam@novas.com] 
Sent: Wednesday, November 05, 2003 1:24 PM
To: 'sv-ac@eda.org'
Subject: RE: New doc for VPI portion

Hi All, here's a resend of the email. I also took the time just now to
go through again and fix up a few things, please ignore the earlier pdf
(if it ever gets to the reflector). Please look at my comments below as
an overview of the changes. 

Thx.
-Bassam.
enc. pdf file of the LRM addition

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

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

-----Original Message-----
From: Bassam Tabbara [mailto:bassam@novas.com] 
Sent: Tuesday, November 04, 2003 6:54 PM
To: sv-ac@eda.org
Cc: Dr. Bassam Tabbara
Subject: New doc for VPI portion

Hi All, [Sorry for long email, brain dump description of my goals for
this revision, Swapnajit the LRM writeup is not on the website, only the
original Novas donation is...]

First of all thanks to all for the feedback (Doug, Michael, and all) in
last meeting. After I went through the notes (thanks Ralph) and my own
spec, I realized that the LRM version did not have 2 crucial things
after the map from the donation material:

1) No "load list", somehow I neglected that part so the API had a major
shortcoming in terms of access (efficiency): I added this now (but
expect bugs, sorry did not have much time for this task this week).
2) The writer portion with vpiHandle: I did not distinguish between the
vpiHandle for the file and any other VPI handle as my idea called for in
the previous version. I fixed this in the LRM with some note about
handles not being interchangeable. I think the idea now comes across
better, I'll let you read it then we can discuss. 

These are the 2 primary fixes which I think address most of the issues
raised. I put an example for (1) so access is obvious. 

** Other things I want to emphasize that caused some misunderstanding:
- Efficiency is really governed (mostly) by the *load* step. The load in
the document means loading from (a file) to active memory. Access or
reading is then a consequence.
- The API is intended to be a "user perspective" set of calls. It does
not address tool specific load optimizations, it does however give the
tools an opportunity to optimize things: purpose of
vpi_data_read_init(....) based on access mode, and also giving the tool
the set of things (either a scope, and/or list of objects) that will be
loaded. Actual load call is separate in vpi_data_read_ load(list or
object here). I've put a comment to this effect in a couple of places.
So basically, I want to leave up to implementation (and it really should
be hidden from user in any case) setting a specific time window for
active things in memory and swapping things in and out depending on
usage: All this really depends on the type of tool: simulator, waveform
viewer etc.... I'd rather keep the API: user side, simple, symmetric,
integrated to VPI. There are no other donation elements with regards to
this part since the goal was to keep it generic (multi-use). I think my
forgetting to put the load list made this problem worse....

** Example: I put an example on the usage of the API. I think that is
what will go in the LRM, and the intent is now clear. Doug, I don't have
an example handy, seems like too much effort to start/maintain that I
don;t have the bandwidth, may be you can help if you have some input
here, but not sure what the purpose would be, it is not going to LRM.. I
don't think.

** One last issue on my mind: There was some discussion about libraries
(Francoise, Doug, Joao...) and multiple implementations (in a
multi-vendor flow), ... Ralph did not capture in minutes. This is
already covered in the libraries chapter, right ?

** Please let me know of any bugs, and help in proof-reading. I suspect
the function lists have many hidden ones.

Thx.
-Bassam.

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

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

This archive was generated by hypermail 2b28 : Wed Nov 05 2003 - 15:08:00 PST