Subject: RE: [sv-cc] more about import/export
From: Francoise Martinolle (fm@cadence.com)
Date: Thu Mar 06 2003 - 08:56:46 PST
Doug, John,
some answers embedded.
We need to clarify in the final LRM what does the get_context returns.
Francoise
'
At 10:31 PM 3/5/2003 -0800, Warmke, Doug wrote:
>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.
The function call can be from within a module, interface, program, task or
function,
generate instance.
> >
> > >
> > > 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.
Yes we should be able to get a hierarchical path name to the function call,
>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)
Yes, look page 192 section Hierarchical names. Each module instance,
generated instance, task, function or named begin-end or fork-join block
defines a new hierarchical level.
Also for generated instances names look page 175 and 176. For for loop
generates,
the value of the genvar variable for the generated instance is appended
between brackets to
the end of the name of the generate block.
>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.
In SV3.1, you can have unamed blocks which will contain local variables.
These variables cannot be referenced from outside the unamed block but are
visible to the unnamed block
and any of its nested scopes.
Section 5.5, draft 3.
"Note that in SystemVerilog, data can be declared in unnamed blocks as well
as in named blocks, but in the
unnamed blocks a hierarchical name cannot be used to access it."
> > >
> > > 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 !
Some exported functions may not be instance specific.
> >
> > > 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 : Thu Mar 06 2003 - 08:58:39 PST