Re: Implementing the non-blocking pipes API

Hi John,

> Want to hear something outrageously cool ? Your pipes implementation
> is running the same scemi2_demo cases I distributed earlier on
> ModelSim 6.1 !!

That's great news!  I must admit I am a bit surprised :-)  I did
expect to have to do some adjustments.  It is very nice to see that
they are so minor.

> I only had to make 1 very minor change. If dpi_pipe_c_can_send()
> is called on an uninitialized pipe, it indicates that the
> send cannot complete.

Oh, right.

>  What you really want to do in this case is
> "initialize on-the-fly" like you do in trySend() so that
> the call with return with a successful status.

Yes, that makes sense.

> To fix it I just changed ::CCanSend() as follows:

I think we need to fix CCanReceive() in a similar fashion
as well.  I guess it will not matter since an uninitialized pipe
has no data to receive anyway.  But for symmetry we might want
to do the initialization after all.

> That's it !

Very cool :-)

> I also have a couple of data shaping tests I can try to run
> through it. I'll let you know how they work.

I am looking forward to hear what you find.

Meanwhile, I found another EOM related bug.  I have attached
the latest version of my code.  This also incorporates your
changes.  I enhanced it a little bit by moving the test of
bufferInitialized inside initBuffer().  I also added the
initBuffer() call to CCanReceive() for the symmetry reasons
I mentioned above.

There is an issue in how the buffer is handled.  The way the
code is currently written it does not resize the buffer at any
time unless the dpi_pipe_c_set_depth() function is called
(BTW is this the name you proposed?).  So if one tries to
send a number of elements that is larger than the current
depth of the buffer it will always fail.  Is this the behavior
you intended for the non-blocking API?  In that case, might
it be worthwhile to change the dpi_pipe_c_try_send() and
dpi_pipe_hdl_try_send() functions to also include a
num_elements_sent argument.  These functions would then transfer
as many elements as there is currently room for in the pipe
buffer and set num_elements_sent accordingly.  The downside
to such an API is that one would have to shuffle the data
that is in the tail of the data attempted transferred.  This
data may not start on a nice svBitVecVal boundary if the
bytes_per_element value is not a multiple of 4 bytes.

Alternatively, we could just have the API resize the buffer on
the fly when the user attempts to send a number of elements
larger than the current buffer allows for.  Note, this would
be software side only.  On the hardware side a static analysis
should be able to detect the minimum buffer size needed.  Also,
when the target is an emulator and not a SW simulator, the
hardware side will be able to use uncontrolled clocks or the
equivalent thereof to handle arbitrarily sized blocks by using
segmentation/reassembly techniques.  In a SW simulator setting
this is not necessary as one can always resize the buffer
dynamically to accomodate the data.

What were your thoughts on this?

Thanks,
Per