AR# 32080


12.4/13.4/14.7 Place - Unroutable connections due to BRAM and MULT pairings that over utilize CLB OMUX resources


My design fails during routing with the following message. 

When I examine the signals mentioned in FPGA Editor, I can see that the signals are all driven by block RAM or Mult components. 

What is an OMUX, and why are the signals unroutable?  


WARNING:Route:438 - The router has detected an unroutable situation due to local congestion. The router will finish the 

rest of the design and leave one or more connections as unrouted. The cause of this behavior might be putting too 

much logic into a single CLB. To allow you to use FPGA editor to isolate the problems, the following is a list of (up 

to 10) such congested connections: 

Congestion on : OMUX(32168,-13919) signal : XLXI_1240/XLXI_111/E<31> 

Congestion on : OMUX(32168,-13919) signal : ReadbackProcessor/DSP_Engine/ProgramMem/UD<29> 

Congestion on : OMUX(30309,-16616) signal : XLXI_1240/XLXI_111/E<24> 

Congestion on : OMUX(30309,-16616) signal : XLXI_1240/XLXI_111/E<30> 

Congestion on : OMUX(34245,-16608) signal : XLXI_1240/XLXI_111/E<26> 

Congestion on : OMUX(34245,-16608) signal : ReadbackProcessor/DSP_Engine/ProgramMem/UP<3> 

Congestion on : OMUX(32144,-17271) signal : XLXI_1240/XLXI_111/E<29> 

Congestion on : OMUX(32144,-17271) signal : XLXI_1240/XLXI_111/E<31>


This message is a general purpose message reporting unroutable connections due to local congestion, where there are not enough routing resources available to complete all of the connections. 

This Answer Record applies to the specific case where BRAM and Mults over utilize the available output (OMUX) switchbox paths.

This Answer is a good match for your case only if the message refers to OMUX congestion and the signal names listed correspond to BRAM and MULT outputs. 


The problem is that a BRAM and MULT component pair were placed together in the same CLB tile such that there were more output signals used than available output switchbox paths. 

This is more likely to occur when the design contains wide dual port RAM output busses. 

The placement algorithm for BRAM and MULT components is currently unable to check for this condition by counting the output paths used by the BRAM/MULT pair. 


A possible method by which to work around this issue is to set an environment variable that prevents all BRAM and MULT components from being placed together in the same CLB. 





Linux and Solaris 



For general information about setting ISE environment variables, see (Xilinx Answer 11630)


The placement restrictions introduced by the environment variable might be too strict for the placer to find a successful placement solution.

In that case, the variable should be unset and the BRAM/MULT placement should be manually constrained with the use of LOC, PROHIBIT and/or area group range constraints: 


  • Identify the BRAMs in the design with the widest output buses.
  • Lock those BRAMs to a site (LOC) or group of sites (area group range). The sites used by the placer during the failed placement might be a good starting point.

  • Prevent the MULTs in the design from being placed next to the problem BRAMs by either locking them elsewhere (LOC), prohibiting them from being place in the same CLB (CONFIG PROHIBIT), or by using an area group range to force them to be placed elsewhere. 


Keep in mind the possibility that the design might have no legal placement if there are too many wide BRAM and MULT components. 


A CR is under investigation to handle this situation automatically.

AR# 32080
日期 10/22/2014
状态 Active
Type 综合文章
People Also Viewed