Re: Implementing the non-blocking pipes API

Per,

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

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. 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.

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

int
InputPipe::CCanSend(int bytes_per_element,
                     int num_elements)
{
   if (!bufferInitialized)
     initBuffer(bytes_per_element, num_elements);
   return bytes_per_element * num_elements <= bytesFree() ? 1 : 0;
} /* InputPipe::CCanSend */


to do that I had to make bufferInitialized protected:

   protected:
     // Buffer.
     bool                      bufferInitialized; ///< Whether buffer
                          ///< has been
                          ///< initialized.


That's it !

I've attached the newest revision of the scemi2_demo. Now I can send it
by e-mail since it doesn't need pre-compiled objects any more.

What you see in here is full source code (including yours) to run
the scemi2_demo cases on a stock ModelSim 6.1a simulator with
native DPI support. No more binary reference model needed !!

You'll find your sources in the scemi2_demo/lib directory and a
modified Makefile there that builds the needed library completely
from scratch.

This was run on a 64 bit Opteron with Redhat Linux version RHEL 3.0
loaded on it.

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

-- johnS

Per Bojsen wrote:
> Argh, I forgot the attachment ;-)
> 
> Hi,
> 
> I have enclosed an update to the SCE-MI pipes non-blocking API
> implementation.  Changes include:
> 
>   1) Fixed bug in handling of EOM on the receive side (consumer
>      side).  This bug resulted in EOM having incorrect values on
>      the receive side of pipes.
> 
>   2) Fixed how the notify callbacks are done to match my current
>      understanding based on John's feedback at the last meeting.
>      Added HDL side callbacks.  Notification is now done to the
>      other side of a pipe whenever the state changes, i.e., on
>      send when data has been transferred successfully to the pipe,
>      and on receive when data has been removed successfully from
>      the pipe.
> 
>   3) Added bytes per element restriction to the interface.  The
>      bytes per element is now a fixed value per pipe which is
>      set on the first use of the pipe that includes a bytes per
>      element argument.  Subsequent uses will check that the bytes
>      per element is consistent with prior uses.
> 
>   4) Fixed bug in the test that allowed the last two loops to
>      go beyond the end of the 1024 word data buffer.  I stress
>      that this was a bug in test and not the pipe API
>      implementation.
> 
> So far I've been testing the code on an AMD64 64-bit Debian Linux
> platform.  I plan to test it out on IA32 32-bit Red Hat Linux soon. Stay
> tuned.
> 
> Enjoy,
> 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
________________________________________________________________