UPGRADE YOUR BROWSER

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..."

Description

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.

Solution

1

This problem is fixed in the latest 4.2i Service Pack, available at:
http://support.xilinx.com/support/techsup/sw_updates
The first service pack containing the fix is 4.2i Service Pack 3.

2

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--------------
#!/usr/local/bin/perl5

@ncd_root=split(/\./,$ARGV[0]);
`xdl -nopips -ncd2xdl $ncd_root[0]`;

open (FILE,"$ncd_root[0].xdl");
while(<FILE>){
chomp;
@fields=split(/\s+/);

# Detect net record
if ($fields[0] eq "net"){
$net_name=$fields[1];
$net="1";
}

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

# Detect FX or F5 pin
if ($net eq "1" && $fields[1] eq "outpin" && $fields[3] eq "FX"){
$comp_name=$fields[2];
$pin_type="$fields[3]";
$bad_load="0";
$conflict="0";

# Search for conflicts
open (FILE2,"$ncd_root[0].xdl");
while(<FILE2>){
chomp;
@fields2=split(/\s+/);

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

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

# Detect Fanout
if ($fields2[1] eq "#" && $fields2[2] eq "net" && $fields2[3] eq
"$net_name"){
$fanout=$fields2[4];
$net2="0";
}

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

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

}
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
$site_name.\n";
}
close FILE2;

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