[sv-cc] New paired proposal for 526

I have uploaded a new proposal in two parts for 526.

The scope of this proposal is very limited.  It became clear from even 
our local discussions that getting everyone to agree on a more detailed 
set of rules would be hopeless in the time we have left.

The main aim of this proposal is to establish that the intent of the 
vpiValid property.  The intent is to let the VPI application know when 
it can access related information belonging to the handle without 
having to check for an error message such as "Handle is no longer 
valid."

Because some of us have been concerned over whether or not an 
implementation can always tell whether a handle is still valid, I have 
proposed changing the vpiValid property from a bool to an int, with a 
new value vpiUnknown that the implementation can return when it doesn't 
know.

Changing vpiValid to an int property requires changing 1364 as well, so 
I a proposal for 1364 in addition to the proposal for 1800.

In order to start conforming to IEEE rules, I have taken the risk of 
putting the new paragraphs in as normal text rather than as a NOTE.  
That may be dangerous, since IEEE could demand that we clean up the 
rest of our notes as well.  So we can change these two paragraphs into 
NOTEs if you all think it's wiser.

From the questions we've heard so far, it seems helpful to make the 
following points:

-- A handle can continue to exist even when the associated variable 
does not.  Two reasons for this are:

   o  VPI, as currently set up, lets applications hang on to handles 
indefinitely.  An alternative, of course, is to require an application 
to reacquire dynamic handles every time it regains control.  This could 
make sense for automatic variables, but with classes one can now have 
linked lists with an indefinite number of volatile links.  (And 
strictly speaking, an implementation can still, under this proposal, 
force the application to reacquire the handles every time.)

   o  In some VPI implementations, multiple applications can reference 
the same handle.  No one application will have enough information to 
free the invalid handle.  So the handle may continue to exist 
indefinitely.

-- As a result, this proposal says nothing about how to let an 
application free invalid handles.  (No other current proposal does 
either.)  That would be a good thing to do, but it should be handled 
independently.

-- For efficiency, callbacks could indicate when the HDL no longer 
accesses a dynamically allocated object.  So an application could set 
callbacks instead of polling.  We agree that this would be useful, but 
I have omitted it from this proposal because (a) we have not yet agreed 
on what callbacks are needed, and (b) it can be handled as a separate 
proposal in the future.

-- A VPI handle does not constitute a reference to a dynamically 
allocated object for the purpose of reclaiming unused memory (12.26).  
A separate Mantis item 538 on this is so far unresolved.  If a VPI 
handle did constitute such a reference, then an application would have 
a deadlock in which, because of the existence of its reference, they 
could not determine when a handle is unused, and hence could never free 
the VPI handle -- and therefore the simulator could never free the 
dynamically allocated memory.

-- In order to keep the proposal limited, I have left the terms "static 
handle" and "execution control" undefined.  But with that, there is an 
underlying assumption that the application developer understands the 
transfer of control between the application and the simulator.  
Transfers of control can occur via callbacks, via DPI, via system tasks 
or functions, or by returning from any of the same.  There may be 
others, but I want to leave further definition, if necessary, to the 
interpretations committee so that we don't discuss it indefinitely 
ourselves.

-- The proposal also says nothing about "outdated" references (Thanks, 
Dave R., for the pointer to 11.4.2).  All it talks about is whether or 
not the application can still access information about the handle.  
That applies independently of what the handle represents.

-- There also seems to be some confusion about whether or not a dynamic 
array can be a static variable.  Yes, it can.  The elements of the 
dynamic array can come and go and be replaced, but the dynamic array 
itself can be either static, automatic, or a non-static data member.  
The same holds true for associative arrays, queues, or a variable 
declared with a type that is a class name.  vpiValid is not about 
whether the values and properties (including vpiSize) of a variable can 
change, but only whether the application can still interrogate the 
handle's properties, values, and relationships without reacquiring the 
handle.

Regards, 
Jim Vellenga


--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Engineering Director                   (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd 
Chelmsford, MA 01824-4179 
"We all work with partial information." 
----------------------------------------------------------