Why the PCIE_TX_N and PCIE_TX_P are 8 bits

Questions and discussions about the Xillybus IP core and drivers

Why the PCIE_TX_N and PCIE_TX_P are 8 bits

Postby Guest »

Is the PCIE_TX and PCIE_RX the real interface pin between PC and FPGA?

Why it is 8 bits instead of 32 bits. I am quite confused about the documents say that we can change it to 32 bits?

I've test the speed using 'fifo' program with another console running 'streamwrite \\.\xillybus_write_32 test.bin', it seems the speed is around 20M/sec with my KC705.

Is this slow speed because the Xillydemo use 8bits interface?

Can anyone help me understand? Thanks!
Guest
 

Re: Why the PCIE_TX_N and PCIE_TX_P are 8 bits

Postby support »

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
support
 
Posts: 802
Joined:

Re: Why the PCIE_TX_N and PCIE_TX_P are 8 bits

Postby Guest »

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
Guest
 

Re: Why the PCIE_TX_N and PCIE_TX_P are 8 bits

Postby support »

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
support
 
Posts: 802
Joined:

Re: Why the PCIE_TX_N and PCIE_TX_P are 8 bits

Postby Guest »

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?
Guest
 

Re: Why the PCIE_TX_N and PCIE_TX_P are 8 bits

Postby support »

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
support
 
Posts: 802
Joined:

Re: Why the PCIE_TX_N and PCIE_TX_P are 8 bits

Postby Guest »

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
Guest
 


Re: Why the PCIE_TX_N and PCIE_TX_P are 8 bits

Postby Guest »

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?
Guest
 

Re: Why the PCIE_TX_N and PCIE_TX_P are 8 bits

Postby support »

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
support
 
Posts: 802
Joined:

Next

Return to Xillybus

cron