AR# 66823


Vivado - Overcoming routing issues with unroutable connectivity


This article covers how to understand routing errors, and methods for overcoming routing issues in Vivado designs.



With routing errors, the route_design log will indicate such errors with the following messaging:

ERROR: [Route 35-7] Design has 4 unroutable pins, potentially caused by placement issues.

ERROR: [Route 35-1] Design is not completely routed. There are 32 nets that are not completely routed.

Also seen in some instances is the following messaging. This is an indication of an unroutable connection.
The "does not reach interconnect fabric" messaging can also indicate a dedicated connection is being misused.
For example, a pin with a dedicated connection has limited connectivity to other pins where the two pins connected are not meant to have such a connection:

Unroute Type 1 : Site pin does not reach interconnect fabric:

-----Num Open nets: 1
-----Representative Net: Net[19474] u_ddr4_mem_intfc/u_mig_ddr4_phy/inst/u_ddr_iob/genByte[1].u_ddr_iob_byte/genBuf[6].IO_BUFDS/OBUFTDS/I_B
-----IOB_X0Y19/OUTB_B -> IOB_X0Y20/OP
-----Driver Term: u_ddr4_mem_intfc/u_mig_ddr4_phy/inst/u_ddr_iob/genByte[1].u_ddr_iob_byte/genBuf[6].IO_BUFDS/OBUFTDS/INV/O Load Term [53197]: u_ddr4_mem_intfc/u_mig_ddr4_phy/inst/u_ddr_iob/genByte[1].u_ddr_iob_byte/genBuf[6].IO_BUFDS/OBUFTDS/N/I
Driver Pin does not reach Interconnect fabric within 5 hops.
Pins Reached within 5 hops from Driver

Narrowing Down the issue

The best way to find the correct and expected connectivity is to check the specific User Guide with information about the primitive used. For instance, the SelectIO Resources Guide will have information concerning the expected I/O primitive pin connections, and the Transceivers Guide will have information on specific GT pins. A change in logical connectivity would be needed if the current connection does not match that of the User Guide for a specific pin, and the messaging is indicating that the connection is unroutable.

Some routing errors are caused by contention for specific routing resource and can be related to congestion. One way to find this contention (or congestion), is to take a net that is listed within the report_route_status as not being routed, and routing this individually with the rest of the design unrouted. If this routes, then this would indicate contention for the same routing resource. For congestion specific routing issues, please see (Xilinx Answer 66314) for more information on how to overcome congestion. Congestion should be evident from the route_design messaging which should include information on congestion such as a [Route 35-448] message.

To better understand the routing problem for a specific net, it is helpful to verify the ROUTE_STATUS property of that net. (Xilinx Answer 56424) has information on each value for the ROUTE_STATUS property.

Constraints related issues - Constraints can be the source of routing conflict as they can constrain instances so that their pin to pin connectivity is unroutable.

Conflicting Constraints - (Xilinx Answer 65502) describes conflicting constraints where an IOB=TRUE is used as well as LOC=OLOGIC_XxYy of a FF driving an OBUFT site. 

In this case it is important to take a look at the constraints of both instances of a pin to pin connection with a routing error, as conflicts like this might be seen.

Conflict for Resources - Routing contention is a common cause of routing errors. This happens when there are two or more logical nets that need to use the same physical routing resource.

Unanchored IODELAY conflict - (Xilinx Answer 62127) describes a conflict for resources. In this case, an IODELAY cell that requires routing resources to and from the fabric is placed in a location where these routing resources will be used by other logic. 

The resolution here is to remove the contention by separating the logic that requires the same routing resources into different I/O tiles.

Dedicated Connections - A common reason for routing errors is having logical pin to pin connectivity, where one of the pins is limited as to the type of pins it can connect to such as I/O or GT connections. Connecting to a pin where there is no routable path will cause a routing error.

Dedicated GT Connections - The following messaging is seen from a GT configuration leading to a routing error. The pin to pin connectivity is unroutable and the logical design in this case needs to be adjusted.

[Route 35-7] Design has 4 unroutable pins, potentially caused by placement issues.

The intended connection in an UltraScale device was a GT COMMON output QPLL0OUTCLK driving a BUFG_GT.

To verify the connectivity relating to dedicated connections such as Transceivers and other I/O sites, the pin to pin path can be traced. 

This is not recommended for fabric/SLICE connections because of the number of possible connections. Below is an image that shows this process.

  • Select one of the pins as your "Start Pin" (try starting with the pin that looks to have the least connectivity).
select_objects [get_bel_pins GTHE3_COMMON_X0Y3/GTHE3_COMMON/QPLL0OUTCLK]
  • Zoom to this pin (F9). With the Routing Resources selected, select the connected wire/node. Use (F9) again to view the full node length, then zoom in on the next connection point.
  • Keep following the routing nodes until a circular Pip connection is found. From this point, the Pips tab of the Properties window will show the possible connections. Selecting any of these will select the next node.
  • Try following to the "Final Pin". In this case the available endpoints are four different QPLL0CLK pins on different GTHE3_CHANNEL sites. This means that the intended connection to a BUFG_GT is not possible.

AR# 66823
Date 08/19/2016
Status Active
Type General Article
People Also Viewed