AR# 14241: 4.21 Virtex-II PAR - "FATAL_ERROR:Route:basrtsanity.c:169:1.8 - Process will terminate..."
4.21 Virtex-II PAR - "FATAL_ERROR:Route:basrtsanity.c:169:1.8 - Process will terminate..."
Keywords: basrtsanity, 169, PAR, FX, Y
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.
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: