[sv-cc] Meeting minutes for 4/30/2007

Attendees:
Rohit Rana
Abi
Gord Vreugdenhil
Francoise
Chas
Chuck
Jim
Andrzej
Steve Dovich
Bassam

1. The correlation between the vpi model and the simulation state - A general overview discussion

Used to be that the world was static from a VPI perspective.
That is no longer true.  If you say, that the VPI state accurately (complete and correct)
reflects the state of the simulation, then you have set a high bar.
The VPI specification cannot dictate the kind of garbage collection
that is done.  It is obvious that VPI was intended to be able to
modify the state of the simulation (via vpi_put_value() for example).
What if VPI puts NULL to a class variable.  What happens?  Gord thinks
that it should be allowed and you get whatever happens.  The question
is "Does VPI reference to an object count?".  Maybe we should make a
way that VPI could explicitly say that it wants to be a reference to
an object.  Another reasonable solution would be to make the time when
VPI has control to be an illegal time for doing garbage collection.
If we allow putting values to dynamic objects then we have to specify
who is responsible for the effects of doing so.  Restricting only the
changing of class variables?

Should we consider giving up on VPI?  Maybe create a PLI 3.0?

Choices are:
   1. We protect the app from itself.  Whenever VPI touches a class
      variable, we keep it.  VPI is a first class client of the sim.
   2. We allow the user to ask if it is still around: vpiValid.
   3. The application tells us that they want a reference to an obj.
   4. Your on your own.

We should have a section of the specification that describes all
situations where there may be side effects.

Gord would be in favor of having the application have a means for
specifying that it would like to be a first class reference to an
object.

Discussed the possibility of permitting an application to ask for
a persistent handle to a class object.
Maybe we need a status return indicating whether or not the simulator
permitted a persistent reference.  We could make vpiValid TRUE if the
application has asked for a specific reference, or if it is a static
object.  If it is dynamic and they haven't asked for a persistent
reference, then it should return FALSE.

Associative array and put value?

initial begin
   aa[15] = 5;
end

What if we are at time zero, and aa[15] doesn't exist yet, and the
application gets a handle to that object then tries to put a value
to it?  Should it be allowed to change the size of aa?

Can you do get value on a "new" call?  Everyone agreed that the
answer should be NO.  Abi thinks that we should not allow anything
that would cause a object to come into existence.  If an application
did a put value to a function call and that caused a size change for
a dynamic object, then that would be undefined.

A variable can have 3 different flavors (incarnations?):
   - Parsed (analyzed) object - it exists in the HDL
   - Instantiated object - has been elaborated, but it hasn't been
     caused to come into existence by simulation yet.
   - Instantiated and allocated and exist - there is a temporal aspect
     to them, is an active simulation object

Proposal:
   Create a routine that given a handle to an object which is dynamic
   could ask the simulator to make the object persistent.  All the
   necessary infrastructure would also need to be created, such as
   the means to give up the persistence, and a way to have the simulator
   tell the application, no it can't make it persistent.  vpi_free_object()
   frees the handle to the object, not the object itself.  It must
   be explicitly make non-persistent.  Could create an iteration from
   NULL to persistent objects, to get a handle to them again.

Discussion on vpiValid flag.

For static objects, vpiValid flag is always TRUE
For dynamic objects, vpiValid flag is TRUE if the object is known to exist
For dynamic objects, vpiValid flag may return vpiUnknown if the implementation
   is not sure.
For dynamic objects, vpiValid flag will return FALSE if the object is known
to have been garbage collected.

Gord says that the vpiUnknown state is useless because the application must
treat it as a FALSE.  Chas points out that they are not the same because
it is possible that if the application attempts to get the handle again, it
may be successful, while a FALSE will always fail.

If the application says make persistent, then vpiValid should always be
TRUE.  It is permissible for something to become invalid, but not a requirement
when the simulation regains control.  Chas is concerned about how much
difficulty there will be in defining the cases where the validity of an
object can be modified.  When you say that a class object is to persist,
it does not imply that the path to that object must stay in existence
as well.

Jim's Proposal:
  if static or vpiPersist => always vpiValid is vpiValidTrue
  for class obj or data member of class obj
    vpiValid == vpiValidTrue => object still exists at time of check
  vpiValid == vpiValidFalse => object has gone away
  vpiValid == vpiValidUnknown => vpiHandle no longer useful

Might be useful to have a callback that occurs when only reference to
and object is a persistence specified by VPI.

Gord would like to get as close to possible to the overhead needed is
proportional to the amount of information that the applications is
tracking.

Gord would like to get rid of the
  vpiValid == vpiValidFalse => object has gone away
predicate.  This simplifies the problem, in Gord's opinion.

All non-persistent handles would no longer be valid after control
has been returned to the simulator.

Jim think we must allow for the ability to tell to the application
that an object has gone away.  Can possibly combine with vpiPersist
so that it is on demand.  Explicitly say that the application wants
to know when an object goes away.  zombie!  We can make class objects
that are not referenced in the HDL but have a vpiPersistent flag
set, then setting a class variable to this class object makes the
class object alive again.

             |  persist         not persist
------------------------------------------
vpiValid    |  Required        SV obj is accessible via vpiHandle
vpiUnknown  |  Not possible    SV obj make exist but is not accessible via vpiHandle
vpiInvalid  |  Obj is only     never
             |  VPI accessible

Jim pointed out that there is another whole part of vpiValid that
still needs to be discussed.  Handling references to members of
dynamically allocated arrays.  VPI is another way of creating an
outdated reference.

Names

What if we have two different cases of the same name within
two compilation units.  For example, two unnamed blocks that
have a variable with the same name.  Currently they do not
have an authoritative name now.  Should they?  Gord thinks yes.
If they should, then how would you name them?

Gord suggests that we have a statement to the effect:

   The tools shall provide a mechanism external to the HDL that
   provides a means for mapping a name.

A compilation mapping file, if you will.  Probably means that
an implementation might have to produce this name mapping file
that could then be used by some downstream tool.




-- 
Charles Dawson
Senior Engineering Manager
NC-Verilog Team
Cadence Design Systems, Inc.
270 Billerica Road
Chelmsford, MA  01824
(978) 262 - 6273
chas@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.