Re: [sv-cc] Calling Verilog tasks from C and disable behaviour

Subject: Re: [sv-cc] Calling Verilog tasks from C and disable behaviour
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Oct 29 2003 - 07:36:43 PST

• Next message: Duncan, Ralph: "[sv-cc] Minutes for 10/29/03 SV-CC Meeting"
• Previous message: David W. Smith: "[sv-cc] SystemVerilog 3.1a Draft 1"
• In reply to: Francoise Martinolle: "[sv-cc] Calling Verilog tasks from C and disable behaviour"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Francoise,

thanks a lot for this input. I just doubt I really understand what you mean.

a) Yes, C++ expections would be a nice and elegant way to implement something like this. BUT DPI is a C interface for good reasons
and you would also have to rely on the user to properly handle a C++ exception. I have not seen many people that are doing this. So
we would have STILL to rely on the user to properly handle a disable.
b) I don't see how you want to solve the user notification problem of a DPI function with a setjump/longjmp. Of course the simulator
can make sure everything on his side, but this would not help the user with cleanup activities/notification within the DPI
function/task. And there is no other, standardized exception mechanism at all within C.

Best regards,
-Michael

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
> 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
> '

--
NOTE: The content of this message may contain personal views
      which are not neccessarily the views of Motorola, unless specifically stated.
         ___________________________________________________
        |                                                   |
      _ | Michael Rohleder            Tel: +49-89-92103-259 | _
     / )| Software Technologist       Fax: +49-89-92103-680 |( \
    / / | Motorola, Semiconductor Products, System Design   | \ \
  _( (_ |  _   Schatzbogen 7, D-81829 Munich, Germany    _  | _) )_
 (((\ \>|_/ >                                           < \_|</ /)))
 (\\\\ \_/ /    mailto:Michael.Rohleder@motorola.com     \ \_/ ////)
  \       /_______________________________________________\       /
   \    _/                                                 \_    /
   /   /                                                     \   \
The information contained in this email has been classified as:
Motorola General Business Information (x)
Motorola Internal Use Only            ( )
Motorola Confidential Proprietary     ( )
*** This note may contain Motorola Confidential Proprietary or
    Motorola Internal Use Only Information and is intended to be
    reviewed by only the individual or organization named above.
    If you are not the intended recipient or an authorized representative
    of the intended recipient, you are hereby notified that any review,
    dissemination or copying of this email and its attachments, if any,
    or the information contained herein is prohibited. If you have received
    this email in error, please immediately notify the sender by
    return email and delete this email from your system.
    Thank you! ***

• text/x-vcard attachment: Card for Michael Rohleder

• Next message: Duncan, Ralph: "[sv-cc] Minutes for 10/29/03 SV-CC Meeting"
• Previous message: David W. Smith: "[sv-cc] SystemVerilog 3.1a Draft 1"
• In reply to: Francoise Martinolle: "[sv-cc] Calling Verilog tasks from C and disable behaviour"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b28 : Wed Oct 29 2003 - 21:57:52 PST