cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
stuartten
Observer
Observer
2,570 Views
Registered: ‎11-08-2013

[DRC RTRES-2] Global clock nets are using local routing resources

Jump to solution

Hi,

I'm implementing a very simple PCIe test design on the KCU116 eval board using Vivado 2017.4.1. During bitstream generation I get a DRC error as follows:

 

[DRC RTRES-2] Global clock nets are using local routing resources: Global clock nets are using local routing resources. 1 net(s) have at least one node with COST_CODE_NAME equal to BOUNCEACROSS or INTENT_CODE_NAME equal to NODE_DOUBLE, NODE_HLONG, NODE_HQUAD, NODE_SINGLE, NODE_VLONG, or NODE_VQUAD. This situation occurs when a global clock net must enter a clock region where all global clock routing resources are occupied. Check the report from report_clock_utilization to determine which clock regions are traversed by the problem net and use floorplanning or other physical constraints to ensure a maximum of 24 global clock nets occupy each clock region. The problem net(s) are sysClock100.

 

Section 7 of the clock utilization report (attached) indicates that no local clock resources are being used. What does this DRC error mean and what might I have done to generate it?

 

Thanks.

0 Kudos
1 Solution

Accepted Solutions
stuartten
Observer
Observer
2,938 Views
Registered: ‎11-08-2013

Hi @marcb.  I think I found the problem.  I had the wrong clock signal going into the .sys_clk input of the Xilinx PCIe IP block.  Rather than the .ODIV2 output of the same IBUFDS_GTE4 whose .O output is sourcing the .sys_clk_gt input, I was using a generic global clock.  This forced a routing violation since this clock is not a legal source for .sys_clk.

 

Thanks for your help.  I believe I'm past this issue now.

 

Stuart

View solution in original post

0 Kudos
5 Replies
marcb
Moderator
Moderator
2,540 Views
Registered: ‎05-08-2012

Hi @stuartten. Was the report_clock_utilization command entered with a routed design? It looks as though sections 6 and 7 of the report are not populated, so it is possibly a post-opt_design netlist.

 

The RTRES-2 would mean that the router unexpectedly needs to use local resources to reach a particular load. The nodes listed are non-global

 

This might mean that the router had no other choice but this path, but would help to look at the path. The nodes from the DRC can be selected from the device view with the below command.

 

select_objects [get_nodes -filter {INTENT_CODE_NAME==NODE_DOUBLE ||  INTENT_CODE_NAME==NODE_HLONG || INTENT_CODE_NAME==NODE_HQUAD || INTENT_CODE_NAME==NODE_SINGLE || INTENT_CODE_NAME==NODE_VLONG || INTENT_CODE_NAME==NODE_VQUAD  } -of [get_nets   {net_name}]]

---------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------
stuartten
Observer
Observer
2,522 Views
Registered: ‎11-08-2013

Hi @Anonymous, thanks for the quick response. You were right in that the clock utilization report I sent was from the synthesized design. Attached, please find a new report generated from the routed design. While this latter report certainly has more information, it doesn't mean much to me. I don't see any clock regions in which resource utilization is anywhere near capacity.

 

BTW, the query you suggested was not fruitful. Here are the results:

WARNING: [Vivado 12-507] No nets matched 'net_name'.
WARNING: [Vivado 12-2683] No nodes matched 'get_nodes -filter {INTENT_CODE_NAME==NODE_DOUBLE || INTENT_CODE_NAME==NODE_HLONG || INTENT_CODE_NAME==NODE_HQUAD || INTENT_CODE_NAME==NODE_SINGLE || INTENT_CODE_NAME==NODE_VLONG || INTENT_CODE_NAME==NODE_VQUAD } -of [get_nets net_name]'

 

What now?

0 Kudos
marcb
Moderator
Moderator
2,505 Views
Registered: ‎05-08-2012

Hi @stuartten. Thanks for the updated repot. I did not see any indication that the global resources are oversubscribed.

 

Is the design checkpoint available to send? This would investigate the issue further. I would be looking to find what path, and what loads are involved. This might help to identify how to resolve the issue. pre-routing the net "route_design -net [get_nets <name>]" could avoid the issue.

 

 

---------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------
0 Kudos
stuartten
Observer
Observer
2,939 Views
Registered: ‎11-08-2013

Hi @marcb.  I think I found the problem.  I had the wrong clock signal going into the .sys_clk input of the Xilinx PCIe IP block.  Rather than the .ODIV2 output of the same IBUFDS_GTE4 whose .O output is sourcing the .sys_clk_gt input, I was using a generic global clock.  This forced a routing violation since this clock is not a legal source for .sys_clk.

 

Thanks for your help.  I believe I'm past this issue now.

 

Stuart

View solution in original post

0 Kudos
syedz
Moderator
Moderator
2,479 Views
Registered: ‎01-16-2013

@stuartten,

 

Thanks for the update! Glad to know that the issue is resolved. Can you please close this thread by marking your above post as "Accept as Solution" 

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos