Subject: [sv-ac] New doc for VPI portion
From: Bassam Tabbara (bassam@novas.com)
Date: Tue Nov 04 2003 - 18:54:15 PST
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 : Tue Nov 04 2003 - 18:56:31 PST