RE: SV utilities in non-context task/functions

Hi John,

My message was not intended to spark more debate.  I was sending this
mainly to Brian as I had an action item from today's meeting to send the
relevant paragraph and include my interpretation so that Brian may fwd
to the SystemVerilog folks for clarification.

Brian, please let me know if this is sufficient.

Regards,
Jason

> -----Original Message-----
> From: John Stickley [mailto:john_stickley@mentor.com]
> Sent: Thursday, March 30, 2006 4:03 PM
> To: Jason Rothfuss; 'itc@eda.org'
> Subject: Re: SV utilities in non-context task/functions
> 
> Jason,
> 
> I think the some of the original intent of the sv-cc committee,
> at least during my participation, was that the standard was
> careful to provide a mechanism where it was clear
> where optimizations of the type you refer to below could
> be done - clear compiler "hints" if you will.
> 
> But also careful to not prohibit certain useful use models
> such as interfacing with external threading environments
> such as SystemC.
> 
> As it turns out, you should be able to have the best
> of both worlds: optimization when you want it. But also
> not prohibiting external use models.
> 
> This allows a scenario where let's say a vendor provides a global
> switch, or perhaps a per-module analysis switch that would
> inhibit such optimizations to accomodate a user who might
> want to make DPI calls and context calls from outside of imported
> functions, such as in SystemC constructors or threads.
> 
> If I remember right this is why adding language prohibiting
> such use models was deliberately left out.
> 
> -- johnS
> 
> 
> Jason Rothfuss wrote:
> > Hi Brian & ITC,
> >
> >
> >
> > Here is the paragraph taken from IEEE 1800-2005, that we were
> debating
> > today:
> >
> >
> >
> > "To avoid any unnecessary overhead, imported task and function
> calls in
> > SystemVerilog code are not
> >
> > instrumented unless the imported task or function is specified as
> > context in its SystemVerilog import declaration.
> >
> > A small set of DPI utility functions are available to assist
> programmers
> > when working with context
> >
> > tasks or functions (see F.8.3). If those utility functions are
> used with
> > any noncontext function, a system error
> >
> > shall result."
> >
> >
> >
> > The utility functions mentioned are:
> >
> >     * svGetScope()
> >     * svSetScope()
> >     * svGetNameFromScope()
> >     * svGetScopeFromName()
> >     * svPutUserData()
> >     * svGetUserData()
> >     * svGetCallerInfo()
> >
> >
> >
> > It is my interpretation of this section to mean that these utility
> > functions may /only /be called from within a context imported
> > task/function; meaning that calling any of these from a pure
> imported
> > function or SystemC constructor not called as a result of a
> context
> > imported function is illegal.
> >
> >
> >
> > Here is an example of why I think this restriction is in the
> > SystemVerilog specification:
> >
> >
> >
> > module top;
> >
> >    reg clk;
> >
> >    wire [31:0] dout;
> >
> >    wire        valid;
> >
> >    ...
> >
> >    bfm i0(dout,valid,clk);
> >
> > endmodule
> >
> >
> >
> > module bfm(dout,valid,clk);
> >
> >    input         clk;
> >
> >    output [31:0] dout;
> >
> >    output        valid;
> >
> >    ...
> >
> > endmodule
> >
> >
> >
> > Compiler ABC wants to take advantage of any optimization possible.
> > Since it sees that there are no context DPI import or export
> > tasks/functions declared in the module "bfm", it decides to omit
> the
> > svUserData space from its internal representation of the module.
> In
> > addition, it decides to inline the module, so its scope (top.i0)
> does
> > not even exist.  So, if I have some SystemC code for which the HDL
> > compiler knows nothing about, I cannot do
> svGetScopeFromName("top.i0"),
> > because the scope doesn't exist, since it has been inlined.  I
> also
> > cannot do svPutUserData() for two reasons: (1) I can't get the
> scope to
> > top.i0; (2) Storage space for svUserData has been optimized away
> because
> > there are no context task/functions declared.
> >
> >
> >
> > Perhaps compiler XYZ does not make these optimizations and allows
> > calling the utility functions from non-context functions, but I
> believe
> > that the specification is trying to allow what compiler ABC is
> doing,
> > and maybe even some other things.
> >
> >
> >
> > Also, let me draw an analogy to PLI.  Using acc_* routines, you
> are
> > supposed to do:
> >
> >
> >
> > int my_pli_call() {
> >
> >    acc_initialize();
> >
> >    /* your stuff goes here */
> >
> >    ...
> >
> >    acc_close();
> >
> >    return 0;
> >
> > }
> >
> >
> >
> > Not all simulators require that you have acc_initialize() and
> > acc_close() in your code, but you're supposed to do it.
> >
> >
> >
> > Imagine that Simulator ABC does something like the initialize and
> close
> > when any imported context DPI function/task is called to set up
> the
> > simulation to enable use of SV utility functions.  Not all
> simulators
> > may do something like this, but it is possible that the compiler
> can do
> > some things to optimize the non-context functions/tasks to the
> point
> > where calling the SV utility functions will crash the sim.
> >
> >
> >
> > Regards,
> >
> > Jason
> >
> 
> 
> --
> 
> This email may contain material that is confidential, privileged
> and/or attorney work product for the sole use of the intended
> recipient.  Any review, reliance or distribution by others or
> forwarding without express permission        /\
> is strictly prohibited. If you are     /\   |  \
> not the intended recipient please     |  \ /   |
> contact the sender and delete        /    \     \
> all copies.                      /\_/  K2  \_    \_
> ______________________________/\/            \     \
> John Stickley                   \             \     \
> Mgr., Acceleration Methodologies \             \________________
> Mentor Graphics - MED             \_
> 17 E. Cedar Place                   \   john_stickley@mentor.com
> Ramsey, NJ  07446                    \     Phone: (201) 818-2585
> ________________________________________________________________