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:
Also seen in some instances is the following messaging. This is an indication of an unroutable connection.
Unroute Type 1 : Site pin does not reach interconnect fabric:
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.
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_objects [get_bel_pins GTHE3_COMMON_X0Y3/GTHE3_COMMON/QPLL0OUTCLK]