Implementation

[virujawoor]

Hello,

Im getting error when mapping the design as below

"FATAL_ERROR:Pack:pkistlogicmend.c:1777:1.9.36.7 - Failed to get an output signal on BEL block
XLXI_435/U3/BU2/dbiterr_9.A5LUT in comp XLXI_478/U1/Uart_TxUnit/TxD.   Process will terminate. For technical support
on this issue, please open a WebCase with this project attached at http://www.xilinx.com/support."


Can anybody please help with suggestions?

Best Regards,

Viru Jawoor

[sarithas]

When this error arises, changing "Starting Placer Cost Table" to another value may resolve it.

Check the below screenshot to see the option.

[virujawoor]

Problem has resolved after changing "Starting Placer Cost Table"  value to 2

Thanks for your kind reply.

[virujawoor]

what is the solution to fix this error instead of changing each time "Starting Placer Cost Table" value?

Thanks in advance.

[xrisas1]

I get the same error..

My design is barely filts my Virtex-6 LX240T (91% Slices). The first time I run the tools, I did it with cost table 3 and I got this error. Then I changed the cost table to 2 and the problem was resolved, map and par finished successfully failing timing for just over 1 ns. I tested the resulting bit file, and live hardware testing passed, but I need to correct the timing just to be on the safe side.

Before doing any changes in the code, I had a look on planAhead and confirmed that the tools can probably do better, since out of my 20ns requirement for the clock, on the path that is failing, more than half is consumed on net delay between the first couple levels of logic, so I thought I should stress the tools a bit more. Starting with cost table 4, I tried 10 runs (until CT13) only to see (20 hours later..) that all of them failed with this error.

So, is there another way to address this issue? Or could somebody that can decipher the ISE messages provide an explanation on what might cause this error?

Currently Using ISE 13.4.

Thanks

[bwade]

We have one known oustanding cause for this error that has been fixed for 14.1. The root cause was that RPM (RLOC) constraints were forcing a carry chain into an unaligned state. If you're not sure whether the design contains RPM constraints you can test for this by running Map with the "-ir all" switch to disable RLOC constraints. If you can identify the specific instances involved you can either remove the RLOC constraints from the source or override them in the UCF file:

INST "xyz" USE_RLOC = FALSE;