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

Hi Shabtay,

> BTW, if I am looking at a consumer from the HDL side, the term "yield to
> another (HDL) thread" sounds awkward to me.  The HDL side is concurrent
> in nature. "Yield" (which I also call synchronization) will happen using
> blocking calls on any of pipes, or flush on output pipe anywhere in the
> HDL side. 

Actually, the `yield to another HDL thread' is not the same as a
synchronization.  In HDL the yielding is what happens when the
process enters a wait of some sort.  In Verilog, for instance,
it would be something like @(posedge clk) or even #10, for instance.
That is, it is anything that causes that block of code to be suspended
until some future *simulation* time.

Of course, this is a just a matter of definition of the term `yield',
but to be consistent with how we've been using it on the software
side that is how it should be defined.  We can use `synchronization'
for the other kind of yield when the HDL side needs to communicate
with the software side.

> [Shabtay] Actually here you hit on a question I wanted to ask. 
> When the producer was notified by the ok_to_send() callback, what if it
> doesn't send any new elements for whatever reason. Maybe once notified
> it wants to wait on a different callback. 
> 
> If this scenario is mot implemented correctly, it may lead to a
> deadlock. However I assume that in SCE-MI 2.0, responding to
> ok_to_send() w/o sending any elements is allowed. 

Yes, I would agree that that is allowed.  It would be very hard if not
impossible to check if the ok_to_send() callback resulted directly or
indirectly in elements being sent.   And yes, it is possible to create
a deadlock with this interface as it was with SCE-MI 1.x and UNIX pipes,
sockets, etc.

> So obviously input pipe empty detected by a blocking receive call will
> cause a yield from the consumer to the producer. However if the consumer
> chose to use the try_receive call which failed, the actual detection of
> the buffer being empty does NOT cause the consumer to yield to the
> producer side of the pipe (or the to another thread).

Here you're talking about synchronizations which is different from
the consumer yielding to another `thread' on its side of the interface.
I am not sure we need to specify when synchronizations happen.  Shouldn't
that be up to the implementation?  The implementor should be free to
decide when the hardware and software side communicate.  We need to
specify the behavior such that applications produce the same results
on different implementations, but not the details of how this is
achieved.

> [Shabtay]Yes. I want to make sure that in the current proposal, the
> implementation does not yield to the producer when input pipe become
> empty while called by try_receive. 

I'm wondering why you think this needs to be specified?  Or perhaps
you're asking if what you describe is a legal implementation of the
specification?  This is of course a weaker statement but definitely
worth clarifying.  I agree that an implementation is not required
to synchronize in the scenario you describe.  I am not sure if the
spec requires it not to.

Per




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