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!

AR# 14241

4.21 Virtex-II PAR - "FATAL_ERROR:Route:basrtsanity.c:169:1.8 - Process will terminate..."


Keywords: basrtsanity, 169, PAR, FX, Y

Urgency: Standard

General Description:
PAR fails with the following "basrtsanity" error after apparently successfully routing a design:

"FATAL_ERROR:Route:basrtsanity.c:169:1.8 - Process will terminate. To resolve this error, please consult the Answers Database and other online resources at http://support.xilinx.com"

(NOTE: Not all "basrtsanity" errors are the same. This Answer Record is only a potential match for your issue if your failure involves a Virtex-II design that failed after routing was performed. See information below regarding a Perl script that can be used to identify the problem area.)

A "basrtsanity" error occurs when the router has determined that there is a fault in the routing data structures. The exact cause of the fault is not easily determined, so this rather generic error message is printed.

This particular case was caused by a MAP packing bug wherein the packer configured a slice such that there was a conflict between a LUT and an F6MUX for the Y output pin of the slice. The F6MUX needed to use an FX-->Y routethru to reach load pins that could not be reached directly from the FX pin. This conflict lead to the router shorting two signals together on the Y pin, which resulted in the basrtsanity error.



This problem is fixed in the latest 4.2i Service Pack, available at:
The first service pack containing the fix is 4.2i Service Pack 3.


The following Perl script can be run with an NCD file as a command line argument to determine whether an FX/Y conflict exists. The script uses the XDL utility, which requires that a valid Xilinx environment exist in the shell where the script is run. The script will identify any slices containing a conflict.

Once the problem logic is identified, the work-around is to apply an XBLKNM attribute to the LUT involved, which will prevent it from being packed with the conflicting F6MUX. The UCF syntax for this is:

INST "lut_name" XBLKNM = some_name ;

-------------cut here--------------

`xdl -nopips -ncd2xdl $ncd_root[0]`;

open (FILE,"$ncd_root[0].xdl");

# Detect net record
if ($fields[0] eq "net"){

# Detect end of net record
if ($fields[1] eq "#" && $fields[2] eq "net"){

# Detect FX or F5 pin
if ($net eq "1" && $fields[1] eq "outpin" && $fields[3] eq "FX"){

# Search for conflicts
open (FILE2,"$ncd_root[0].xdl");

# Detect Load Type
if ($fields2[0] eq "net" && $fields2[1] eq "$net_name"){

if ($net2 eq "1" && $fields[1] eq "inpin" && $fields[3] ne "FXINA" &&
$fields[3] ne "FXINB"){

# Detect Fanout
if ($fields2[1] eq "#" && $fields2[2] eq "net" && $fields2[3] eq

# Detect component site name.
if ($fields2[0] eq "inst" && $fields2[1] eq "$comp_name"){

# Detect conflicting Y pin.
if ($fields2[1] eq "outpin" && $fields2[2] eq "$comp_name" && $pin_type eq
"FX" && $fields2[3] eq "Y") {

if ($conflict eq "1" && ($bad_load eq "1" || $fanout ne "loads=1")) {
print "An FX/Y conflict has been detected at component $comp_name at site
close FILE2;

AR# 14241
Date Created 03/20/2002
Last Updated 08/20/2003
Status Archive
Type General Article