generating xillybus core for 2 lanes on Kintex

Questions and discussions about the Xillybus IP core and drivers

generating xillybus core for 2 lanes on Kintex

Postby Guest »

Hello,
I am using Xillybus core on Kintex-7 device. The code worked beautifully out of the box, I can run loopback tests. Very impressive piece of work!

One problem:
my Kintex chip has only 4 lanes connected to PCIe. The other 4 lanes are used for different purposes. The Xillybus project seems to assume that all 8 lanes are used for PCIe. Currently it is not a problem since the PCIe core automatically detects that only 4 lanes are used. However, the other 4 GTX transceivers become unusable, since they are included into Xillybus, and I would like to use them for their intended purpose.

I have tried to recustomise the PCIe core provided in Xillybus download package. The project compiles, but when used in the FPGA, the device is not discovered by the computer's BIOS at boot time.

Could you let me know what is the proper way of generating the Xillybus project for 4-lane and also 2-lane PCIe on Kintex-7?
thanks a lot.
Guest
 

Re: generating xillybus core for 2 lanes on Kintex

Postby support »

Hi,

To begin with, there happens to be an out-of-the-box bundle for Kintex with 1x lane. It goes up to 400 MB/s in both directions, if your host supports Gen2 PCIe, or else it's 200 MB/s. If that's good enough for you, just drop a note to Xillybus' support email and you'll get your copy right away.

Moving from 8x to lower rates is somewhat tricky, mostly because reducing the lane width probably involves reducing the application clock (known as bus_clk in Xillybus' user signals interface). This, in turn, requires changing the constraints and some other settings, as I'll detail next. Anyhow, the suggested method to get on top of things is to generate the example design for the x8 PCIe core, and then again for the desired lane width. Please change only the lane width and the application clock frequency in the PCIe endpoint block. Nothing else.

So the first thing to do, is to see how the timing and placement constraints have changed between the two example designs, and track down the related lines in Xillybus' constraint file, and make the changes. This doesn't require an exact understanding of what the constraints mean, but rather sticking to the patterns.

The nontrivial change is editing the instantiation parameters of pipe_clock in xillybus.v (probably PCIE_USERCLKn_FREQ and PCIE_LANE), so that it generates internal clocks that are adequate to the new lane width. The easiest way for this is to synthesize the example project with the desired lane width, and get the values that appear in the synthesis report for the instantiation of the pipe_clock module. Trying to deduce the correct number from the sources is a lost battle.

And lastly, fix the widths of the signals that carry the connections to the physical PCIe pads, in particular in the top level (Xillydemo?) module.

Either way, custom IP cores from the IP core factory can be used. The only thing to note, is that you may not get the warnings when expecting too much bandwidth, since the web application assumes 800 MB/s.

Regards,
Eli
support
 
Posts: 802
Joined:

Re: generating xillybus core for 2 lanes on Kintex

Postby Guest »

Hello Eli,
thanks a lot for sending the 1x version to me. The example works great, I am now adding my logic to it.
One more question if you don't mind:
We have two cards in the system with the identical firmware. That firmware has a single memory interface, 32-bit bus, 16-bit address. However, the driver creates only one file in /dev directory:
/dev/xillybus_mem_32

Question : how do I address one card or the other via that single device file?
thanks a lot.
Guest
 

Re: generating xillybus core for 2 lanes on Kintex

Postby support »

Hi,

If you look in the system log file, you'll see that Xillybus failed to generate the second set of device files, because of a naming clash (it tried to create a device file with a name that already exists). The natural solution for your case is defining udev rules that mangle the device file names, possibly based upon their PCIe address position, so that they are unique and well-defined.

Regards,
Eli
support
 
Posts: 802
Joined:

Re: generating xillybus core for 2 lanes on Kintex

Postby Guest »

Thanks Eli,
we started looking at the udev rules, but were not quite sure we're on the right track.
Thanks for confirming that.
Guest
 


Return to Xillybus

cron