by support »
Hello,
Unfortunately, the critical warnings issued by Vivado are a bit misleading. The clue to actual problem is in the Tcl log you posted: The part you're migrating to doesn't have a PCIe block on the site required in the pcie_ku.xci file. Vivado reacts to this by messing up the parameters in general (those related and those which are not).
This leads to enabling certain PCIe features which xillybus.v Verilog module doesn't expect, hence the critical warnings on unconnected pins.
How to solve this: First, figure out the location of the PCIe block that works with the MGTs you intend to use. Alternatively, open the PCIe block's configuration in Vivado, and look at the selected "PCIe Block Location". Even if it's not correct for your board, at least it's a legal site on the targeted FPGA.
Then start from scratch: Unzip a fresh demo bundle, and change the part in main.tcl file, like you did before. But in addition, edit vivado-essentials/pcie_ku/pcie_ku.xci as follows: Find the assignment for PARAM_VALUE.pcie_blk_locn, and change the site to one that is legal for the FPGA. For example, from X0Y0 to X0Y2.
Then run the Tcl script for generating the project. The critical warning on updating pcie_ku should not be there anymore. Vivado will however update additional parameters like MODELPARAM_VALUE.gen_x0y0_xdc and PARAM_VALUE.gen_x0y0 in the XCI file, but this is done properly during the project generation. There's no need to edit these manually.
Note that it's not good enough to make this correction after the project has been created with the Tcl script. The messup of the PCIe block happens when the Tcl script is executed with an illegal site for the PCIe block.
And a final note: What about generating the project and then changing the FPGA part? Exactly the same problem: The PCIe block is automatically locked when the FPGA part is changed. The only way to unlock it is "upgrading" the IP, which leads to the same messup of its parameters. The only difference is that the related warnings are more visible, as they are issued in response to manual actions.
Hope you'll have a smooth run this time.
Regards,
Eli
Hello,
Unfortunately, the critical warnings issued by Vivado are a bit misleading. The clue to actual problem is in the Tcl log you posted: The part you're migrating to doesn't have a PCIe block on the site required in the pcie_ku.xci file. Vivado reacts to this by messing up the parameters in general (those related and those which are not).
This leads to enabling certain PCIe features which xillybus.v Verilog module doesn't expect, hence the critical warnings on unconnected pins.
How to solve this: First, figure out the location of the PCIe block that works with the MGTs you intend to use. Alternatively, open the PCIe block's configuration in Vivado, and look at the selected "PCIe Block Location". Even if it's not correct for your board, at least it's a legal site on the targeted FPGA.
Then start from scratch: Unzip a fresh demo bundle, and change the part in main.tcl file, like you did before. But in addition, edit vivado-essentials/pcie_ku/pcie_ku.xci as follows: Find the assignment for PARAM_VALUE.pcie_blk_locn, and change the site to one that is legal for the FPGA. For example, from X0Y0 to X0Y2.
Then run the Tcl script for generating the project. The critical warning on updating pcie_ku should not be there anymore. Vivado will however update additional parameters like MODELPARAM_VALUE.gen_x0y0_xdc and PARAM_VALUE.gen_x0y0 in the XCI file, but this is done properly during the project generation. There's no need to edit these manually.
Note that it's [b]not good enough[/b] to make this correction after the project has been created with the Tcl script. The messup of the PCIe block happens when the Tcl script is executed with an illegal site for the PCIe block.
And a final note: What about generating the project and then changing the FPGA part? Exactly the same problem: The PCIe block is automatically locked when the FPGA part is changed. The only way to unlock it is "upgrading" the IP, which leads to the same messup of its parameters. The only difference is that the related warnings are more visible, as they are issued in response to manual actions.
Hope you'll have a smooth run this time.
Regards,
Eli