chnl_tester state machine flow issue

[buttercutter]

@drichmond @mjacobsen

https://github.com/KastnerRG/riffa/blob/master/fpga/riffa_hdl/chnl_tester.v#L128 is only cheating the receiving part. This means we are not actually using the actual data received from linux driver, instead we just use self-defined counter.

The problem with this is that we will only be able to compute result from 1 onwards with linear increasing trend. Therefore, it will pose a problem for user verilog logic coding integration which will not follow the same linear increasing trend.

Could you advise ?

[buttercutter]

I have finished rewriting chnl_tester.v to perform simultaneous Rx and Tx

How do I rewrite testutil.c to two separate threads ?

especially I also need to check if (sent != 0) which makes these two threads not totally independent

@marzoul do you have any idea regarding this ? Do I need to modify riffa_driver.c ?

[buttercutter]

Regarding the documentation which states that "At most one thread should be used to access a single channel." as in http://riffa.ucsd.edu/node/10 , I have the following preliminary conclusion:

For https://github.com/KastnerRG/riffa/blob/master/driver/linux/riffa_driver.c#L1003-L1019 , both wrapcheck() functions are using the same io.data variable, while the fill_sg_buf() function is being called with the same data structure udata for both chnl_send() and chnl_recv().

This makes multithreading impossible with the current linux driver coding.

I have a workaround which is to instantiate two separate instances of fpga_chnl_io for https://github.com/KastnerRG/riffa/blob/master/driver/linux/riffa.c#L84-L111

What do you guys think about this ?

New info:

I have just modified few lines for the driver coding as in this modified riffa.c

Could anyone advise on this ?

[buttercutter]

@mjacobsen @drichmond

I have modified your RIFFA coding as in https://github.com/promach/riffa/tree/development to satisfy full duplex communication capability.

However, I am stucked at sample length more than 64. The main reason is due to https://github.com/KastnerRG/riffa/blob/master/fpga/riffa_hdl/tx_port_128.v#L205-L238 which slows down the Tx side and affecting the normal operation of the asynchronous FIFO

I do not wish to increase depth of this asynchronous FIFO as countermeasure to this problem because it will increase latency as well as resource usage of FPGA.

Could anyone advise on better countermeasure ?

[buttercutter]

For those who are interested, please see this reddit thread as well.

@louislxw

By the way, for https://github.com/KastnerRG/riffa/blob/master/fpga/riffa_hdl/rx_port_128.v#L201-L214 , why do we need three FIFO instead of just two FIFO ?

[marzoul]

@ProMach Strange what you say about not possible to do multithreading on a single channel.

Indeed it's not possible that 2 threads try to write or read a given channel. I even added a security check in the Linux driver about this, to at least avoid crash.

However, it is possible, and it does work very well, to have one thread sending data and another thread receiving data, both on the same channel. This has always worked well for my FPGA accelerators.

Regarding chnl_tester, even though it does not do simultaneous send+recv, it's still very useful to check maximum throughput in either direction.

[buttercutter]

Indeed it's not possible that 2 threads try to write or read a given channel. I even added a security check in the Linux driver about this, to at least avoid crash.

Could you elaborate on the security check in the linux driver ?

it is possible, and it does work very well, to have one thread sending data and another thread receiving data, both on the same channel.

What do you exactly mean by this sentence ? Could you elaborate more ?

Note: I have only modified a few lines in riffa.c

Regarding chnl_tester, even though it does not do simultaneous send+recv, it's still very useful to check maximum throughput in either direction.

I have measured the multi-threaded code version to be faster than the original code version. However, I cannot say that I have no bugs in my modification.

Do you have any comments on updated testutil.c and chnl_tester.v ?

[buttercutter]

What do you guys think about the assumptions in this edaboard forum post ?

@louislxw @marzoul @mjacobsen @drichmond

For those of you who are interested in contributing to full-duplex RIFFA, then you are welcome to check out ILA waveforms for full-duplex RIFFA

Just download those two files inside the above gist link and open riffa_full_duplex.gtkw using gtkwave software.

[buttercutter]

How does reorder_queue_input.v achieve tag reordering purpose if it is only considering two tags instead of more than two tags ?