03-15-2012 06:17 AM
1. Run Synthesis/Translate/Map without -global_opt in the Map Process Properties window.
2. From the resultant PCF, note both the TIMEGRP identifier(s) and matching Timing Constraints. For instance, from a Win XP Command window:
find TIMEGRP *.pcf > timegrp.txt
3. In the Map Process Properties window, select -global_opt speed.
4. Rerun Map.
5. Open the PCF in a text editor. Correct the corrupted TIMEGRP identifier(s), and add the Timing Constraints just above the 'SCHEMATIC END;' line, and save the file.
6. Run Place & Route. This should also run the Static Timing Analysis.
I hope it does you more good than it did me - the Timing Score increased significantly over the non-optimised version! So, I will have to add in a pipeling stage and rework my FSM to suit after all.
"If it don't work in simulation, it won't work on the board."
05-14-2012 01:41 AM
Gentlemen at XILINX,
I am just about evaluating the new software, and found that this issue is still not resolved with XILINX ISE14.1!!
We could go the way patching the .pcf file whenever this issue appeared for some time, as we apply FPGA's only supported in ISE13, but this is not acceptable to do this on a wider scale!
Take these issues serious as alot other developers complain about the same thing!
05-16-2012 03:58 AM
This problem will surely not occur with Vivado, which is the new tool, as it's a completely different set of algorithms.
The release of ISE 14.2 will nearly complete and so I doubt that the problem will be fixed in this version.
If you want you can open a webcase with your test project and we'll see what the developers will say.
05-16-2012 04:29 PM - edited 05-16-2012 04:33 PM
Why do you expect us to believe that? This is becoming a joke and I am extremely frustrated that Xilinx have not fixed this problem yet, while lying to us about it. The workaround is great, but it doesn't work when you're using SmartXplorer which I have to use for most of my projects.
Back in May last year paullee3 posted:
This is a known issue, CR has been filed, it is scheduled to be fixed in future release, meanwhile, please manually revise the pcf content to get around the issue.
At this moment, Xilinx target this fix in 13.3.
Xilinx 13.3 rolls around and still no fix. graces then posts:
The issue is not seen in 14.1.
And yet it is. Are you guys simply trying to brush this bug under the carpet? Have you filed it under WONTFIX? You can't possibly expect us to keep waiting for a fix (and paying for licenses to get newer versions of the software) when you obviously have no idea.
05-17-2012 11:38 PM
Well I agree with scollison.
Don't make us lose our time by telling us it is solved when it's not. In my case I am able to fix it everytime by editing pcf but it's a pain in the ass and I'm simply not using it now. However, everytime you tell us it's fixed so I have a try and it's actually not.
I know some bugs happen to be hard to solve, but still, I hope you understand this is really disappointing and frustrating.
05-18-2012 02:12 AM
I read through the CR notes again this morning and I can see that the developers couldn't reproduce the problem with ISE 14.1 using the test case provided. Please note that when a CR is filed, the developers set a tentative release version with the possible fix but the release version may change after investigation.
I've checked the internal notes in the AR http://www.xilinx.com/support/answers/41015.htm and it looks like IT MAY be updated soon with the current status.
06-07-2012 11:25 AM
I had the issue with 13.4, upgraded to 14.1 and the problem is still there. For one guy here migrating to 14.1 seemed to do the trick but he may have just been lucky, because I'm still seeing this corruption in PCF file and manual editing of this file is not an option for me.