Subject: RE: [sv-cc] Fwd: READ api issues
From: Francoise Martinolle (fm@cadence.com)
Date: Tue Jan 13 2004 - 13:02:22 PST
Bassam,
see my replies.
At 09:47 AM 1/13/2004 -0800, Bassam Tabbara wrote:
>Hi Francoise, I think most I will add (see below my OKs on the load_init
>and saying loads optional and so on, I think several other edits I will
>make), for the vpi_get_time, here's my opinion:
>
>FM: vpi_trvs_get_time, We can enhance vpi_get_time(vpiHandle, s_vpi_time)
>to perform the same. The s_vpi_time data structure has a field (type)
>which can be set to return different formats (currently vpiScaledRealTime,
>vpiSuppressTime, vpiSimTime). You just need to add your specific
>constants: vpiMaxTime, vpiMinTime, vpiNextVC, vpiPrevVC ...
>
>BT: Extending s_vpi_time this way does *not* work in my opinion, that
>field (vpiSimTime, vpiScaledRealTime...) is for specifying the type of
>return of time read/unsigned64 and so on ... we need it to be **as is**
>i.e still need to return in different types.... I think adding a new field
>is an option but probably *not backward compatible*, so seems easier to
>add a new routine. BTW, just like the "get" routines this one is not that
>crucial it just adds flexibility, not much more, so not worth the
>effort/risk of extending.
The s_vpi_time structure is defined as:
typedef struct t_vpi_time {
PLI_INT32 type;
PLI_UINT32 high, low;
double real;
}s_vpi_time, 8p_vpi_time;
The type field is a 32 bit value for which we are only using the 2 first
bit to mean either viScaledRealTime, vpiSimtime or vpiSuppressTime.
Theses constants are defined to be:
#define vpiScaledRealTime 1
#define vpiSimTime 2
#define vpiSuppressTime 3
vpiScaledRealTime states that the time will be returned as a real, while
vpiSimtime states that the time will be returned as a 64 bit quantity.
There are 30 other bits of the type field which can be used. You can also
use the 30 bits in combination with the 2 first bits.
Let's assume that I define vpiMinTime to be 4.
Let's say I want to get the mintime of a trvsObj as a real number, I would
allocate a s_vpi_time_structure and set its type field to be 5 since
vpiScaledRealTime is 1 and vpiMinTime is 4.
We can even provide macros to set and extract some bit fields of the 32 bit
type.
>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: Friday, January 09, 2004 9:18 PM
>To: bassam@novas.com; sv-cc@eda.org
>Subject: RE: [sv-cc] Fwd: READ api issues
>
>Comments starting witn FM;
>
>At 12:47 PM 1/9/2004 -0800, Bassam Tabbara wrote:
>>Francoise, thx a lot for the feedback. I will attempt to skim and offer
>>an opinion (since Swapnajit had requested this), all in all I do not
>>think there is substantial disagreement here, and I think some editorial
>>fixes can help clarify/address the issues you raise. Looking forward to
>>getting all the team's support in the vote, and the final polishing that
>>must be done to get the READ VPI in LRM form.
>>
>>** I honestly think these are either cosmetic/philosophical in nature, or
>>are valid editorial fixes. I think in some cases, I have to choose in
>>favor of the Novas tremendous experience in this serving different and
>>varied concerns from partner and customer alike (so yeah forgive the
>>"fluff" in a couple of cases but it's worth it), and my true attempt at
>>munging all of the different uses and applications of our API (and the
>>wealth of API routines ...), and I've done my best to present that in VPI
>>form in the proposal, in some cases using my best judgement tempered by
>>all the excellent input from all in keeping this in VPI form, so I
>>frowned on ideas that would move this away from a VPI style, I think we
>>all like that accomplishment so let's keep it. I sincerely appreciate all
>>of your efforts to help in this regard and correct the missteps or things
>>I dropped in all the revs so far. I've taken to heart Michael's comments
>>and Francoise's comments (before now and the ones below).
>>
>>** I only mean to help in the discussion below (and **only because
>>Swapnajit requested this**, I think people already know most of these) so
>>please take it at that, forgive my lack of detail in a couple of comments
>>(only because I've seen this so many times, but I know Francoise is
>>summarizing everything).
>>
>>-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: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
>>Francoise Martinolle
>>Sent: Friday, January 09, 2004 8:09 AM
>>To: sv-cc@eda.org
>>Subject: [sv-cc] Fwd: READ api issues
>>
>>>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:
>>>[BT] The heavy cost of extra complication with the addition of that
>>>extra "db" layer, and they are only for cases of "postprocess" mode is
>>>not worth it. In some sense they break the "advantage" built into the
>>>proposal of "treating similar things in the interactive/postprocess
>>>modes the same", and "keeping things simple". For all practical concerns
>>>you already have a **top scope handle** even when you have multiple
>>>scopes they are independent so you have a couple of handles, or even
>>>potentially you can always have a **virtual top scope** in the db
>>>storage, so have the extra db type floating around and so on in all
>>>cases is NOT worthwhile in my judgement. So you also have one handle in
>>>that case, but really a couple of handles is not that big of a deal
>>>(we;re talking VPI ...).
>>>[BT] Adding the db creates a lot of indirection to everything, you
>>>cannot then create a handle from a scope without passing a db
>>>pointer,to really do this as you suggest, if you mean a "virtual top"
>>>that's a minor thing (but not worth the typing ...), if you mean really
>>>using the db handle in all handle creation, that means this READ API
>>>will no longer look like VPI !!! I cannot then call vpi_handle() to get
>>>the trvsHndls and so on, and that's is NOT what I have in mind, and I
>>>think a lot of the members would not be happy with that approach...
>
>FM: I only mean that from any object that had obtained you can always ask
>which db it came from. The dbHandle acts much like a scope/module. It is
>a new one to one method. You don't have to ask about the db handle unless
>you need it. You can keep track of the handles yourself but it may become
>easier for an application to sometimes be able to get back the dbhandle.
>>> a) I have a handle from a different extension, and that handle
>>> implementation is completely unknown to my inferface function vpi_get,
>>>[BT] you get a FALSE.
>
>FM: Joao explained to me that you have to know that your interface created
>handles in a given address space in order to do this. It would work, I think.
>
>>> 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!
>>>[BT] Hmm, you can always compare the handles! This situation is no
>>>different than having multiple handles in any VPI ...
>>>[BT] I think in most cases having a top scope handle is sufficient. In
>>>other cases you would have a couple of (top) scope handles, or you can
>>>choose to add in the db a "virtual top" (aka root), to clarify the
>>>situation in case there are many top scopes (i.e. forest) in a single
>>>database. The "InExtension" is really for the READ api, yes. I think a
>>>database handle (aka root) adds another layer so for common case it adds
>>>complication. I do not think this is a worthwhile complication worthy of
>>>addition at this time. For all intents and purposes keeping things
>>>simple serves users much more than adding complication.
>>>
>>>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.
>
>FM: after discussion with Joao, I kind of agree with the approach taken of
>using the VPI information model even for handles pointing to objects from
>the database.
>>>[BT] Again the intent is to be simple and allow flexibility. This goes
>>>hand in hand with the above if there is a separate dbobject than this is
>>>ok. But in my opinion a separate db object really breaks the intent of
>>>the proposal to minimize different teatment of traverse objects
>>>**regardless of where they came from** whether simulator or db or what
>>>have you ... I do not think this simplicity is a burden it rather makes
>>>things neat, and there is no confusion users already keep track of
>>>handles of scopes and the like ... the extra virtual top is just an
>>>additional level of indirection, with no practical value.
>>>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.
>>>
>>>[BT] Hmmm, to the extent that this overlaps with Michael's comments
>>>about clarifications for the ***READ API concerns** I agree, we have
>>>these editorials. As for conventions, and bootstrapping and the like
>>>these are beyond the scope of this chapter ....
>
>FM: It should at least be said that this function implementation is
>supposed to be provided separately and executed prior using the READ
>API. I think that delivery of a shared library and integration should be
>part of a standard in order to enable full portablity of that library. A
>user which uses multiple vendor has always a problem trying to integrate
>the same API with different simulators. We should all agree on a standard
>mechanism.
>
>[BT] Ok.
>>>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().
>>>
>>>[BT] This is incorrect in my opinion. The trait is there, only this is
>>>the READ API.
>
>FM: I think that what I really meant there is to generalize the functions
>a bit so that they can be easily extended to also be used in the write
>case. For example having a function to open a database such as;
>vpi_db_open(filename, access, flags) where access can be read or write.
>[BT] Ok.
>>>
>>>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()
>>>
>>>[BT] This is also incorrect. **ALL** the extensions are done to the
>>>existing VPI when applicable, and you can do **everything** using that
>>>set of API. An **additional** set is provided when the corresponding VPI
>>>cannot handle the extension for backward compatability (e.g. vpi_goto()
>>>has some additional function on vpi_control() but you can use
>>>vpi_control() to do the same function).
>
>FM: If vpi_goto can do what vpi_control can do and more, then we should
>only specify vpi_goto. vpi_get_time can be used to do what
>vpi_trvs_get_time can do . You can use the type field in the time
>structure to indicate the time : vpiNextVC, vpiPrevVC... vpi_get_time
>takes a reference handle which can be a trvsobj.
>vpi_goto should take a collection handle or a trvsobj and a s_vpi_time
>structure and return a new collection or trvsobj.
>[BT] Ok.
>>>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.
>>>
>>>[BT] This is a philosophical issue. Whether a collection is a mix of
>>>things, or there are some special types of collections. I chose the
>>>latter, the former is there for later extension. It seems reasonable as
>>>an architectural design decision of the proposal to have a special
>>>vpiTrvsCollection type.
>
>FM: I think it would be better to have a subtype of collection which can
>indicate what it contains, but keep the general collection as the only vpiType.
>>>There are many variations of functions : vpi_read_load(),
>>>vpi_load_init(), vpi_load_init_create() with no distinct advantage.
>>>[BT] The advantage of multiple methods is flexibility. An application
>>>can chose what is best for it. A complex routine need not be called if I
>>>do not need it.
>
>FM: The functions proposed only accomplish what you can do with a few vpi
>function calls. VPI has been designed to provide building blocks not
>convenience functions.
>[BT] Ok, I will keep only a load_init as we discussed in the meeting. And
>clearly mark that vpi_load/unload are optional when user wants to exercise
>more control.
>>>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.
>>>
>>>[BT] This is incorrect. **Of course!!!!* you load the data when you
>>>cross a specific window!!! The application (in general) need not concern
>>>itself but what's the harm in adding a "loaded" property ? Some
>>>applications may wish to do that ! A collection is good enough and an
>>>app can not concern itself .... and ignore this, some other may wish to
>>>do so. That's the whole point. I think it's just you mis-interpet an
>>>intent to be flexible and give **optimization** hints to actual load
>>>this is NOT the case. This is just an API, the tool needs to have some
>>>smart developers.
>
>FM: It seems to me that the load functions and properties should not be
>part of the mandatory standard. They seem to be added as optional
>functionality. They should be optional.
>[BT] Ok, will say they are optional.
>>>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).
>>>
>>>[BT] Well that's the way the other chapters are: Assertion API/Coverage
>>>API, why they are that way I don't know! Is this not an editorial change ???
>
>FM: They should also be changed.
>>>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.
>>>[BT] Yes your last comment indicates that "user" is more general :-)! It
>>>can be a developer and or designer or anyone using it :-)! Anyway I
>>>think Stu will boil all this down later ... just my 2 cents.
>>>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.
>
>FM: I think that there are things proposed in the specification which are
>not vital to the standard, in particular defining the minimum time of a
>trvscollection etc.. The standard should define the minimum set of API
>functionality to define portability. This again seems like a vendor
>convenience extension function, which can be found by querying the time of
>each member of the collection. It should be removed from the standard.
>>>[BT] explained above ..
>>>
>>>Nothing is specified on what happens if an object has been partially
>>>dumped into the database.
>>>
>>>
>>>
>>>
>>>
>>>[BT] I thought I added this, I think it's in, this is old feedback.
>
>FM: I don't think it is specified. For ex, if you only dumped a bit select
>of a vector, what is happening if you obtain a handle to the vector and
>ask for its trvsObj. What is the trvsObj going to return for the entire
>vector or for the bits which were not probed? How are you going to find
>out which bits were probed?
>For a struct type object, do you get a trvsobj for the entire struct? or
>one for each field? one for each scalar or vector?
>
>
>
>>>Minor issues:
>>>[BT] Thanks for all the edits, The editor (I think that's me) next week
>>>must go through in detail ... except what is relevant to
>>>philosophical/design issues of above ...
>>>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???
>>>
>>>[BT] Covered above...
>>>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.
>>>[BT] Hmmm, this was my opinion all along (and the diagrams too!),
>>>previous feedback suggested to do the list of things (which I might add
>>>is not what other chapters e.g. assertion/coverage have done...).
>
>FM: sorry if I had given you this feedback, I am not sure now what is the
>best way to document this and be synchronized with the current VPI spec.
>>>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.
>>>
>>>[BT] No precedent in Verilog yes, but in SV we did this in assertion
>>>chapter !
>>>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().
>>>
>>>[BT] Nope vpi_get_time cannot be used without significant backward
>>>compatability issues.
>
>FM: You had claimed this before but I don't see any backward compatibility
>issue. Please describe.
>>>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.
>>>
>>>[BT] ....
>>>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.
>>>
>>>[BT] ....
>>>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?
>>>
>>>[BT] ...
>>>
>>>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
>>>
>>>[BT] Yes, but what's the harm ?
>
>FM: It is redundant and complicated the interface implementation.
>>>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".
>>>
>>>[BT] There is no explicit load, this is just a hint ...
>
>FM: Just accessing the handles should be the hint.
>>>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?
>>>[BT] No ... what if you are loading a "window-ed" in time ... I think it
>>>is better to let apps be smart about this.
>
>FM: ok
>>>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)
>>>
>>>[BT] ok ...
>>>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.
>>>
>>>[BT] above ...
>>>The vpi_goto() is unnecessary it can be replaced with the combination of
>>>vpi_control() and vpi_filter() with a criteria of vpiHasVC.
>>>
>>>[BT] above ...
>>>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.
>>>
>>>[BT] ....
>>>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.
>>>
>>>[BT] Also agree... a lot of this is implementation dependent, yes! We
>>>only need to focus on the read API portion ...
>>>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().
>>>
>>>[BT] "Try" is relatively speaking a construct in programming (as in
>>>try/fail) ... request is not.
>>>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().
>>>
>>>
>>>
>>>
>>>
>>>[BT]...
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
This archive was generated by hypermail 2b28 : Tue Jan 13 2004 - 13:04:46 PST