Subject: RE: DirectC: C layer
From: Kevin Cameron (sv-xx@grfx.com)
Date: Sun Dec 15 2002 - 10:29:55 PST
> From: "Warmke, Doug" <doug_warmke@mentorg.com>
>
>
> Team,
>
> Some more discussion regarding the update of
> output arguments is embedded. Please read below.
>
> Regarding Joao's discussion of our original goals,
> I totally agree - we need to optimize convenience
> and performance. Here is yet another way to think
> about the goals of our SVC interface:
>
> The user's code on the C-side should look as much as possible
> like a natural C function. In natural C functions, one doesn't
> need to call special system-provided API's to propagate output
> values to their destinations. Same with natural SV functions
> for that matter. Our SVC standard should try to meet
> this "naturalness" requirement as much as possible.
> Otherwise, why not just stick with PLI?
PLI/VPI is an abstract access method. It's all you can do when
the simulator data is not mapped to memory in a consistent manner.
The logical step forward is to move to a C++ based coding style
for the VPI/PLI functionality so the interface can stay abstract
but be handled more efficiently and (C++) users will understand
it easily.
There are too many legacy simulators around that are too difficult
to re-engineer to make using a direct memory interface practical.
If I was going to write a simulator from scratch I would certainly
endevor to provide as many direct interfaces as possible. However,
having a standard that is only implemented by one or two vendors
is not useful, it needs to be implementable by everyone (in reasonable
time).
> Note that this "naturalness" is inherent in the current mixed
> VHDL/Vlog implementations in use today. I like sticking with
> that established language-mixing use model as much as possible.
Which standard is that?
> Futher, note that one of the main spirits of the 17 points is
> that SV call sites of C functions should obey natural SV
> syntax and semantics as well.
It would be good to be able to call standard C library functions
without (major) rewrites of all the header files, so I think the
interface definition needs to support both styles (as much as
possible).
Kev.
> I hope these arguments and this plea for "naturalness" sound
> reasonable to most on the committee. I think we can achieve
> this goal and still meet other concerns satisfactorily.
>
> More below...
>
> -----Original Message-----
> From: Stickley, John
> To: Francoise Martinolle
> Cc: Andrzej Litwiniuk; sv-cc@server.eda.org
> Sent: 12/13/2002 5:07 PM
> Subject: Re: DirectC: C layer
>
> Francoise,
>
> Francoise Martinolle wrote:
> > Andrzej,
> >
> > It was very difficult today to place any word during the meeting so
> I am
> > gathering my issues/comments in this email.
> >
> > I have 3 main issues with the proposal.
> >
> > The first one has to do with passing by reference the simulation
> object
> > value and that
> > value be modified by the directC interface. When and how is the
> > propagation of that value
> > done? Wires and regs have fan out and updates to their values
> should cause
> > propagation and fanout. When does this happen? What about if there
> is a
> > force in effect on that
> > object? Would the value be updated by the C code?
>
> johnS:
> I don't think this would be a problem. While in the C function,
> we've all agreed time advance is 0-time, correct ? So what would
> happen is that the calling of the C function would be an instantaneous
> call somewhere in the process activation phase of the SV simulation
> cycle that would essentially block the kernel for the duration of
> the call, much as PLI callbacks do today.
>
> DOUG: While the 0-time constraint does make things easier, it is
> still not out of the question for an implementation to handle
> output argument updates for time consuming functions in the future.
> It is difficult, but essentially at each suspension point, the
> temporaries used to store the current value of output arguments
> would need to be flushed through into the system. (Exact same
> actions as need to be taken when a 0-time function terminates
> and returns to caller).
>
> The generated code representing the SV process that makes the function
> call (I'm talking about an SV-to-C call now) will make the call which,
> upon return, would update the output argument which could,
> in turn, update the value of the nets as if the value had been
> directly assigned with local, conventional blocking assign statement.
> To me that's the easiest semantic to describe and understand.
> Effectively the function acts as a combinatorial argument
> transformation such one would see with direct blocking assignment.
> If non-blocking semantics are desired, the function return or
> output argument could simply become the source expression of a
> non-blocking assignment on the SV side.
>
> Example:
>
> Continuous assignment:
>
> wire dest;
> dest = my_ret_func( source );
>
> Blocking and non-blocking assignment w/ void function that has output
> arg:
>
> reg dest;
>
> always @(posedge clk) begin
> ...
> my_void_func( source, dest ); // Blocking assign semantics to
> dest
> nb_dest <= dest; // Non-blocking assign of arg to nb_dest
>
> Blocking, assignment w/ non-void function that returns arg:
>
> reg dest;
>
> always @(posedge clk) begin
> ...
> dest = my_ret_func( source ); // Blocking assign semantics to
> dest
>
>
> Non-blocking, assignment w/ non-void function that returns arg:
>
> reg dest;
>
> always @(posedge clk) begin
> ...
> nb_dest <= my_ret_func( source ); // Non-blocking assign
> semantics
>
>
> So, unless I'm missing something, I don't see where the
> pass-by-reference
> semantic makes a difference here for the case of the void function
> with an output arg. And for return args, the implication is always
> return-by-value.
>
> DOUG: John - you've shown the easiest cases here.
> In which the natural SV language mechanisms are used
> to propagate output values into the system.
> It is more difficult for implementations to handle
> the void function with output argument case. In that
> scenario, extra code would have to be generated that
> would automatically update any nets to which the output
> arguments are connected. IMO this is slightly troublesome
> for implementations, but highly convenient for users.
> Since the only alternative is to have the user explicitly
> make API calls to propagate output values. And then we
> are basically back at the inconvenience level of PLI/VPI,
> whether or not we choose to use functions from those API's
> or our own (as Kevin has suggested).
>
>
> <rest of mail thread is snipped>
>
> Thanks and regards,
> Doug
>
This archive was generated by hypermail 2b28 : Sun Dec 15 2002 - 12:10:46 PST