RE:[sv-cc] Example header file for discussion today

Hi all,
I confess I do not fully understand how the 'blue' function tray option
works, however it rather looks like a switching out of all functions as
a run-time option, which I don't think is quite what we want, since the
run-time tool can't easily do this on a per-library basis. I prefer the
symbol-replacement at compile time within the user application, which I
think is the 'green' option.

I have some more comments:
1. Let's get practical and declare 1995 not explicitly supported as
different from 2001. No tool supplier is interested in writing this!

2. There's a long list of VPI routines, but quite a few of them should
have *no* differences between versions except passively, if they are
passed an inappropriate handle. I think that it might make sense to only
switch those routines that have an *active* difference between versions.


In fact, I don't think there is a reason to have the list of
differentiated routines the same for every different version (it just
proliferates symbols). I think there is an advantage to not
differentiating wherever possible, which is that it is more likely to
keep the tools consistent, because it reduces the number of different
cases. Once the list is finalized, all tool developers can then not
worry about differentiating within non-differentiated routines.

My list for the routines that absolutely have to be differentiated would
be:
First, any routine that returns a handle WOULD NEVER return a handle to
an object not understood in its compatbility:
 vpi_scan
 vpi_iterate
 vpi_handle
 vpi_handle_by_name
 vpi_handle_by_index
 vpi_handle_by_multi_index

Also I think the property routines have to be differentiated, because of
the "sometimes it's one type, sometimes it's another" problem.
 vpi_get
 vpi_get_str

The registration routines might need to be differentiated, though when a
callback completes I don't know if there is anything about it that
requires knowledge of the compatibility (getting value is not currently
differentiated as far as I can tell, and when the user routine is
entered, it may call other VPI routines, but they themselves carry the
differentiation).
 vpi_register_systf
 vpi_register_cb

Routines that don't look to me that they need differentiating.
I don't see why we have to differentiate the printing routines:
 vpi_mcd_*
Or the user data routines
 vpi_get_userdata
 vpi_put_userdata

Delays haven't changed, have they?
 vpi_get_delays
 vpi_put_delays

Values have added the 2-state stuff, *but*, if you can't get a handle to
an SV variable in the first place, you would never be able to send it to
vpi_get_value, would you?
 vpi_get_value
 vpi_put_value

The rest of the list might be negotiable, I haven't thought through
every single one. First we have to decide if we are OK with
mix-and-match differentiation, or we think the blanket 'hit them all'
approach is safer. There's a fair amount of work getting the
differentiation list correct, but I see a lot of advantages to having a
short, common list. Apart from anything else, the implementers are going
to develop these lists independently anyway, for all the common cases,
so we might as well standardize them. On the other hand, there may be
implementation issues that are different for each tool, I'm not sure.

3. Michael has used the #define constant VPI_USER_VERSION. Is this a
good name? The concept we are trying to convey is that we will switch
the tool behavior to be compatible with a particular VPI Object Model
version. I'd probably go for something longer and more explanatory such
as VPI_VERSION_COMPATIBILITY_REQUESTED (yes, it's horrible, but less
chance of name collisions, plus more precisely targeted googling or
other search tools!). I don't feel particularly strongly about this, the
concept needs an essay to fully describe it anyway.

Abi

-----Original Message-----
From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org] On
Behalf Of Michael Rohleder
Sent: Wednesday, October 25, 2006 5:43 AM
To: sv-cc@server.eda-stds.org
Cc: Michael.Rohleder@freescale.com
Subject: [POSSIBLE VIRUS:###] [sv-cc] Example header file for discussion
today
Importance: High

Hi all,

here is the example vip_user.h file as discussed last week. It includes
two possible implementations, one in green and one in blue. Never
compiled, never checked for syntax errors, etc. This was the best I
could do in this short time.

Best regards,
-Michael