Subject: Re: [sv-cc] more about import/export
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Mar 05 2003 - 15:51:27 PST
Francoise,
Francoise Martinolle wrote:
> Looking at Andrzej's example which illustrates where and how import
> declarations to
> extern function can occur, I have more questions and potential issues.
>
> 1) place of declaration for import/export
> It looks like the import declaration can appear anywhere a declaration
> can appear.
> right?
>
> in SV3.0, the import/export are strictly for interfaces and must be
> declared in a modport.
>
> If we allow the import declaration to appear in any declarative scope,
> and the C function is a "context"
> function, what is the meaning for the context? Is it the current
> instance? or the current scope?
johnS:
The context is the place from which the function is called
not the declaration. On the C side, the callee can obtain
the SV module context of the call site by calling svGetContext().
That's how it will know which particular module instance
is calling it.
>
> SV 3.0 has the ability to declare variables in unnamed blocks; this is
> currently discussed in the bc committee as an issue for hierarchical
> references and VPI name look up.
> Do we want to allow to have import/export declarations in unnamed blocks?
>
> 2) Context passing for exported SV functions
> I think the way we have it set up is complex.
>
> The export declaration must be in the same declarative scope as the
> function SV declaration.
> If there are multiple instantiations of the same function and
> therefore multiple instantiations of the
> export declaration, since the export declaration does not have any
> instance information,
> how does the C function knows which exported SV function to call?
johnS:
The C model would typically identify the specific SV module
instance in which it wants to make the call by geting the SV
context handle via svGetHandleByName() then passing it to
svSetContext() prior to making the call. Typically svGetHandleByName()
would only be called once at construction time and the handle
would be stored.
That's one scenario - the case where a C model can call an HDL
function "out of the blue". This might typically happen if
the C model is running in it's own kernel that is synchronized
with the SV simulator. It could also happen if a C function
being called from SV wants to make a call to an export
SV function that happens to be in a different module than
the one it is being called from.
The other scenario is the case when the a C callee function
called from SV, in turn, makes a call to an exported SV function.
In that case the "default context" is the context of the
SV module originally making the call into C. If svSetContext()
is not called, the context is assumed to be the default context.
Joeo and Andrzej, please let me know if this is the understanding
we reached this week. I did not see this first scenario in your
document that you just mailed out Joao.
>
> The answer was that there will be a default context which would be
> inherited from the current context of the C call which is calling the SV
> function.
> If you don't want to use the current context, there is a C library
> function provided: set_context
> which would be used to set the context prior to the SV call.
>
> I see some problems with that, you would have to hardcode in the C
> function the hierarchical path to
> the export SV function you want to call if different from the current
> context. The C wrapper code
johnS:
Not necessarily. The C model may have been initialized at construction
time and established the context of the SV model that it wants to
communinate with by storing the context handle as a local data member.
Later on, when calls are made back into the SV side, the stored
context handle can be used with svSetContext(). This way, name
lookup only needs to be done once.
Additionally, model reuse is supported here. It may be that the C
model object can be instantiated more than once with the pathname to
each associated SV module passed to the C model's constructor
by say a top level testbench module.
> which calls the SV function is now dependent on the hierarchical name
> too, since the SV function arguments can be instance specific (width of
> the ranges can be dependent on a verilog parameter).
> Note that every C function which calls SV would have to be qualified
> as "context".
>
> I think it is simpler to provide the full hierarchical name in the
> export declaration. The context
> is contained in the hierarchical path to the function and the wrapper
> code can be generated more
> easily.
johnS:
This will not support reuse quite as nicely in my opinion.
And you still have to somehow identify to the C model which
particular SV function instance it wants to call.
Unless you require that a different C alias is given for
each exported instance of an SV function. That really prevents
reuse !
> Allow the export declaration to be outside of a module definition or in
> $root.
>
> The syntax :export cname = hierarchical_path_to_SVfunction...
> would allow to have different C functions calling different instances of
> the SV function. The C function
> does not need to know or set the context.
>
>
>
> Example
> ========= start of SV code ========
> module top
>
>
> mod u1#(15)(); //instance of mod parameter size is overridden with 15
> mod u2 (); // instance of mod uses default parameter size value of 7
>
> other u3();
> endmodule
>
> module mod
> parameter size = 7;
> export SVf;
> function SVf (reg [size :0] arg1 )
> ...
> endfunction
> endmodule
>
> mod other
> initial
> begin
> import extern context B = void foo(int i = 5);
>
> foo; // calling B(5), B is calling SVf, which SVf to call?
> end
> endmodule
> ========= end of SV code ========
>
> Let's assume in the above example that foo is context sensitive and
> calls SVf exported function.
> How do you specify which SVf to call if you have only one export
> declaration?
>
> If you instead use:
> export C = top.u1.SVf();
> export D = top.u2.SVf().
>
> the C code for function foo can be simple, no need to get and set the
> context
>
> function foo (int arg1)
> {
> if (arg1 == 5)
> C(...); // calls C
> else D( ...); // or calls D
> }
-- johnS
__
______ | \
______________________/ \__ / \
\ H Dome ___/ |
John Stickley E | a __ ___/ / \____
Principal Engineer l | l | \ /
Verification Solutions Group | f | \/ ____
Mentor Graphics Corp. - MED C \ -- / /
17 E. Cedar Place a \ __/ / /
Ramsey, NJ 07446 p | / ___/
| / /
mailto:John_Stickley@mentor.com \ /
Phone: (201)818-2585 \ /
---------
This archive was generated by hypermail 2b28 : Wed Mar 05 2003 - 15:56:52 PST