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
________________________________________________________________