Subject: [sv-cc] Fwd: READ api issues
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Jan 09 2004 - 08:08:39 PST
>My previous email bounced.
>The Cadence VPI/database experts and I have reviewed the latest proposal
>and we are still not satisfied with the final specification. We have
>brought some of these issues in the past and we still think that these
>issues are important and should be solved.
>
>When accessing data from multiple databases, the user application must
>keep track of which handles comes from where. Instead it should be
>possible to query which database a handle originated from. Our preference
>would be to create a database handle when opening a database and allow to
>obtain the database handle back from any other handle obtained from the
>database. The current proposal specifies a new property (vpiInExtension)
>to determine if a handle was obtained by a specific access to a database;
>this does not work at all in the following two scenarios:
> a) I have a handle from a different extension, and that handle
> implementation is completely unknown to my inferface function vpi_get,
> b) I have two databases for which I use the same READ api to access
> it. Two handles coming from each databases would always have this
> property TRUE. I can't tell if these handles belong to a different
> database because I have no database handle to compare it to!
>
>
>The current proposal does not separate the data accessed via a simulator
>from the data accessed from the data base management software. We would
>prefer to have different vpiTypes for handles obtained from a database,
>the reason is that the representation of a vpiNet in a database is
>completely different from a vpiNet obtained from the simulator. With the
>inability to tell from where it obtained the handle, an application has a
>hard time keeping track of the handles.
>Our preferred approach is to have a vpiDbObject type to represent a
>database object, there would be an additional property (vpiOrigType) to
>indicate the type of the object it originated from in the design. For
>example a vpiNet object in the design would have a corresponding
>vpiDbObject in the database domain. The only correspondence which would
>exist between the simulation object and the database object would be that
>they have the same vpiName and vpiFullname.
>
>In the scheme proposed to have and use more than one set of VPI routines
>at the same time the specification of the vpi_load_extension() is
>incomplete. In fact the vpi_load_extension() is the only routine which is
>NOT part of the READ API library. This routine should be implemented by
>the application or tool which needs to invoke the READ API and needs to be
>provided as a separate object or library. There are some conventions on
>the shared library name and bootstrap function for the READ API which need
>to be explicitly stated.
>
>The API is not general enough to also be applicable to writing the data
>base, which is a desirable trait. If a function to open a database was
>provided with the capability to indicate the access (read, write...) to
>the database, that would be preferable to an implicit data base open with
>vpi_read_load().
>
>Some of the extensions are not in line with the spirit of VPI:
> provide basic building blocks
> provide a very few number of general functions.
>Specifically:
>Some of the functions added could have been done with existing VPI functions.
>Ex: vpi_trvs_get_time() can be accomplished with vpi_get_time()
> vpi_goto() can be accomplished with vpi_control() and vpi_filter()
>
>Some functions added have slight variations which could have been
>implemented with existing functions. ex: vpi_load_init_create() could have
>been implemented by creating a collection of all objects within a scope:
> Ex: colH = vpi_create(vpiCollectionK, 0, scopeH, vpiObjDecls) ;
> vpiObjDecls is a new iteration which will return all variables, regs,
> nets in a scope.
>
>There are many variations of functions : vpi_read_load(), vpi_load_init(),
>vpi_load_init_create() with no distinct advantage.
>
>The application needs to concern itself with whether the data it is
>accessing is loaded into memory. This instead should be an implementation
>issue. Whether or not the data is loaded should be transparent to the
>application. When accessing the trvsObj handle with vpi_handle(), the data
>should be loaded if not already loaded. There should not be any specific
>instruction to load the data. The READ API implementation should be
>concerned with efficient loading of the data, not the application. A
>collection of objects should be a good enough indication to the READ API
>implementation to prepare for loading this collection of objects.
>
>The proposal assumes a lack of knowledge of the current VPI standard
>specification which is not appropriate nor necessary. For example, it
>should not repeat the specification of the vpi_handle(), vpi_iterate() nor
>explain the VPI naming conventions (section 29.1.2).
>
>The proposal is written as a user manual and not as a standard
>specification. The examples are useful but are not normative and should be
>moved to an informative section. The examples make the specification
>harder to comprehend. The term "user", which is used throughout the
>document, is not accurate. Generally, the document uses this term to
>refer to the application developer. However, there are other "users",
>such as the API developer (which is using the specification while doing
>his/her development) or the designer (which is using the tool) ...etc.
>
>Collections should be a general concept. This concept is applicable in
>other situations. As currently specified it is too specialized for the
>collection of database objects.
>
>Some new concepts have been introduced but are incompletely defined such
>as the time of a trvsObjCollection. We believe that this in particular
>should not be defined.
>
>Nothing is specified on what happens if an object has been partially
>dumped into the database.
>
>
>
>
>Minor issues:
>
>Section 29.1.1:
>The first diagram on page 1 shows a box containing "foreign". Since this
>is not discussed at all in the document, this should be removed.
>The introduction which talks about what systemVerilog adds in terms of
>data types should be removed when final inclusion in the SV LRM.
>If efficiency is not an API concern and is dealt behind the scenes, why
>having the functions to indicate to load the data and query if the data is
>loaded???
>
>Section 29.1.2: this section should be removed as it is common knowledge.
>Section 29.2.1
>The vpiObjCollection and vpiTrvsObjCollection should be removed.
>The list of the object types which can be passed to vpi_get_value() is
>inconsistent with the VPI information model defined for SV. Ex: Reg and
>Reagarrays have disappeared.
>We should not attempt to list the object types here.
>The vpiHasNoValue property is missing.
>
>
>Section 29.2.2.1 and 29.2.2.2
>The separation between static and dynamic info has no precedent in VPI.
>This classification has no advantage.
>VpiIsLoaded should be removed.
>
>Section 29.2.2.2
>The reference to vpi_goto() should be removed.
>vpi_get_time() can be used on a vpiTrvsObj, there is no need for the
>additional function vpi_trvs_get_time().
>
>Section 29.2.3
>This section is useless and should be removed.
>
>Section 29.3.2:
>A single vpiType vpiCollection should be provided. No need to have
>specialized classes.
>
>Replace:
> The first call gives NULL handles to the collection object and the
> object to be added.
>
>with:
> The first call provides a NULL handle to the collection object and the
> object to be added to the collection.
>
>Another way to create a collection is to provide an iteration type method
>and a reference handle.
>For example, in order to create in one shot a collection of all the nets
>which are declared in a scope:
>colH = vpi_create(vpiCollectionK, 0, scopeH, vpiNet);
>This is a very useful capability.
>
>Section 29.3.2.1 Operation on collections
>vpi_read_load() should be removed.
>
>vpi_goto() should be removed.
>The behavior vpi_handle(vpiTrvsObjCollection, objCollectionH) is
>unspecified with respect to unrecorded objects.
>Do you get a trvsObj for a particular object if no data has been recorded
>for that object? Do you get a NULL handle for that trvsObject? Do you only
>get back a collection of non NULL trvsObj?
>
>
>Section 29.4:
>The list of the traversable objects is incorrect.
>
>We should only have a vpiCollection type object. The fact is that there is
>no specific additional properties about a vpiTrvsObjCollection of
>vpiObjCollection; why having specialized classes?
>The only possibility seems to be the vpiTrvsObjCollection 1-to-1 method
>which has an incomplete specification.
>
>Section 29.6:
>vpi_read_get_version() is not necessary VPI has already a function to
>access version information:
>vpi_get_vlog_info().
>
>vpi_load_extension() is not a READ API function, it is a function which
>must be implemented by the application or tool which intends to call the
>read api functions. This should be clearly distinguished.
>
>vpi_load_init(), vpi_load_init_create(), vpi_read_unload(),
>vpi_read_load(), vpi_goto() should all be removed.
>
>vpi_goto() can easily be replaced by vpi_control() followed by
>vpi_filter() with a criteria of vpiHasVC
>
>
>Section 29.7:
>I disagree with the reading of the data.
>Accessing a vpiTrvsObj with vpi_handle() should be sufficient to access
>the database data. There should not be any need to explicitly "load".
>
>Section 29.7.1:
>vpi_load_init() and vpi_load_init_create() are unnecessary
>functions. Loading should be transparent to the application. The
>indication of which data is to be loaded can be suggested by the handles
>to the objects which have been obtained or gathered in a collection with
>vpi_handle(), vpi_iterate(), or vpi_create().
>
>Sections 29.7.3, 29.7.3.1
>These sections should be removed for reasons explained earlier.
>
>Section 29.7.4:
>"So far we have outlined..."
>should be removed.
>
>Why is the initial time of a trvsObj left to the tool implementation.
>Shouldn't it start at the first time recorded in the database or at the
>first time there is a value recorded for that object?
>
>
>Section 29.7.2.3:
>vpiHasNoValue property does not appear in the diagram featuring vpitrsObj.
>
>Section 29.7.5:
>Some fragments of code which try to add a handle at a time to a collection
>should be replaced with the capability of adding an entire iteration at a
>time to the collection (see previous comments on vpi_create()).
>
>vpiReg is no longer a vpiType in SV VPI (at least in the latest spec sent
>by Joao)
>
>Section 29.7.7;
>Remove any reference to vpi_goto().
>
>The time of a trvsObjCollection is undefined. Is it the smallest time for
>a trvs object?
>Some trvsObj of the collection may have different times. We should not
>define the time of a trvsCollection. It seems that the code wants to
>compare the time of each trvsobj with the time it passed to vpi_control()
>in order to determine if a trvsObvj had a VC at that time. There is no
>need to define the time of a trvsObjCollection.
>
>The vpi_goto() is unnecessary it can be replaced with the combination of
>vpi_control() and vpi_filter() with a criteria of vpiHasVC.
>
>Section 29.8
>Should be removed. No need to vpi_read_unload() : the tool itself should
>implement its own optimizations for loading and unloading and not depend
>on the application to instruct it to do this.
>
>Section 29.9
>The user_data field is unnecessary.
>It is stated that the struct_version set to 1 for systemVerilog 3.1a. I
>think that struct version value should not be specified by the standard.
>It is tool implementation specific. What about if the tool wants to
>provide other vpi function (vendor extensions), the tool will need to
>generate a different version numbers for each s_vpi_extension structure
>that is different. This is irrespective of what happens to the standard spec.
>
>It is unclear who calls vpi_load_extension() and where the implementation
>of this function resides.
>
>Section 29.10:
>Section 29.10.1
>vpi_control():
>"Try to move" why try? Replace with "request to move"
>remove reference to vpi_goto().
>
>Section 29.10.2
>Replace vpi_read_get_version() with vpi_get_vlog_info().
>
>Remove vpi_load_init() and vpi_load_init_create().
>
>Replace vpi_trvs_get_time() with vpi_get_time() and enhance vpi_get_time()
>to handle vpiNextVc, vpiPrevVC etc...
>
>Remove vpi_read_load() and vpi_read_unload().
>
>vpi_create() is missing creating a collection with an iteration.
>
>Remove vpi_goto().
>
>
>
>
>
>
>
>
This archive was generated by hypermail 2b28 : Fri Jan 09 2004 - 08:09:52 PST