Subject: Re: [sv-cc] Calling Verilog tasks from C and disable behaviour
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Oct 29 2003 - 07:19:43 PST
Francoise,
A couple of comments embedded.
Francoise Martinolle wrote:
> We had a discussion internally at Cadence about the proposed disable
> functionality when applied to Verilog tasks called from C.
>
> We think that depending on the user to write his C code properly to handle
> a disable is not the best way to do this. Today the disabling is handled
> totally on the simulator side and should continue to be that way.
> There are existing mechanisms in C and C++ to handle exceptions and these
johnS:
Careful here. While there is sophisticated exception handling support for C++,
the only existing "mechanism" for exception handling is C is the arcane
function return status code and that is only a de-facto convention. And one
can argue that Doug's solution in fact uses that convention. Whatever
solution we come up with has to scale to both C and C++. That is one
of the fundamental requirements of the DPI.
> should be used instead of relying on a usage protocol. Moreover the
> protocol solution proposed does not cover Verilog functions which makes it
> an incomplete solution. In the proposed solution the simulator must also
> detect a non compliant usage, this will require extra checking from the
> simulator side and involve performance degradation. Verilog simulators
> should carefully consider new features which create any impact on
> performance.
>
> What we would prefer would be that the disabling behaviour is implemented
> *on the simulator calling side* with setjump longjump if C code is used. If
johnS:
Ouch ! In the past I've seen setjump/longjump deployed as a poor man's
implementation of catch/throw in a C environment. It has a number of
problems of its own the most pronounced of which is not giving intermediate
calls in the chain opportunities to clean up after themselves. Doug's
solution explicitly allows for this.
> the user programs in C++, the mechanism is already implemented in the C++
> compiler with the throw/catch exception. In that particular case, the user
> C++ code which catches the disable exception can do the necessary cleanup.
> The unwinding of the stack is performed automatically.
johnS:
We cannot necessarily rely on the infrastructure knowing when it can
and cannot use exception throwing. It will depend largely on how the
user builds the C/C++ application. I see some fundamental issues in
defining a way of throwing an exception from the infrastructure that
is caught in the application. You have to define exception classes
as part of the standard with very explicit instructions of how to
catch them and what to do with them. The DPI should not delve into
C++ specific use models but rather should keep itself C/C++ neutral
as it does now.
>
> A similar problem exists with mixed SystemC / Verilog design. SystemC can
> call a Verilog task or function and the latter can call another System C
> method. An SC_thread is created when calling a Verilog task and catch/throw
> exceptions are used to handle disable behaviour. Why would'nt the same be
> implemented when Verilog calls C or C++ code?
johnS:
I think the fundamental assumption in SV-CC has been that the Verilog
exported task will be called from the same HDL thread that called the
imported task to begin with. In this case, there should be no need to
create a SystemC SC_THREAD, dynamic, static, or otherwise.
However, there is another use model that we've also seen where exported
tasks are called directly from user defined SystemC SC_THREADS. In this
case the thread can simply block until the task returns and then go
about its way with proper handling of the disable status. Again, I see
no reason for creation of a new thread on the SystemC side when the task
is called.
> We would like to reopen this discussion today. Stuart Swan will participate
> to the conference call today if that is debated.
>
> Francoise
> '
-- johnS
/\
/\ | \
| \ / |
/ \ \
/\_/ K2 \_ \_
______________________________/\/ \ \
John Stickley \ \ \
Principal Engineer \ \________________
Mentor Graphics - MED \_
17 E. Cedar Place \ john_stickley@mentor.com
Ramsey, NJ 07446 \ Phone: (201) 818-2585
________________________________________________________________
This archive was generated by hypermail 2b28 : Wed Oct 29 2003 - 07:27:12 PST