Subject: Re: DirectC: C layer
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Tue Dec 17 2002 - 10:12:08 PST
Francoise,
Please see responses to your questions below...
Regards,
Doug
Francoise Martinolle wrote:
> My comments in blue below.
>
> At 09:53 AM 12/15/2002 -0800, Warmke, Doug wrote:
>
>>
>> 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.
>
>
> I do agree with the naturalness argument. The behaviour of the SV to C
> function call should look like
> if it were a SV to SV function call.
>
Great!
>> 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).
>
>
> You said the "temporaries used to store the current value of output
> arguments".
> In order to create such /temporaries/ the SV kernel would have to do a
> /copy of the value
> /of the SV argument into that temporary, and pass that temporary by
> reference.
> Then the C function would update the value of the temporary, and upon
> the return the
> SV kernel would have to update the real object value and flush out the
> value through the
> system (propagate and schedule fan out).
> Is that what you are proposing?
> If that is the case you are not really passing a reference to the
> simulation object.
> You are doing copy in and copy out and either passing by value or
> reference the temporary
> value depending on the type of the argument on the C side.
> Am I correct?
> In my opinion the update of the simulation object value must be left out
> to the SV kernel,
> for the reason that the simulation object may currently be forced and
> that there are simulation
> semantics attached to a simulation object.
>
DOUG: You've caught me out - I was indeed making an assumption
about implementation here. Joao's response to your similar
question seems quite good to me. An implementation may use
temporaries or direct values depending on different criteria.
I totally agree with you that the update of the simulation object
value must be left to the SV kernel. Further, I feel that as
a matter of convenience to the user, this update should not require
any special API call to be made (as is currently the case with
PLI/VPI). The update should be done automatically when the C
function returns.
What I was trying to get at here was the advanced (future) case
in which external functions may actually consume time. In those
cases, the SV kernel update mechanism would need to be invoked
by whatever code is suspending the thread in the C function.
My point is that the automatic update mechanism would essentially
be the same in all cases.
Thanks for reading through my (long) emails!
-Doug
>
>
>> 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.
>
>
> Yes I thought about this but I don't think it is a good idea to give the
> user the
> responsibility to call a C function to flush out the 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 : Tue Dec 17 2002 - 10:13:39 PST