Subject: RE: [sv-cc] more about import/export
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Mar 05 2003 - 22:31:12 PST
Francoise, John,
Some comments and questions embedded.
Regards,
Doug
>
> 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.
DOUG: Francoise's question brings up a very interesting point.
(Why do you seem to have this habit, Francoise? :^)
Even with John's answer, which makes sense, what exactly is
the context anchored to? I think John is assuming that it
is anchored to the nearest enclosing module instance.
If so, that should be explicitly stated in the LRM.
(Looks like I may have to do such stating when I work
on this part of the SV-side LRM).
What if the function is called from within a program instance
or an interface instance, rather than a module instance?
The context must be anchored to such instances as well.
Are there any other types of instances to which import/extern
functions must be anchored?
Generate statements may provide some trickery for
implementations, although I don't think we need to
mention that in the LRM.
>
> >
> > 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?
DOUG: Another good question. I think that given John's
answer above, the answer to this question may be a "don't care",
though. Since the context is anchored to the instance
immediately surrounding the call site, not the declaration site.
All instances must be nameable for hierarchical references
to work, thus I don't think this is an issue.
Here come a couple questions that may display the limits
of my SV syntax knowledge :-O
1. This reminds me of generate blocks as well.
Is there a firm definition for hierarchically referring
through generated instances? (Maybe already resolved in
Verilog 2001, sorry for my lack of expertise here)
2. In SV 3.1 draft 3, I looked through the BNF for the module
construct and I couldn't find any reference to unnamed blocks.
Here I'm thinking about something parallel to the VHDL "block"
construct, rather than a basic block of sequential code
delimited by begin/end. Is there anything in SV like a
VHDL block? If so, we'll have to watch out for anonymous
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.
DOUG: When I work over the C-side LRM, I will make sure to edit
it to reflect this understanding. The API functions you name
will all be present.
<EOM>
>
> >
> > 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 - 22:31:59 PST