Subject: Re: [sv-cc] more about import/export
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Mar 05 2003 - 16:16:30 PST
Francoise,
To elaborate on what I said below about the issue of model
reuse have a look at slide 21 of the DATE tutorial sent out
by Michael today.
This shows 4 instantiations of the same C model (EthPortWrapper)
where each construction is passed the module pathnames to
which association is to occur.
-- johnS
John Stickley wrote:
> 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 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. __ ______ | \ ______________________/ \__ / \ \ 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 - 16:22:08 PST