Xillybus Virtex-7 Gen3

Questions and discussions about the Xillybus IP core and drivers

Xillybus Virtex-7 Gen3

Postby Guest »

hello

we have been using Xillybus with VC707 board for a long time.
now we are trying to use Xillybus on a custom board having Virtex7 690 FPGA.
the port locations of GT lines and the reference clock are the same as VC707 board.

we downloaded demo bundle for VC709 board and generated a custom core from IP core factory for our custom board.
for core bundle we used "xillydemo-vivado.tcl" tcl command to generate a design.
After the design is generated we copied the files related to Xillybus to a new project.
In the new project we changed the
xillybus.v
xillybus_core.ngc
xillybus_core.v
files with the ones generated at IP core factory.
we modified the location of PCIE_PERST_B_LS port in xillydemo.xdc file with respect to our custom board.

when we run synthesis we get the errors related to port connections of pcie_v7_8x module below

.cfg_mgmt_addr(19'd0),
.cfg_mgmt_write(1'b0),
.cfg_mgmt_write_data(32'd0),
.cfg_mgmt_byte_enable(4'd0),
.cfg_mgmt_read(1'b0),
.cfg_mgmt_type1_cfg_reg_access(1'b0),

.cfg_msg_transmit(1'b0),
.cfg_msg_transmit_type(3'd0),
.cfg_msg_transmit_data(32'd0),c

.cfg_per_func_status_control(3'd0),

.cfg_ext_read_data(32'd0),
.cfg_ext_read_data_valid(1'b1),

since these ports are not activated in demo bundle we get errors.
therefore we comment out these lines and run synthesis and implementation again.
this time we do not get any error.
after the FPGA of custom board is programmed with the .bit file and the PC connected to Xillybus is reseted, the host PC does not recognize Xillybus in device manager.

When we examine the RX and TX line with scope we observe that while the signals driven by FPGA are not static the signals driven by PC are static.

what is our misteke?
do we need to make any changes to PCIe IP or Xillybus files?

Xillybus for Gen3 PCIe runs at 2.5GT/s. Do we have to connect our custom board with Virtex 7 690 to a Gen3 PCIe slot?
Guest
 

Re: Xillybus Virtex-7 Gen3

Postby support »

Hello,

Generally speaking, the preferred way to use Xillybus on a custom project is to add the project-specific source files to the Xillybus demo bundle, so you don't lose all kinds of settings in the transition.

In your case, it appears like you didn't use the demo bundle's PCIe block XCI, neither the constraints (or did you?).

Regarding the port mismatch in pcie_v7_8x, there have been changes very recently in the PCIe block's settings, dropping the features related to these ports exactly. You did right in dropping those pins (you may also download a fresh demo bundle and re-generated the custom IP core). This was necessary to support Vivado 2017.3.

As for PCIe speeds: Any PCIe slot is fine: Gen1, Gen2 or Gen3 (when using the demo bundle's PCIe block as is). The demo bundle indeed sets the lanes' speed at 2.5 GT/s (no point going higher).

Regards,
Eli
support
 
Posts: 777
Joined:

Re: Xillybus Virtex-7 Gen3

Postby Guest »

thank you for your quick answer

I want to clarify my previous post.

we downloaded the current available version of demo bundle and we generated a core from IP core factory.
we generated a new project in order to locate the necessary files from core bundle and core generated by IP core factory.

in order to generate a project of demo bundle, we run the script verilog\xillydemo-vivado.tcl of core bundle.
after a project for core bundle is generated we copied the files of core bundle project below to our new project.
vivado-essentials\pcie_v7_8x.v
vivado-essentials\pcie_v7_8x_pipe_clock.v
vivado-essentials\pcie_v7_vivado_pipe_clock.v
vivado-essentials\xillydemo.xdc
vivado-essentials\pcie_v7_vivado\pcie_v7_vivado.xci

from the files of core generated by IP core factory we copied the files below to our new project.
xillybus.v
xillybus_core.ngc
xillybus_core.v

in our new project we just modified xillydemo.xdc.
we modified location constraint of PCIE_PERST_B_LS port to match our custom board.

we did not change the constraint below since port locations of RX, TX and ref clock signals in out custom board are same with VC709.

set_false_path -from [get_ports PCIE_PERST_B_LS]
set_property LOC IBUFDS_GTE2_X1Y11 [get_cells -match_style ucf */pcieclk_ibuf]

after a .bit file is generated for our new project we program our FPGA and restart the PC connected to FPGA via PCIe Gen2 slot.
However, the PC does not recognize Xillybus as a hardware.

I think we do everything correct. That is why I write this message.

Any help we will appreciate.
Guest
 

Re: Xillybus Virtex-7 Gen3

Postby support »

Hello,

It will be much easier to figure out what's going on if you modify the demo bundle to your board, and not copy files. Even just for the sake of the experiment.

Could you start from a fresh demo bundle, and just modify the pin that is different? If that works, apply the custom IP core. If that works, try to figure out the difference.

The idea is to move gradually from something that works that something that doesn't.

Regards,
Eli
support
 
Posts: 777
Joined:

Re: Xillybus Virtex-7 Gen3

Postby tozkoparan »

hello

thank you for your quick answer
we implemented demo bundle alone only by changing necessary constraints(PCIE_PERST_B_LS location and location of LEDs)
after the PC reset the PC does not still recognize Xillybus as hardware.
can we conclude that there is a connection problem? any suggestion?

best regards
tozkoparan
 
Posts: 15
Joined:

Re: Xillybus Virtex-7 Gen3

Postby support »

Hello,

So we have some kind of progress. If your "custom board" is manufactured by some other hardware vendor, I suggest trying out their test code for PCIe.

If it's your own -- please take a look on the LEDs. Their meaning is as follows:

GPIO LED 0: Heartbeart. Just blinks.
GPIO LED 1: Indicates transmission of data from the FPGA to the CPU
GPIO LED 2: Indicates transmission of data from the CPU to the FPGA
GPIO LED 3: Indicates that the FPGA is waiting for CPU-to-FPGA data to arrive (i.e. there's at least an outstanding request for reading) OR that the Xillybus logic is held reset (on some platforms).

In your case, GPIO LED 3 is of interest, because it stays on while the Xillybus logic is reset, i.e. when the PERST is asserted. Since you've moved this pin, it's the primary suspect. I suggest looking how the LEDs behave on a on the evaluation board that works, and then compare with your own. The pattern should be exactly the same (if you plug both boards to the same hardware).

I don't rule out other possibilities, but this one is the easiest to check.

And in the meanwhile: Is the moving of PERST the only change you've made, compared with the reference design? For example, have you made any changes in with clocking?

Regards,
Eli
support
 
Posts: 777
Joined:

Re: Xillybus Virtex-7 Gen3

Postby tozkoparan »

Hello

thank you for your great support.
after our experiments, we realize that our custom board has some design errors.
we will continue our experiments after board revision.

thank you again for your concern
tozkoparan
 
Posts: 15
Joined:


Return to Xillybus

cron