Subject: [sv-cc] Meeting minutes for Mar. 12, 2003
From: Amouroux, John (john_amouroux@mentorg.com)
Date: Wed Mar 12 2003 - 15:25:32 PST
SV-CC Meeting Minutes, for Mar. 12, 2003:
Agenda::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
- Procedural work [Swapnajit, 5 minutes]
- SV representation of data - unpacked array
[Andrzej, 20 minutes]
- Extern/export [Joao, 10 mins]
Team, as I said in my other mail, let us try
to close the remaining issues before we send
the proposal to SV-EC.
- Any other topic that you would like to
bring up before our proposed technology freeze
date (03/14).
General::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Minutes proposed for approval by Andrzej and seconded by Michael.
Vasillios wants us to do a "technology freeze" by the end of this week.
Andrzej's dilemma:::::::::::::::::::::::::::::::::::::::::::::::::::
Andrzej's dilemma is about the representation of unpacked arrays of packed
types.
He just sent a reply to the reflector (html #1009). Without resolving this
issue, access to these types cannot be allowed. He has proposed what he
calls an imperfect solution, and is hoping a better solution can be found.
John S. thinks that this may be the best we can do.
On a side note, Michael wants the LRM to explicitly state that only the enum
values are passed between functions, not the names.
John S. suggests that if we only use access functions, we can safely access
this data. Andrzej says that this won't help.
Michael asks if these restrictions and/or their work-arounds will create any
source code compatibility. The consensus of the group is an inconclusive
no.
John S. thinks that only single-dimensioned bit vectors will actually most
often be used, so if we just solve this issue we may have done enough.
Doug suggests that any function declared for export could have a specially
manipulated layout to keep it C compatible, even if called from SV.
Michael again asserts that he is concerned about source compatibility.
Because he has to support so many different tools/flows, source
incompatibility will be very troublesome.
Andrzej reiterates that C-compatible types have no problems. He also sees
no source code compatibility issues. But Joao says there is a small hole
when passing complex (open?) arrays directly. [I didn't catch the rest of
this.]
Michael suggests that we place a restriction that open arrays only be passed
as stand-alone parameters, not embedded in anything else. Andrzej's
counter-restriction is that if open arrays are to be passed, they must have
a C layout, and still let them be anywhere.
Francoise asks if we can introduce a temp variable (in a wrapper), where we
would on-the-fly translate data from one representation to another. [This
seems similar to Doug's suggestion previously.] Andrzej thinks that this
would be too inefficient (i.e. slow). John S. thinks that users would learn
that this is slow, but could still use it anyway until they optimize their
code. Andrzej doesn't want users even to be able to fall into this slowness
trap.
The final comment from Andrzej is that he is simply trying to protect the
vendors implementing this solution.
This issue is still open, to be resolved over email if possible.
Joao's modified proposal::::::::::::::::::::::::::::::::::::::::::::::
Joao sent out his proposal to the reflector (#1003). All his changes are in
blue. [Joao then proceeds on a tirade against OutLook due to numerous
crashes he experienced, and John S. informs him that it should really be
called LookOut!]
Joao notes that just allowing multiple declarations of functions is not good
enough. Sharing functions means that data types are typically being shared
too, and multiple definitions of data types are not allowed in either C or
SV.
Doug also doesn't want to allow multiple decls because he doesn't want to
promote what he sees as unhealthy design habits.
John wants Joao to specify that an exported SV function cannot be called by
a C function at elaboration time.
Joao will update his pure definition in the doc - will take his definition
from the LRM text already existing.
Francoise asks about who allocates these scope handles. Joao says that
scope handles belong/are allocated by the simulator. Francoise asks if
these handles remain valid after a restore? Joao says yes. But this may be
simulator dependent. Similar restore issues may be present with the user
data pointer.
Doug asks how unrelated functions can share the same user data space since
there is only one per scope. He wants us to define a way for us to be "good
citizens" - (i.e. supply some good examples on how this should be done).
Doug emphatically wants this to be in the 3.1 LRM.
Michael wants caller file and line number info available. Joao forgot to
put this in, but will add it.
Doug wants svPutUserData instead of Set. He also suggests getScopeFromName
and getNameFromScope.
Michael asks what an svScope is. Joao says it is an opaque structure.
Doug suggests svArrayHandle instead of svHandle, to be less generic.
Francoise doesn't want svSetScope to return the current scope, as the user
may not want it. Andrzej says that this is for efficiency, so that two
calls are not necessary. [Final decision not noted.]
Some svHandle appeareances in Joao's doc are typo's - these should be
svScope's.
Closing::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Roll call.
Francoise Martinole
John Amouroux
Doug Warmke
Michael Rohleder
Kevin Cameron
Swapnajit Mittra
Joao Geada
Ghassan Khoory
Andrzej Litwiniuk
This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 15:27:10 PST