Xillybus with Vivado HLS Coprocessing

Questions and discussions about the Xillybus IP core and drivers

Xillybus with Vivado HLS Coprocessing

Postby mohdamir »

Hi Eli and all,

This tutorial is a great start: http://xillybus.com/tutorials/vivado-hls-c-fpga-howto-2 where I can implement coprocessing using a simple sin function in Vivado HLS.

However, I got a problem where the rc reached read EOF, and furthermore the size of N (in the sample it is 1000) can't be more than 23. If i use 24 (or above), it will stuck there and nothing happens.

Could anyone point me the direction what should be done, please? Or maybe a suggestion. Below is the modification I have made:

I used Windows, and I removed fork(), but I didn't use any kind of CreateThread or similar. I made some modifications to be used with Windows which are:

1) include header for windows such as <io.h> etc
2) change open, read, write, close to _open, _read, _write, _close and also \\\\.\\xillybus_read_32 and \\\\.\\xillybus_write_32
3) put character 'f' for floating point number

The flow of the program sequentially is:

1) open xillybus_read and write with fdr and fdw
2) malloc tologic
3) a for loop for tologic data
4) buf and donebytes
5) write using _write for rc
6) malloc fromlogic
7) buf and donebytes
8) read using _read for rc
9) print the results

Regards.
mohdamir
 
Posts: 15
Joined:

Re: Xillybus with Vivado HLS Coprocessing

Postby support »

Hello,

To begin with, it's recommended to run the read and write loops in different threads. Otherwise, there's a chance that things will get stuck, if the part that writes data for processing fills the DMA buffers. Since you don't read any data on the other side, the FPGA fills the DMA buffers for data to read, and then waits. The host waits for more room in the write DMA buffers, while the FPGA waits for the read DMA buffers to clear up, and we have a deadlock.

On the other hand, if data is written and read in different processes or threads, this can't happen.

mohdamir wrote:However, I got a problem where the rc reached read EOF, and furthermore the size of N (in the sample it is 1000) can't be more than 23. If i use 24 (or above), it will stuck there and nothing happens.


You got an EOF? How could that be? The *_eof signals in the FPGA are tied to zero.

Regards,
Eli
support
 
Posts: 802
Joined:

Re: Xillybus with Vivado HLS Coprocessing

Postby mohdamir »

Yup, I've already tied *_eof to 0 in my FPGA. This is what I have done, by modifying/adding the code in VHDL (as shown below).

*Note 1: in my HLS code, I removed debug header *.h and also I removed the code of debug, and I didn't change anything for the rest of the sample code. Furthermore, I used Virtex 707 and my clock period is 4 ns (without uncertainty).

*Note 2: I tried to use 10 ns for the clock period in HLS, however there are always timing error (at least 4 timing not met), so I changed to 4 ns, and made a little tweak in placer cost table such that all timing are met.

This is what I have done for my FPGA:

1) adding wires/registers

Code: Select all
// Wires related to HLS_wrapper
wire    [31:0]    in_r_dout;
wire             in_r_read;
wire             hls_fifo_rd_en;
reg             in_r_empty_n;
wire    [31:0]    out_r_din;
wire             out_r_full;
wire             out_r_write;


2) adding FIFO (to function) with Xillybus/HLS

Code: Select all
 fifo_32x512 fifo_to_function
 (
 .clk(bus_clk),
 .srst(!user_w_write_32_open),
 .din(user_w_write_32_data),
 .wr_en(user_w_write_32_wren),
 .rd_en(hls_fifo_rd_en),
 .dout(in_r_dout),
 .full(user_w_write_32_full),
 .empty(hls_fifo_empty) );
 
 assign hls_fifo_rd_en = !hls_fifo_empty && (in_r_read || !in_r_empty_n);
 
 always @(posedge bus_clk)
 if (!user_w_write_32_open) in_r_empty_n <= 0;
 else if (hls_fifo_rd_en) in_r_empty_n <= 1;
 else if (in_r_read) in_r_empty_n <= 0;


3) adding FIFO (from_function)

Code: Select all
 fifo_32x512 fifo_from_function
 (
 .clk(bus_clk),
 .srst(!user_r_read_32_open),
 .din(out_r_din),
 .wr_en(out_r_write),
 .rd_en(user_r_read_32_rden),
 .dout(user_r_read_32_data),
 .full(out_r_full),
 .empty(user_r_read_32_empty) );
 
 assign user_r_read_32_eof = 0;


4) adding wrapper for hls_wrapper

Code: Select all
 xillybus_wrapper HLS_wrapper
 (
 .ap_clk(bus_clk),
 .ap_rst(!user_w_write_32_open || !user_r_read_32_open),
 .in_r_dout(in_r_dout),
 .in_r_empty_n(in_r_empty_n),
 .in_r_read(in_r_read),
 .out_r_din(out_r_din),
 .out_r_full_n(!out_r_full),
 .out_r_write(out_r_write) );
mohdamir
 
Posts: 15
Joined:

Re: Xillybus with Vivado HLS Coprocessing

Postby support »

Hi,

But -- did you or did you not get the message saying EOF was reached?

Regards,
Eli
support
 
Posts: 802
Joined:

Re: Xillybus with Vivado HLS Coprocessing

Postby mohdamir »

Sometimes, I got EOF if I put (for example); define N to 25.

But sometimes, it stuck, without any message (EOF or anything), for example; define N to 100.

Another interesting part is, if I use different floating point number, instead of 0.78539816, but I just use 0.78 (in the C code), I can get 128 for N without error, but 256 with error EOF.
mohdamir
 
Posts: 15
Joined:

Re: Xillybus with Vivado HLS Coprocessing

Postby support »

Hello,

If you get an EOF in the stream with the *_eof ports tied low, you're definitely in the unicorn zone: Things that never happen do happen to you. The immediate suspect is clocking issues and timing constraints. As a matter of fact, I find it quite peculiar that you reduced the clock to 10 ns, and the timing failed at that time -- but for 4 ns it was fine. If a design passes timing on 4 ns, it definitely should pass on 10 ns. A change in the placer cost table can't explain what happened to you.

So I warmly suggest looking into the basics of your design: Timing, clock domains and constraints.

Regards,
Eli
support
 
Posts: 802
Joined:

Re: Xillybus with Vivado HLS Coprocessing

Postby Guest »

I want to try thr same. Could you explain me the procedure of how you did it?
Guest
 


Return to Xillybus