Questions on xillybus_fpga_api.pdf

Questions and discussions about the Xillybus IP core and drivers

Questions on xillybus_fpga_api.pdf

Postby kevin » Tue Dec 12, 2017 10:49 am

Hi, I have some questions on http://xillybus.com/downloads/doc/xillybus_fpga_api.pdf page 11

1) For the signal "user_r_{devfile}_eof" , could you elaborate the following sentences ? Besides, why is the signal user_r_read_32_eof assigned as 0 in the demo bundle ?

Like the ’empty’ signal, the ’eof’ signal must be asserted only on a clock cycle following a read cycle. An exception for this is when the ’empty’ signal is already asserted, in which case ’eof’ may be asserted at any clock cycle. This exception can be used to make a blocking read() call at the host return immediately. So, one way to assure that ’eof’ is asserted correctly, is to have it combinatorically ANDed with the ’empty’ signal.


2) Do you have examples of why
The ’empty’ signal may and may not be asserted in conjunction with an ’eof’ assertion.


3) How do I see the following as loopback FIFO ?

// 32-bit loopback
fifo_32x512 fifo_32
(
.clk(bus_clk),
.srst(!user_w_write_32_open && !user_r_read_32_open),
.din(user_w_write_32_data),
.wr_en(user_w_write_32_wren),
.rd_en(user_r_read_32_rden),
.dout(user_r_read_32_data),
.full(user_w_write_32_full),
.empty(user_r_read_32_empty)
);
kevin
 
Posts: 42
Joined: Tue Dec 12, 2017 10:41 am

Re: Questions on xillybus_fpga_api.pdf

Postby support » Thu Dec 14, 2017 3:19 am

Hello.

Answering your questions with matching numbers:

1) 'eof' is held zero, because the demo bundle shows an infinite loopback stream, and hence should never send an EOF to the host. The cited paragraph describes when eof may be asserted, not that it must be.

2) Once again, this paragraph says what's allowed. It's up to the application logic to make the choices what to do.

3) Note that all of the FIFO's ports that are related to writing to the FIFO are connected to Xillybus' user_w_write_32_* signals, and all FIFO read data ports to user_r_read_32_*. Consequently, Xillybus' IP core pushes arriving data from the write_32 stream to the FIFO, and fetches data to send to read_32 from the same FIFO. All in all, data is looped back from write_32 to read_32.

Regards,
Eli
support
 
Posts: 626
Joined: Tue Apr 24, 2012 3:46 pm

Re: Questions on xillybus_fpga_api.pdf

Postby kevin » Thu Dec 14, 2017 6:33 am

The user_r_read_32_eof signal is required to go from ’0’ to ’1’ only on a clock cycle following an asserted read enable, according to Xillybus’ core API. This is assured, since it’s a logical AND between user_r_read_32_empty and has_been_full.


1) I understand from the above sentence that user_r_read_32_eof is only a single positive pulse. However, how does the AND operation helps to assure generation of single positive pulse ?
kevin
 
Posts: 42
Joined: Tue Dec 12, 2017 10:41 am

Re: Questions on xillybus_fpga_api.pdf

Postby support » Sun Dec 17, 2017 8:29 am

Hello,

The cited sentence says nothing about user_r_read_32_eof being a pulse. It just states when it's allowed to transition from '0' to '1'. There is no rule on how long it remains at '1'.

Regards,
Eli
support
 
Posts: 626
Joined: Tue Apr 24, 2012 3:46 pm

Re: Questions on xillybus_fpga_api.pdf

Postby kevin » Mon Dec 18, 2017 5:20 am

I still do not understand why signal 'user_r_read_32_eof' should depend on the signal 'has_been_full'.

Would you be able to describe more ?
kevin
 
Posts: 42
Joined: Tue Dec 12, 2017 10:41 am

Re: Questions on xillybus_fpga_api.pdf

Postby kevin » Fri Dec 29, 2017 3:59 am

1) From http://xillybus.com/downloads/doc/xillybus_fpga_api.pdf#page=17 , why do we ever need a signal called 'capture_has_been_nonfull' ?

Code: Select all
if (capture_full && capture_has_been_nonfull)
    capture_has_been_full <= 1;


2) Why capturing should not take place (capture_en is not asserted) if FIFO has been full in the past (capture_has_been_full is asserted) ?
kevin
 
Posts: 42
Joined: Tue Dec 12, 2017 10:41 am

Re: Questions on xillybus_fpga_api.pdf

Postby support » Tue Jan 02, 2018 3:37 pm

Hello,

The whole point of the said example is to show how to issue an EOF as a result of an overflow in the FIFO. This way, the application on the host knows that as long as the data keeps arriving, it has not been subject to loss due to an overflow on the FPGA.

Regards,
Eli
support
 
Posts: 626
Joined: Tue Apr 24, 2012 3:46 pm

Re: Questions on xillybus_fpga_api.pdf

Postby kevin » Thu Jan 04, 2018 2:07 am

According to first point in http://xillybus.com/doc/bandwidth-guidelines , it is suggested to tied 'full' signal to zero for optimal data rates. However, it also says that it would result in overflow issues.

Would you be able to describe more on how 'capture_has_been_nonfull' is related EOF when overflow happens ?
kevin
 
Posts: 42
Joined: Tue Dec 12, 2017 10:41 am

Re: Questions on xillybus_fpga_api.pdf

Postby support » Wed Jan 10, 2018 9:01 am

Hello,

The reason to tie "full" low on a bandwidth test is to allow the data to flow without interruptions. It's a quick and dirty way, and comes at the cost of the data being faulty. This is the complete opposite of the efforts to ensure the validity of the data in the example discussed in this thread.

Regards,
Eli
support
 
Posts: 626
Joined: Tue Apr 24, 2012 3:46 pm


Return to Xillybus

cron