Re: DirectC memory ownership - proposed rules

Subject: Re: DirectC memory ownership - proposed rules
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Mon Dec 16 2002 - 11:40:46 PST

Joao,

thanks a lot for this clarification. Please make sure this information also finds its way into the C Layer definition. Especially
the lifetime statements are essential and exactly what I have requested to define.
Just twos comments on this:
a) Your definitions on the output ports prohibit the usage of the heap for building the strings. Otherwise the allocated memory
would be leaked (or you need to do some clumsy things), since it must live when terminating the function and can thus not be freed'
by it. Since it is furthermore not possible to use strings allocated on the stack (for obvious reasons), the only possible/permitted
(C) variables are globals or const strings (or some tricks with the heap). Not the most elegant solution, but of course working.
b) i: Your definitions of the inout port cries for 'const' [without going into the whole discussion again] to aid in asserting the
read-only attribute. ii: I would request a 'do' and a 'don't' example for this case, to make the restriction even more clear.

Thanks again,
-Michael

Joao Geada wrote:

>
> In general the rule is very simple: C code owns all the memory it creates,
> SystemVerilog owns all its own memory.
>
> Details:
>
> strings:
> on input ports:
> Verilog owns and manages the string (char*). Users C code can read
> the string but must not maintain a reference to this reference as the
> validity of the pointer is not guaranteed beyond the end of this DirecC
> call
>
>
> on output ports:
> Verilog passes a reference to a NULL pointer. User code is expected
> to change this reference to a pointer to a valid string (or leave the
> reference alone if no output string is to be passed to Verilog).
> C code owns any memory it may allocate to represent this string.
> SystemVerilog will copy this string out (if non-NULL) on exit of the
> DirectC function. SystemVerilog must not make any assumptions about the
> validity of this pointer across any other DirectC calls. SystemVerilog
> must never make any changes to the string passed by C (though it can
> make changes to its own copy of this string).
> [This last rule because SystemVerilog must not assume that it has been
> given a pointer to a writable string]
>
> on inout ports:
> Verilog passes a reference to a valid string pointer. User code can
> read this string but must never make any changes to this string. User
> can change the string by the same means, and following same rules and
> restrictions, as per output ports.
>
> NOTE: according to sv-ec, strings are a SystemVerilog 3.1 class type. You cannot
> nest strings (or any other class) inside a SystemVerilog structure. This implies
> that strings can only be passed directly to a DirectC function, never indirectly.
> Because of this the specific layout used to represent the string class does not
> need to be described for the DirectC interface (ie implicit conversion in both
> directions across the interface).
> NOTE: no classes other than strings can cross the DirectC interface.
>
>
> pointers:
> SystemVerilog cannot perform any operations on the opaque pointers, so nothing
> extra needs to be said than the general rule.
>
>
> Joao
> ==============================================================================
> Joao Geada, PhD Principal Engineer Verif Tech Group
> Synopsys, Inc TEL: (508) 263-8083
> 154 Crane Meadow Road, Suite 300, FAX: (508) 263-8069
> Marlboro, MA 01752, USA
> ============================================================================== 

--

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! ***

This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 13:24:26 PST