UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Scholar helmutforren
Scholar
518 Views
Registered: ‎06-23-2014

Timing failure related to PCI Express endpoint, K7 325T vs 160T

Jump to solution

I'm using Vivado 2018.1, System Verilog, KC705 dev board with 325T FPGA, and custom target board with 160T FPGA, Xillybus, and PCI Express endpoint v3.3.

 

I have a project that builds fine and meets timing whenever I build it for the 325T that's on the KC705.  However, when I change to the 160T that's on our custom target board, the project no longer meets timing.  I believe the problem is due to EITHER the placement of something or the lack of a clock constraint.

 

Note that the KC705 solution uses 8 PCIe lanes.  The custom board uses only 4 PCIe lanes, and it unfortunately uses the non-recommended lanes 0-3 out of 8 rather than 4-7 out of 8.  I'm still working on a clean xdc way to address this.  For now, after recustomizing the Xilinx PCIe v3.3 IP, I go manually change the placement of gtxe2_channel_i's from GTXE2_CHANNEL_X0Y7...X0Y4 to GTXE2_CHANNEL_X0Y3...X0Y0.  When I was working with the Xilinx PCIe v3.3 example project, this edit did the job sufficiently.  That example project built and my linux host recognized the target board via lspci.


However, now that I have additional RTL in the project, it no longer meets timing.  I'm wondering if, having moved the location of the GTX's being used, I need to also move something else, and this will allow timing to be met.  Alternatively, I see that my single failing route is involving an MMCM in a pipe_clock module.  I wonder if my problem is failing to set a clock constraint, or if my moving things around has moved a the cells out from under the auspice of an existing clock constraint.  Finally, if I must, I can look at slowing down some clocks in the configure of the PCIe v3.3 IP, but I'd rather not do that.

 

While it's just a single signal that fails timing, it seems to be involved with both a 125MHz clock and a 250MHz clock such that it appears twice in the timing report, as two different paths with different hold time failures.  I'll attach BOTH timing summaries.

 

Note that the path #181 in question only takes 0.513ns, but the slack is -0.258.  In order to get non-negative slack, this path would have to take an impossible 0.255ns.  I call that impossible after seeing how short and simple the route is. It's a single FDRE with low fanout over short distance.  The solution must lie outside of the path itself.

 

[EDIT: Note that this signal appears in the source file pcie_k7_vivado_pipe_clock.v and has "(* ASYNC_REG = "TRUE", SHIFT_EXTRACT = "NO" *)" specified.  Source attached. Does this perhaps mean that this signal is not supposed to meet timing?  I would think the source would also lead to removing the timing failure.  Otherwise I've been using set_false_path constraint whenever I cross clock boundaries...]

 

 

Path 181 Timing Summary.jpg
Path 61 Timing Summary.jpg
0 Kudos
1 Solution

Accepted Solutions
Adventurer
Adventurer
512 Views
Registered: ‎06-10-2014

Re: Timing failure related to PCI Express endpoint, K7 325T vs 160T

Jump to solution

Hello,

 

In the XDC file provided in Xillybus' bundle, there are these following two lines (adopted from Xilinx' example design):

 

set_false_path -to [get_pins -match_style ucf */pipe_clock/pclk_i1_bufgctrl.pclk_i1/S0]
set_false_path -to [get_pins -match_style ucf */pipe_clock/pclk_i1_bufgctrl.pclk_i1/S1]

 

So the failing path should have been ignored. Have you dropped these lines from your XDC file? Or else, why aren't they in effect?

 

Regards,

   Eli

0 Kudos
2 Replies
Adventurer
Adventurer
513 Views
Registered: ‎06-10-2014

Re: Timing failure related to PCI Express endpoint, K7 325T vs 160T

Jump to solution

Hello,

 

In the XDC file provided in Xillybus' bundle, there are these following two lines (adopted from Xilinx' example design):

 

set_false_path -to [get_pins -match_style ucf */pipe_clock/pclk_i1_bufgctrl.pclk_i1/S0]
set_false_path -to [get_pins -match_style ucf */pipe_clock/pclk_i1_bufgctrl.pclk_i1/S1]

 

So the failing path should have been ignored. Have you dropped these lines from your XDC file? Or else, why aren't they in effect?

 

Regards,

   Eli

0 Kudos
Scholar helmutforren
Scholar
451 Views
Registered: ‎06-23-2014

Re: Timing failure related to PCI Express endpoint, K7 325T vs 160T

Jump to solution

SOLVED.  Thanks very much, @billauer .  Those set_false_path's got lost in translation from 325T to 160T.  Well, I should have done a more thorough comparative analysis of the xdcs than I did.  At least I did learn enough that I was correct in thinking the timing there shouldn't matter.

0 Kudos