Re: Implementing the non-blocking pipes API

Per,

More good news. My data shaping test worked first time
- no modifications to your pipes from what I sent earlier.

-- johnS

Per Bojsen wrote:
> 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


-- 

This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________