02-12-2015 11:45 AM
INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate. For technical support on this issue, please open a WebCase with this project attached at http://www.xilinx.com/support.
So the project started doing this on 14.5 so I upgraded to 14.7 but same problem. Yes I'm using the webpack and it's understandable that xilinx is expecting users to find their own logic problems but what am I suppose to do about this kind of error? And without webcases how will xilinx ever find out about this bug?
I will begin the arduous task of trial and error to try and find the cause.
I am so unhappy,
02-12-2015 06:22 PM
02-12-2015 12:46 PM
The stock answer is to contact your FAE (usually through your distributor) if you need faster help.
In the meantime, you might try to compile the design using ISIM and see if you get error messages instead of a crash.
In my experience this sort of XST crash often comes due to connectivity errors between modules, like mis-matched port names, types or widths. Common causes are bad connections to .ngc modules like most Coregen IP, or between modules of different source language (VHDL instantiating Verilog or vice versa).
02-12-2015 01:26 PM
For bugs like this, the forums are the right place. Every post is read by a Xilinx employee.
Unfortunately, ISE is now in "long term maintenance mode" as it is replaced by Vivado for all products of 7-series and newer. So support (generally) for ISE is here on the forums, or through your distributor or Xilinx FAE.
The post here by other users is valuable, as they have seen what you have, and traced it to the cause they refer to.
02-12-2015 01:51 PM
It simulates fine in ModelSim and there were only some code changes, no new IP added. So I'm just going to have to commenting out sections and changing the logic around a bit to see if I can narrow it down. Thanks for responding.
02-12-2015 06:22 PM
02-12-2015 08:48 PM
I found that if I commented out one signal in a record it would synthesize. After spending quite some time reworking the logic on that signal I decided it was probably was not the problem. I then spent some time eliminating synthesis warnings such as a couple of incomplete sensitivity lists, hand full of inadvernent latches, and a few width mismatches on some assignments. Now it synthesizes. So I'm good for now. Thanks to the people who responded.
02-16-2015 05:02 AM - edited 02-16-2015 05:03 AM
Hi @rayhaynes ,
Please close this thread to your findings.
06-21-2017 04:50 PM
This is a late response but if anyone who run across this here is what I found. I'm using a large record for cpu readback of bits. Each module shares the same record with the whole record set to high 'Z' at the top of the file. Then elements in the record are driven as required in each module. The problem I was having with a synthesis error was caused by having an element in the recorded that was driving anywhere in the design. It didn't happen always but once it did it was persistent. Deleting that unused element would fix the error. This appears to be a bug as not driving an element is not illegal.