Subject: [sv-cc] More minutes for the face2face (11/12/2003): Bassam's read/write presentation minutes
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Thu Nov 13 2003 - 11:24:15 PST
starting from about 11:50am - Bassam's presentation
- Bassam presented some new changes to the data read/write list
- added a load list mechanism to address efficiency issues from last meeting
overview of changes:
- additional note (last paragraph) in requirements section re the
focus of the API, specifically aimed primarily at users rather than
tool providers
- discussion quickly ensued over how the write side mechanisms would work
given that VPI is not aware of the contents in foreign models
Aside: simulators already know how to dump their own contents, so there is
no value to providing an API only for simulators to write SV content.
Therefore, write API is valuable only to dump foreign data.
Question on whether we should tackle the writer side. We have decided
to first complete the read side APIs, only then deal with the writer.
Followed by quick investigation into the technical issues related to
foreign models being able to write. All predicated on being able to
create "handles" to foreign data that can then be used to write into
the database:
fp = vpi_open_write_file(...);
h = vpi_create_handle(fp, "name of foreign thing", "SV type descriptor str");
vpi_write(fp, h, time, vpi_value_p);
h would be a new VPI handle type (vpiApplicationHandle), supporting
at least the following properties:
vpiType, vpiName, vpiTypeDescriptorStr
possibly also vpi_get_value (gets last value written)
Bassam will split proposal into 2 separate chapters (read and write)
Discussion then continued back to the read side APIs
Presentation of overview of how read side API is used (section 29.5.*)
1) select the data to be loaded
- access type
discussion on what to name the various access types, as first two
are both interactive. For time being, name them as follows:
vpiDataReadAccessLimitedInteractive
vpiDataReadAccessInteractive
vpiDataReadAccessPostProcess
- scope and/or item list (either can be NULL, or both provided)
if both given, acess given to the union of both elements
2) obtain handles to the objects
using standard VPI mechanisms
3) load the objects:
- vpi_data_read_load(handle)
or
ll = vpi_data_read_createloadlist()
vpi_data_read_addtoloadlist(ll, handle)
...
vpi_data_read_addtoloadlist(ll, handle)
vpi_data_read_load(ll)
once objects are loaded, they are now in memory
Raised issues on how to access data on time order traversal.
As API is given now, access is easy on object order traversal
(ie all value changes on a particular object at a time); however
obtaining all value changes at a particular time is not easy.
Some discussion as to why this would be needed (stimulus
replay, etc); Bassam stated that time order can be obtained
but that he did not want to specify that level of detail.
Arguments that object order and time order traversal are both
required, though any one implementation may have one order
more efficient than the other.
Issue to be revisited
4) scan the data out of the object via iterators (29.5.5.1)
linear scan with prev/next, random order with jumps
What time do scan handles point to when originally created?
Bassam will specify this in next update
some discussion on the origin of confusions in interpretation
of this spec. Some attributed to there being 2 "VPI"s in discussion:
a) the simulator VPI model
b) the "separate from simulator" waveform reader VPI model
both models are separate, but both using the same API (aka VPI).
Asked Bassam to provide diagrams describing this and also an
abstract data model (simulator -> waveform file -> reader ...)
In example demonstrating loading, replace "silly" by "simple"
-Discussion on coupling of read VPI model vs the simulator VPI model
discussion concluded that read model can both exist separate from
simulator AND separately. When inside the simulator, the model
exposed is a superset of the simulation model (ie simulator + time history)
whereas outside simulator only information dumped into the waverform is
visible
Summary of action items:
- split off proposal into reader and writer portions.
[focus first on reader]
- provide object model for all the new handle types (traverse handles)
- provide abstract diagram for use model/data flow from simulator->writer->reader->application
- use vpi_control for performing more operations, rather than relying
on new calls. vpi_control takes first argument as command, then arbitrary
set of other arguments. So could be used to move time (prev next, even
across collection), etc
- minor other corrections as noted in the minutes
==============================================================================
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
==============================================================================
This archive was generated by hypermail 2b28 : Thu Nov 13 2003 - 11:26:18 PST