cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
292 Views
Registered: ‎12-02-2012

PCIe phy part migration

Jump to solution

PG239 stipulates that for FPGA parts that are not supported out of the box by the standalone phy IP, "the IP can then be migrated to the desired part." A later section gones on to say, "In summary, though a limited number of devices are supported by this IP, the generated IP targeting the supported device can be migrated easily to other devices."

Nowhere in the guide however does it explain how to perform this migration. Importing the generated xci into a project targeting the desired different part just sees Vivado lock the IP, after which you can't modify or generate the output for. Changing the part in the xci file itself also doesn't work, since the IP is still treated as unsupported for that particular device. So this being the case, what is the actual procedure for migrating the phy?

1 Solution

Accepted Solutions
Explorer
Explorer
145 Views
Registered: ‎12-02-2012

Re: PCIe phy part migration

Jump to solution

To anyone else whom stumbles upon this topic looking for the same info, I'll lay out the process I went through that appear to have worked.

1) Generate the phy for a supported platform, like the VU9P. Make sure if the option is available to include the transceiver core as an IP inside of the phy IP.

2) Generate the output product, and copy it out.

3) Generate a generic PCIe controller (non-XDMA version) for the actual target part, like a VU13P, using the SAME NAME as what you called the phy, and generate the output product. Make sure you picked all of the same options regarding lanes, speed, etc. The same name is important because the transceiver IP generated uses the name as part of its own naming pattern, so this way you don't need to go into the phy code to change anything.

4) From the generated PCIe controller, grab the contents of ip_0 and use them to overwrite the ip_0 directory in the phy IP. This will get you the correct transceiver locations/constraints.

5) Add the generated source output (including the source file in the synth dir) of the phy plus the copied over transceiver XCI to your project.

6) You now need to reconstruct the constraints. Namely you need the constraints from the ip_NAME.xdc file in the source dir of the original phy IP, and the _late.xdc inside of its synth directory. I think those are the only ones that I pulled from, the transceiver XDC will be picked up automatically once you. Some of the constraints may not work immediately out of the box in terms of finding specified pins since they seem relative to just the generated ip core, so you may need to update them with a modified filter command to pick them out in the new build hierarchy.

The above 'should' work, the generated bitfile I used did link up and enumerate.

View solution in original post

0 Kudos
2 Replies
Highlighted
Xilinx Employee
Xilinx Employee
269 Views
Registered: ‎08-06-2008

Re: PCIe phy part migration

Jump to solution

Please follow the steps below and let us know if it didn't work.

1. Generate the PHY IP for a part that is supported. You could right click on the IP in IP catalog and then select a part from 'Compatible Families' list.

2. After the IP is generated, right click and click on 'Open IP Example Design'.

3. Now change the device by going into 'Settings'.

4. After changing the device,you will see the IP is locked (if the selected device is not supported).

5. Run implementation. You will need to make sure required constraints for the device you have selected are taken care of.

Thanks.

Explorer
Explorer
146 Views
Registered: ‎12-02-2012

Re: PCIe phy part migration

Jump to solution

To anyone else whom stumbles upon this topic looking for the same info, I'll lay out the process I went through that appear to have worked.

1) Generate the phy for a supported platform, like the VU9P. Make sure if the option is available to include the transceiver core as an IP inside of the phy IP.

2) Generate the output product, and copy it out.

3) Generate a generic PCIe controller (non-XDMA version) for the actual target part, like a VU13P, using the SAME NAME as what you called the phy, and generate the output product. Make sure you picked all of the same options regarding lanes, speed, etc. The same name is important because the transceiver IP generated uses the name as part of its own naming pattern, so this way you don't need to go into the phy code to change anything.

4) From the generated PCIe controller, grab the contents of ip_0 and use them to overwrite the ip_0 directory in the phy IP. This will get you the correct transceiver locations/constraints.

5) Add the generated source output (including the source file in the synth dir) of the phy plus the copied over transceiver XCI to your project.

6) You now need to reconstruct the constraints. Namely you need the constraints from the ip_NAME.xdc file in the source dir of the original phy IP, and the _late.xdc inside of its synth directory. I think those are the only ones that I pulled from, the transceiver XDC will be picked up automatically once you. Some of the constraints may not work immediately out of the box in terms of finding specified pins since they seem relative to just the generated ip core, so you may need to update them with a modified filter command to pick them out in the new build hierarchy.

The above 'should' work, the generated bitfile I used did link up and enumerate.

View solution in original post

0 Kudos