Subject: RE: DirectC: C layer
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Sun Dec 15 2002 - 09:53:39 PST
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?
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.
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.
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 - 09:54:05 PST