Subject: Meeting minutes from November 26
From: Francoise Martinolle (fm@cadence.com)
Date: Mon Dec 02 2002 - 11:19:41 PST
Meeting minutes for Tuesday November 26th.
attendees:
Stuart Swan, Francoise martinolle, Michael
Swapnajit, Bassam, Doug, John, Kevin, Joao, Andrzej, Ghassam,
Kurt, Joe Daniels
I am not sure if John Amouroux was present...
approval of the meeting minutes:
Doug approved, Bassam seconds
issue 1.6 :
Joao and John proposal for discussion
John summarized the main points of the proposal and the recent changes:
Based on some recent discussion, we propose adding an aliasing capability
to alias
a SV function to a C function.
For passing context, use existing function in VPI or tf interface. no new
API function.
Does require static binding of names.
Francoise: What is the difference with creating a function in PLI
Joao: main difference is accessing the parameters directly.
Francoise: abstracts type access interface should be the vpi interface
rather than inventing a new API
Joao: 2 inelegances: providing context in other direction, ability of
migrating pli functionality
to use direct C (only access to arguments). -> ability of using PLI within
a direct C call
?: require some a set of API, existing also with PLI, let's make it all PLI
John: agree
Kevin: no time to reinvent stuff
joao: yes agree use VPI to deal with abstract data types, complex types
joe daniels: agree to limit the scope to Andrzej proposal
Today impossible to call non free function
Stuart: modeling situation can be turned around with just SV call C
Kevin: accessing complex data types is an problem
Stuart: fairly simple proposal for simple data type, C cannot block, not
full fledge
solution to call SV and C++
Doug? until the face to face
Ghassam:
Swapnajit: we don't need to decide on this issue right now.
Andrezj: no blocking on either proposal
John: C to SV, the context interface is simpler: get the module context
Discussion of Kevin proposal of virtual functions
joao: can you use the pointer?
kevin: not creating pointers
pointer to fill needs to be allocated somewhere
andrzej: pass a struct as an inout argument
joao: define the buffer as an inout to read
kevin: table this
kevin: a structure as a context: union with the context and line number
information
in C++, not easy what to do this in the linker, in C++ you are overloading
the function
John: restrict to C linkage, avoid the need for the locator and symbol search
Joao: code has to be located at the beginning of simulation before code is
executed
one indirection needed
Kevin the context include a pointer in the user context field
K: 2 problems the locator does the work at elaboration time
Joao: no elaboration static , all code already exists after elaboration
Joao:is there any performance deficiency between kevin and john's proposals?
Michael: very first call of user defined task,
K: The locator does the context set up at elaboration time
Joao: static elaboration happens before main, the environment is not up yet.
K: if you have a C++ simultor, calls and registers the user function
J: no C++ linkage should be needed.
K: svlocator does not require a C++ function
J: C linker will not link correctly
M: Static initializer in those classes
Swapnajit: continue discussing off line
K: C++ linker can also check that the argument match which you cannot do
with C linker
The ansi C compiler does not tell you that the arguments don't match at the
call
J: we cannot suppot support C++ mangling
M: Please write up the major benefits of your proposal, is it worth doing this
John: you are adding a dynamic linking capability
Swap: Kevin to send the email requested by Michael
M: contain line number and filename: is these any extra acc set up needed
for this function?
Issue: 1.10: external modules
Friday the 15: external models idea
Doug: extern C module, may take away the extern and C keyword
The foreign attribute may be enough.
commonality with extern task and functions
If you get rid of the foreign attribute: cannot put instance specific bindings
Doug: specific implementation could define their own attributes
we don't need the foreign attribute only implementation specific, naming a
shared object
entry point
Swap: make correction and send it again
Doug: only ports and parameters are interpreted by SV, nothing else ( no
declarations
or behaviour)
K: some other things may need to be interpreted
D: too complex
A: is the external module a black box?
D: yes, must be like in VHDL
K: in analog you may want to declare the temperature and make it known to
the external
without it being a port or parameter we need to be able to do this in the
future.
Face to face: confirmation
December 3 rd
This archive was generated by hypermail 2b28 : Mon Dec 02 2002 - 11:20:06 PST