Subject: [sv-cc] Minutes for 10/15/03 SV-CC Meeting
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Oct 15 2003 - 10:59:43 PDT
*** SV-CC Minutes, Oct 15, 2003 ***
Attendees:
Andrzej
Joao
Michael
Doug
Swapnajit
Bassam
Glenn
Francoise
Ralph
John Stickley
Abhinash
Ralph proposes accepting last meeting's minutes.
Motion seconded by someone (Joao?) and passed unanimously.
*** Novas VCD donation
Joao: Intent here is that VCD is not very efficient,
and it's hard to agree on a common format for dumping.
API should be much easier to agree on. If all vendors
provide a library implementing the API to read their files.
The write-side would remain internal to simulators
and not come into play in this standards effort.
Michael: This would enable on-the-fly waveform viewing.
It will also provide performance benefit.
Abhinash: For post-process debugging, we would still be
dumping to the file, correct?
Bassam: It doesn't really matter. The simulators dump
a proprietary file format during simulation, then provide
a read API in library form for post-process readers.
The read API is also built into the simulators.
Doug: I thought this was an on-the-fly API? Am I wrong?
Bassam: This can replace a waveform viewer's API.
It can support both on-the-fly (interactive) as well
as post-process debug.
Doug: How does interactive mode work? Does simulator
run along, populating its internal database, then at
interactive time, the 3rd party wave viewer is notified
and goes to query data to fill its database?
Joao: Yes it is basically like this. Note that this API
is present both within the simulator, as well as in library
form for post-process mode.
Bassam: This is quite like normal VPI value query, but with
the extension that you can query objects at different time
points.
Doug, Joao: We need some version control info in the file
to coordinate it with the proper library and simulator version.
i.e. we have to make sure that if simulator X produces a file,
and simulator Y's API is called upon to read the file, a
proper error is present.
Doug: I would like to see some example apps using this
donation, similar to what John Stickley did earlier to
illustrate the use of context import functions working
together with export functions.
Swapnajit: Bassam will resubmit this in LRM form, too.
*** DPI call chain disable problem ***
Michael: Thinking about safe way to handle disables, meeting
basic usability and safety requirements (user resource cleanup).
Go back to Doug's taskA, taskB, taskC example from earlier
email archives. (taskA nearest to bottom of stack by initial block).
taskA is disabled. taskC returns a 1 to indicate disable event
received. And doesn't care too much about mechanics of having
user confirm they properly handled the disable event. Michael
is more concerned about what happens during incorrect user
handling of disable events during import tasks. i.e. user
calls some further exported SV function or task after a
disable event was received.
Doug: Just call this an error
Michael: But what about cleanup code that calls PLI/VPI,
or DPI functions? I would require that the DPI import task
or function has to immediately acknowledge that disable
is received, and "the task knows what it's doing".
Doug: I don't see any functional difference in the
proposals by Doug and Michael to get the user
acknowledging a disable event.
Ralph: Michael's notifies the simulator earlier.
This might be advantageous in some cases.
Joao: Main problem is handling disables detected
within exported functions.
Some: This comes up as soon as import tasks are
introduced. (NOTE: This statement was later
proved incorrect by Francoise)
Joao: My preference is that we have a complete
solution. We should be able to actually disable
C code. How do we handle the cleanup mechanism?
Context should be useful. User can register a
cleanup function that is called as a callback,
using the context pointer. Since we own the
stack, we can just blow away the user's C code.
This way we don't have to trust the user to
do their part of this disable event.
Andrzej: We are talking about exception handling
in C code. Isn't this going to far? The cleanup
mechanism might need to be more robust for C.
Doug: A callback is too complicated for users.
Further, control has to return to the C side
in order for the C or C++ runtime system to
do cleanup in all its supported ways.
(i.e. use of automatic class variables on
stack with destructors used for cleanup)
Michael: The callback couldn't look into the
local variables of a C function.
Joao: But the C function and its variables wouldn't
be there any more.
Michael: But my function might contain local variables.
And those might be key to my cleanup efforts.
Joao: This cleanup issue is also present in native
Verilog disable activity.
Doug: But Verilog is a language "kinder" with regard
to resource leaks than C.
Francoise: I don't think you can stop the C code from running.
Michael: Doug has provided a detailed overview of all the
possibilities that can happen.
Doug: My suggestion to handle Joao's problem with exported
functions initiating a disable event is to make that illegal.
It is limited in scope and I think it will be acceptable to users.
Michael: Would like written examples of the use cases
in order to better understand.
Francoise: This problem does actually exist today in SV 3.1,
since an exported function can disable another function.
The lower level function can disable a higher level function
up the chain, and the same control issues exist.
Joao: Not quite sure about this. Is a function a named block?
However, an export function can disable a SV task way up the chain.
So you are right, the problem does exist right now.
John: Would like to disallow exported functions from
doing disables on things higher up the call chain.
Joao: Three choices:
1) Automatically disable all C code side. Cleanup issues persist.
2) Totally disallow disables of call chains containing C code.
3) Doug's protocol proposal. Requires user interaction.
Joao: Disables are used as "structured gotos".
This is important functionality.
Doug: True, but mostly for functions disabling themselves.
Not disable of blocks far up an interlanguage call chain.
I stand by the proposal to disallow exported functions from
disabling blocks higher up the call chain.
Francoise: Do new SV 3.1a features reduce the need to use
disables on high level task calls?
Joao: Probably, but the new features such as processes will
have the same basic issues.
Doug: An important use model of disable is to have some high
level testbench process call a "disable" on a complex TB task.
Clint: Could we just leave this ambiguous?
Several: No, not good for the standard.
Joao: Note that TestBuilder has this same issue,
and does leave it ambiguous.
Francoise: We do need to study interaction of processes and
other new constructs interacting with DPI call chains.
This could be an issue even for 3.1 DPI.
Joao: As per the automatically disabled approach,
it's easy to kill off a C section of the stack.
Doug: Disagree - that assumes a coroutine/thread implementation
on the C side. If an implementation uses the native stack,
it's not easy to unwind it robustly on all platforms.
Swapnajit: Meeting over.
Asks Joao, Michael, Francoise to do some caucusing among their
teams and come up with some examples and counter-proposals that
we can compare, pro and con, with Doug's proposal.
10:02am PDT - Meeting adjourned.
This archive was generated by hypermail 2b28 : Wed Oct 15 2003 - 11:03:26 PDT