RE: my action item for explaining semantics of notify callbacks in SCE-MI pipes

>>> Does your proposal allow the infrastructure to yield control from
the
>>> HDL side to the SW side under any other condition?
>>
>>
>> How about when the buffer implementing the pipe is full?
>
>johnS:
>Precisely. i.e. a blocking function will see a try function
>fail due to a full (or empty) pipe and so will yield at that point.
>Until it can try again. Again, refer to the example in the
>spec for how this is done.

 [Shabtay] 

John, I want to be very precise about the conditions. Fullness of
emptiness of the buffer by your proposal does not cause either yield or
callback to be called. Only the fact that #elements in the pipe have
changed established the criteria for the callback to be called, and it
is the blocking send on full buffer or blocking receive on empty buffer
that causes the yield (among the other causes we discussed).

Please confirm.

Taking this discussion to the next level of details,

Assume now that at simulation start an input pipe is empty. Assume the
HW side used first try_receive() which obviously failed. Assume now that
the HW side now calls the blocking receive() function.

According to your proposal, given that the "the pipe state (i.e.
#elements in the pipe) hasn't changed", the ok_to_send callback will NOT
be called.

Is this behavior in line with your proposal? 

Actually, even if the first call at simulation start is a blocking
receive() on an empty pipe, by your proposal ok_to_send callback will
NOT be called.

Is this behavior in line with your proposal or do you want to create an
exception at simulation start?


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.