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,
Internet Explorer 11,
Safari. Thank you!
AR# 23363: ISE 14.7 MAP - Master Answer Record for MAP application crashes
ISE 14.7 MAP - Master Answer Record for MAP application crashes
My design crashes during the mapping stage of the implementation tools.
Why does this happen, and what can I do to avoid it?
The error message does not indicate the problem.
Answer Record will address the general issue of MAP application
crashes, what they are, how to investigate them, and how to report them
to Xilinx Technical Support.
What is a MAP crash?
A MAP crash is a sudden unexpected application failure. When it occurs, one of several generic failure messages is printed:
Segmentation fault (core dumped)
DeleteInterpProc called with active evals
Why does the MAP crash message not indicate what is wrong?
A crash, by definition, is a situation where an application fails catastrophically with no opportunity for self diagnosis.
No information is available except for the observable circumstances of the crash.
are always software bugs, but they often occur due to something unusual
or unexpected in the input design where a DRC error would be the
This situation can be contrasted with other
"FATAL_ERROR" situations where, although a fatal condition has been
detected, the application is still running and is able to report
information relevant to the failure condition.
How can I investigate a MAP crash?
It is very useful to identify the phase of MAP involved when the crash
occurs. This information can provide a basis for understanding the root
cause of the failure. For example, if the crash occurs during the
"Running directed packing... " phase of MAP and you have just added some
MAP packing constraints to the design, this is a strong indication that
the new constraints are related to the crash failure. If the crash
occurs during the "Running timing-driven packing... " phase, a sequence
of numbered placement phases are run. Make a note of the placement phase
Examine the NGDBUILD and MAP report files (.bld and
.mrp) for warning messages further upstream. Often crashes are triggered
by unexpected and invalid circuit configurations. There are often
warning messages in prior phases that can provide some insight into the
Run MAP with different command line options to
see if there is a dependency. In particular, if the failing phase is
"Invoking physical synthesis ...", try turning off one or both of the
physical synthesis related options; -logic_opt and
-register_duplication. The -logic_opt option corresponds to the
"Combinational Logic Optimization" option in Project Navigator. If the
failure occurs after "Running timing-driven packing... " and during one
of the subsequent placement phases, try running the design with timing
driven packing (-timing) disabled.
users might be unfamiliar with the phases involved because the MAP
messages scroll by quickly in a small window and MAP does not save a log
file (this will be added in ISE 9.1i).
It can be helpful to rerun MAP from the
command line using the command listed near the top of the MAP report
(.mrp). You can create your own log file by running a MAP command and
"piping" the output to the "tee" command so that messages appear on the
screen and also are saved in a file.
map -o test.ncd test.ngd | tee map.log
Can anything be done to avoid a MAP crash?
1. Check the Answers Database for known problems. The Answer Records often provide work-arounds. 2. Try variations in the switch options. 3. Install the latest service pack, if you have not already: http://www.xilinx.com/xlnx/xil_sw_updates_home.jsp 4. Try a different platform, if available. Crashes are sometimes Windows-only or Linux-only. 5. Open a WebCase and ask to have your crash investigated. Be prepared to provide a test case for the investigation.
How should I use Answer Record searches to look for my MAP crash issue?
the Answers Database for Known Issues involving the same phase. For
example if MAP is crashing in the "Mapping design into LUTs..." phase, a
search of 'map crash "Mapping design into LUTs..." ' finds four Answer
Records, two of which specifically mention this phase as the failure
point. If you are running 8.1i software, only one Answer Record (Xilinx Answer 22999)
is a good match. If you are running a version later than 8.1i sp3, none
of the Answers are a good match and we are dealing with a new issue
that should be reported to Xilinx Technical Support. If the failure
occurs during a placement phase, search for known problem in that phase
for both MAP and PAR.
I have found an Answer Record that
matches my problem, but it claims that the problem was fixed in an
earlier revision of the software than the one I am using. This is very
frustrating. What does this mean? Has the old problem come back?
you are seeing a failure mode identical to a problem that is reported
to be fixed, then your problem is almost certainly not the exact same
issue. It might be a related issue and might respond to the same
work-arounds, or it might only share the same general failure mode.
How should I report a MAP crash to Xilinx Technical Support?
prepared to identify the phase that is failing. It helps to provide the
command line involved and all of the messages that appear on the screen.
Consider that MAP runs many different phases, including synthesis and
placement algorithms. The sooner the phase is identified, the sooner the
problem investigation can begin. It might be necessary to
provide a test case to investigate the failure. Ideally, the entire
project directory can be provided. While the NGD file can be used to
reproduce a MAP failure, it is not possible to test MAP constraint
work-arounds without netlist source and constraint files.