cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rkfournier
Adventurer
Adventurer
1,347 Views
Registered: ‎05-09-2018

DRC Failure on PCIe IP Implementation

Jump to solution

Vivado 2018.2 implementation is producing the following DRC Required Pin error while implementing the PCIe IP in an Artix-7 design. The example design compiles fine with the same source files, so I am not sure why this error is appearing. In the real design, all four GTPs are being used, so maybe there is a conflict with the GTP PLLs.

Any thoughts on this error? Also, how can I determine which GTP PLL is being used by the PCIe core?

  • [DRC REQP-49] connects_GTGREFCLK0_ACTIVE_connects_GTGREFCLK1_ACTIVE: GTPE2_COMMON cell pciex1_gen2_inst/U0/inst/gt_top_i/pipe_wrapper_i/pipe_lane[0].pipe_quad.gt_common_enabled.gt_common_int.gt_common_i/qpll_wrapper_i/gtp_common.gtpe2_common_i: Use of the GTGREFCLK is reserved for test purposes only. This has the lowest performance of the available clocking methods and can degrade transceiver performance.
0 Kudos
Reply
1 Solution

Accepted Solutions
venkata
Moderator
Moderator
1,293 Views
Registered: ‎02-16-2010

@rkfournier

I find your approach to using "Shared logic in the example" option is the right approach.

With GTP_COMMON instance, there are two PLLs available. You can connect PCIe to PLL0 and the remaining GTPs to be driven by PLL1. The ports and attributes to control both the PLLs are independent. So you can generate the IP example designs individually and update one of the instances to have the required attributes for both the designs and connect the PLL ports as required.

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------

View solution in original post

0 Kudos
Reply
7 Replies
venkata
Moderator
Moderator
1,327 Views
Registered: ‎02-16-2010

@rkfournier

The DRC error will be reported when fabric clock is connected to GT reference clock input. The recommendation is to have the GT reference clock generated on the board. With Artix-7 GTP, there is only one GTP_COMMON instance in each quad. If the target device you chose has only one quad, PCIe will be using the GTP_COMMON instance inside this quad.

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Reply
rkfournier
Adventurer
Adventurer
1,321 Views
Registered: ‎05-09-2018

Thanks!

I am a little confused though. I have the PCIe instance that uses the GTP common, but I also have the remaining three GTPs that also want to use the GTP common.

How do I configure my design so that I can use all four GTPs? 

Note: the PCIe system clock and GTP reference clock are both 100 MHz.

0 Kudos
Reply
rkfournier
Adventurer
Adventurer
1,320 Views
Registered: ‎05-09-2018

Never mind!

I went back and recreated both IP modules so that the shared logic is in the example design. This way I can connect both to the GTP common.

rkfournier
Adventurer
Adventurer
1,301 Views
Registered: ‎05-09-2018

Do you have any recommendations as to how to merge the PCIe IP with the GTP transceiver IP?

I need the PCIe to support 5 gigabits/second and the other three GTPs to support 2.5 gigabits/second.

0 Kudos
Reply
venkata
Moderator
Moderator
1,294 Views
Registered: ‎02-16-2010

@rkfournier

I find your approach to using "Shared logic in the example" option is the right approach.

With GTP_COMMON instance, there are two PLLs available. You can connect PCIe to PLL0 and the remaining GTPs to be driven by PLL1. The ports and attributes to control both the PLLs are independent. So you can generate the IP example designs individually and update one of the instances to have the required attributes for both the designs and connect the PLL ports as required.

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------

View solution in original post

0 Kudos
Reply
bhall0107
Adventurer
Adventurer
565 Views
Registered: ‎11-13-2018

Hello,

I am getting the same error for the XDMA example design for the Artix-7. I tried enabling both include shared logic in example design options, but during bitstream generation, the error still occurs. 

After opening the XDMA example, what would I need to change to avoid this error? All I've added was a clocking wizard module because the board that I'm using (AC701) has a 200 MHz oscillator and I want the reference clock into the PCIe/DMA bridge to be 100 Mhz.

Thanks in advance for your help. 

Brad

0 Kudos
Reply
bhall0107
Adventurer
Adventurer
505 Views
Registered: ‎11-13-2018

Just to be clear, I was trying to implement the example design for XDMA on the AC701 using Vivado 2019.2. I got rid of this error by constraining sys_clk_n and sys_clk_p to E11 and F11. That was a mistake on my part. I have not been able to get the example design working yet. Please see https://forums.xilinx.com/t5/PCIe-and-CPM/AC701-PCIe-Example-Design-Problems/m-p/1075926#M15773 for more information on what I've tried.

Did you select both Include Shared Logic (Transceiver GT_Common) in example design and Include Shared Logic (Clocking) in example design?

Best,

Brad

0 Kudos
Reply