The Xillybus Forum

Yeah, indeed. And I just test this can be easily used with python with:

`xillybus_write_32.write(buf)`

`xillybus_read_32.read(size_of_buf)`

Eli, thanks for the Fantastic IP and fantastic guidance! I really appreciate it!

Hi,

Guest wrote:This is about 780190476 bytes/sec, is it very fast for KC705?

That's roughly 780 MB/s. Slightly below the current published limit of 800 MB/s (which will rise soon) and far above what you required -- 300 MB/s.

So if you worked a bit more on the test fixture, you can get it a little higher, I suppose. The question is why bother.

Regards,
Eli

Thank you very much! Eli!

Here is the test results:

16384 bytes, time taken = 0.024222 millisec
16384 bytes, time taken = 0.022990 millisec
16384 bytes, time taken = 0.022990 millisec
16384 bytes, time taken = 0.022580 millisec
16384 bytes, time taken = 0.022580 millisec
16384 bytes, time taken = 0.022169 millisec
16384 bytes, time taken = 0.020938 millisec
16384 bytes, time taken = 0.020938 millisec
16384 bytes, time taken = 0.021348 millisec
16384 bytes, time taken = 0.020938 millisec
16384 bytes, time taken = 0.024632 millisec
16384 bytes, time taken = 0.021759 millisec
16384 bytes, time taken = 0.021759 millisec
16384 bytes, time taken = 0.022169 millisec
16384 bytes, time taken = 0.020938 millisec
16384 bytes, time taken = 0.022990 millisec
16384 bytes, time taken = 0.020938 millisec
16384 bytes, time taken = 0.021759 millisec
16384 bytes, time taken = 0.020938 millisec
16384 bytes, time taken = 0.034485 millisec
16384 bytes, time taken = 0.021348 millisec
16384 bytes, time taken = 0.020938 millisec
16384 bytes, time taken = 0.022169 millisec
16384 bytes, time taken = 0.021348 millisec
16384 bytes, time taken = 0.022580 millisec
16384 bytes, time taken = 0.020938 millisec
16384 bytes, time taken = 7.890599 millisec

This is about 780190476 bytes/sec, is it very fast for KC705?

Yes and yes.

Thanks eli, that message is very reassuring.

Just for double confirm, to read and write from memory, I only need to customize 'streamread.c' and 'streamwrite.c'?

And the device that read() and write() methods target should always be \\.\xillybus_read_32 and \\.\xillybus_write_32?

Best,
Chongxi

Hi,

The bandwidth limit of the bundle you have (KC705) is 800 MB/s, so 300 MB/s should be a piece of cake. I suggest forgetting what I said about the full signal, and see what you get as is, with the loopback in place. Probably way above 300 MB/s.

Please just be sure to write() and read() buffers of say, 16 kB each at least, or the CPU will become the bottleneck on calls to read() and write(). Also, be sure not to read data or write data to the disk or any other slow I/O -- a disk is likely to become a bottleneck too if it's involved.

So writing from memory and reading to memory is probably the right way to feel the speed in a scenario like yours, where you don't want to throw away the data.

Best regards,
Eli

Thanks eli for your fast response.

For my application, I need 300MB/sec stream data go through a filter and loopback to the PC.

Now I am not connecting to any filter yet, just loopback the data stream and test the speed.

Is there any method that I can go to 300MB/sec speed streaming loopback without losing any data?

Hi,

Yes, just use the 32 bit stream in async mode. This is the default for those write_32 streams in the demo bundle anyhow.

And yes, forcing the full signal is likely to cause loss of data in a loopback scenario, but the point is to measure how fast the data can go, without one stream waiting for the other.

As for changing the PCIe for 5 Gb/s -- it's not the simplest thing to get done properly, which might explain the instability you experienced. Anyhow, even if you were successful, you wouldn't see any improvement, as the 8 existing lanes can carry by far more bandwidth than your Xillybus bundle will allow for. The bottleneck isn't the PCIe block.

This page explains more on this topic: http://xillybus.com/doc/xillybus-bandwidth

Regards,
Eli

Wow Thanks eli, your answer is very clear. I understand it now.

So if I want to use 32 bits transferring I just use 32bits FIFO, which is working at asynchronous mode?

If I force the full signals from the `FIFO` to `xillybus_ins`, would that leads to lost of data?

And also I try to modify the pcie-ip-core to run at 5.0Gbits/s instead of 2.5Gbits/s, however when scanning the hardware after I downloaded 5.0G version of bit file, windows always gives me a blue screen.

Best,
Chongxi

Hi,

The PCIE_TX and PCIE_RX ports are the PCIe gigabit transceiver lane wires themselves, running at 2.5 Gbit/s or more on each wire, depending on the platform. The width of 8 is related to the 8 PCIe lanes connection between the KC705 and computer, and has nothing to do with data widths used with Xillybus.

The reason for your slow performance is most likely the speed at which data was read from test.bin (a file on the disk?), or maybe the rate at which it's consumed on xillybus_read_32, in case you've left the loopback.

For an actual performance test, it's actually better to at least disconnect the full signals from the loopback FIFO on the FPGA, and force it zero, so the FPGA never halts the data flow -- if you haven't done that yet.

Regards,
Eli