Re: ISE 13.1 corruption in PCF file

bassman59 · ‎02-25-2008

samcossais wrote:

The guy for whom you say it worked have just not tried at all I guess.

My thought, exactly!

----------------------------------------------------------------
Yes, I do this for a living.

andrewjcart · ‎09-16-2010

To correct previous posts, this IS an issue in 14.1. I have seen it happen repeatedly. The .pcf file contains non-ascii data in a few different places. I tried cleaning the project and rerunning the compile and found the same error.

This bug is a huge time-drainer. I hope a fix for this becomes a high priority for 14.2! For me, this is a show-stopper.

Boots

pheles · ‎09-28-2010

Hi,

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.

Cheers,

...meaning "prospect for other FPGA vendors until we have a solution that works for you" ??

I'm pretty sure that once you publish Vivado, then loads of bugs and errors will show up when the wide mass of people starts using it. You have shown how you test your software packages before release! And this is a completely new toolset. It will certainly take some time until we get an existing FPGA project result a working bit file with it.

I'd rather expect you to offer the old and the new workflow in parallel for some time, which includes that you keep track on fixing existing bugs. This one should rise severity up to maximum as the workflow ends with a failure!!

This is a bad joke after all! I can only repeat my first line. If you guys can't learn from loyal costumers, perhaps you will from dropping market shares!!

nvardi · ‎08-12-2009

Can verify that the PCF file corruption still exists in ISE 14.2 whenGlobal Optimiztion is enabled (speed, in this case).

Working on an example for a web case to submit to Xilinx (is it worth the trouble?).

michelcharette · ‎06-07-2012

Yes, I believe it is still very much worth the trouble! Xilinx don't seem to take this issue seriously and it's really hurting my perception of them as a serious FPGA vendor.

rcingham · ‎09-09-2010

The FPGAs are definitely serious.
It's just the tools to develop them that have a slightly risible tendency.

------------------------------------------
"If it don't work in simulation, it won't work on the board."

tsckk · ‎10-25-2012

Hi,

I want to share my experiences with the corrupted pcf file.

This issues occures not only with ISE 13.1 but also 13.2, 14.1 and 14.2, meaning the issues is definitely not fixed. I actually submitted a webcase for my problem. The Xilinx support told me this is a known issue and there are three options to "workaround" the corruption:

1. Run MAP with -global_opt turned off

2. Manually fix the corruption in the .pcf file after MAP and start PAR manually with the fixed .pcf file

3. Use Linux OS

Option 1 is not an option, since the -global_opt is a key MAP option for timing closure in my complex design, it significantly improves the timing score.

Option 2 also is not an option, since I am using the SmartXplorer tool, and, as you all know, with SmartXplorer you cannot manually modify the .pcf file after MAP. Also, SmartXplorer is essential for my design too, since it helps me find the best implementation with the lowest timing score.

Option 3, is not an option either, I need to implement my design under Windows.

It cost me a lot of time to actually figure out what was going wrong, since at first ISE would not even report an error but simply not list the defined timing constraints in the PAR timing report anymore. From my point of view, such a corruption of the .pcf file NEEDS to report an error during PAR. But it only does it randomly.

The Xilinx support furthermore told me, and I quote:

"I would like to apologize for the inconvenience this issue is causing. This is a known issue for which CR #589454 has been filed. Unfortunately, as ISE is being repaced by Vivado, this issue will not be fixed".

Regarding Vivado, I am using a Virtex 5 device and Virtex-5 devivces are not supported by Vivado and also will not be supported. So how am I supposed to get my design running if with this bug, a bug that exists and has not been fixed for several versions AND will not allow me to use an existing Virtex device?

This is unacceptable and causes me a lot of trouble and time! I have been dealing with this for month now and it is frustrating to say the least.

I completely with all the designers that have posted their frustration in this thread.

Regards

Thomas

bassman59 · ‎02-25-2008

tsckk wrote:

Regarding Vivado, I am using a Virtex 5 device and Virtex-5 devivces are not supported by Vivado and also will not be supported. So how am I supposed to get my design running if with this bug, a bug that exists and has not been fixed for several versions AND will not allow me to use an existing Virtex device?

This is unacceptable and causes me a lot of trouble and time! I have been dealing with this for month now and it is frustrating to say the least.

When Xilinx says that a showstopper bug in a toolset isn't going to be fixed, they're essentially saying that those devices which use those tools are essentially deprecated.

----------------------------------------------------------------
Yes, I do this for a living.

avrumw · ‎01-23-2009

Unfortunately, as ISE is being repaced by Vivado, this issue will not be fixed

I am pretty sure the webcase engineer made an error in interpreting the CR status. As you pointed out, Vivado is only for the 7 series devices and onward, and Xilinx is still actively fixing any bugs that occur in ISE. If you have a testcase that still shows this bug in the latest version of the tool, send it to the webcase engineer, and insist that the CR be re-opened (and don't take no for an answer).

Avrum

samcossais · ‎12-07-2009

bassman59 wrote:

tsckk wrote:

Regarding Vivado, I am using a Virtex 5 device and Virtex-5 devivces are not supported by Vivado and also will not be supported. So how am I supposed to get my design running if with this bug, a bug that exists and has not been fixed for several versions AND will not allow me to use an existing Virtex device?

This is unacceptable and causes me a lot of trouble and time! I have been dealing with this for month now and it is frustrating to say the least.

When Xilinx says that a showstopper bug in a toolset isn't going to be fixed, they're essentially saying that those devices which use those tools are essentially deprecated.

This would be a surprise to say the least as Spartan-6/Virtex-6 are not supported by Vivado but still likely to be used even in projects starting right now as the 7 series is not that much available. If the global opt. option is the least of their problems compared to Vivado, then why can't Xilinx just grey out or remove the option ? Anyway, the Xilinx support on this problem is really embarassing.