Subject: [sv-cc] Calling Verilog tasks from C and disable behaviour
From: Francoise Martinolle (fm@cadence.com)
Date: Wed Oct 29 2003 - 06:54:55 PST
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
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
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.
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?
We would like to reopen this discussion today. Stuart Swan will participate
to the conference call today if that is debated.
Francoise
'
This archive was generated by hypermail 2b28 : Wed Oct 29 2003 - 06:56:24 PST