Implementation

[radnorc]

Well, one issue is this one.

Another issue is:

When sometimes some signal between some logic reported by timing violation, and i fix it, but removing it adding FFs etc. Then i run the whole implementation again, and then PAR continues yelling about that signal again. however, that signal doesnt exist anymore, neither in declaration nor in a code. That thing goes on even after i choose clean up project files and reimplement. It goes away only when i close and reopen ISE.

Another thing i noticed is, sometimes near the translate process the ISE just closes, or for example when implementation completed, and i want to go to static timing and copy results, right when i press copy ISE closes.

There were one or two more things i noticed, but cant remember. The ones mentioned above are the most frequent.

Someone mentioned that PAR freezes due to many hold violations, thats true.

So the workaround to that issue would be, go in small steps in design, and try to run the whole implementation more often. That slows down work...but that is what you have to do with Xilinx tools. no better option. those tools cant handle situation when there are lots of timing violations and stuck.

When this happens, i go ahead, disable all wide new muxes and big logic, implement again, if it succeeds then i start enabling one logic after another to see what caused problem.

thats what works.

[rcingham]

Make sure that SmartGuide isn't enabled, and after a big change it is usually worth doing a Cleanup Project Files...

[numbat]

FWIW, I have hundreds of lines of Xilinx MIG phy code (see my earlier reply) that contains most of the large combinational logic in my project. I have no intention of modifying that code.

Not to mention that there's absolutely no evidence that this is why Par is hanging. :-)

"Touch things until the problem goes away" is a lousy fix, but far too often it is what is required to keep Xilinx FPGA based projects somewhere near schedule. :-(

[gszakacs]

"Touch things until the problem goes away"

I have another "fix" that has worked reasonably well for me:

Let someone else work the bugs out of the latest ISE version before adopting it.

Unfortunately if you are an early adopter of the latest FPGA family, you may be stuck with the

latest (and buggiest) version.  I'm usually at least one family behind the bleeding edge and

tend to use only the even-numbered major releases of ISE.  I'm pretty happy with ISE 12.4

-- Gabor

[radnorc]

Even or non even... thse tools are non reliable.

I have downloaded right now even version, 13.4, and? same stuff... it gets now stuck at phase 5, 13.3 got stuck on phase 3 (good progress!).

The only workaround as i mentioned before is: just to create design in very small increments, and after every modification implement the whole design, so that to catch setup time violations earlier, if you implement design less often and then PAR stucks, it would be hard to determine which part of newly modified logic caused the problem.

And going to the version 12 has its own troubles, like for example speed files for Spartan6 families are not quite right, which is also crucial thing to consider.

Of course nothing is impossible, but it is clear that it is not possible to effectively implement your designs with Xilinx tools these days.

i think there is nothing else to discuss within this topic anymore.

[gszakacs]

A suggestion was made to open a webcase.  If your intent in posting here was to solve the issue

rather than just complain about the sorry state of Xilinx tools, then I would suggest doing so.

-- Gabor

[radnorc]

open a webcase, and wait for 2 weeks to get workaround which would be almost same as i described? no thanks.

this issue as i discovered recently from several other people turned out to be pretty common, and should not be a big news to those who are responsible for software.

[andrewjcart]

I have come across where the routing software gets stuck in phase 6, but that this signified an error in our design. After doing some troubleshooting, we found that the routing tool was trying its best to meet the timing for a DSP-based multiply block with low latency, while trying to meet timing for all the other DSP blocks. When we raised the latency for the multiply block in question, the routing tool was able to finish. 

Maybe its getting stuck in phase 4 signifies that your design is not able to meet timing? Its getting stuck probably does mean something, though you may have to do some guess-work or troubleshooting to isolate the issue. 

Maybe try commenting out sections of your design to see how the routing performs. This might be a good way to isolate the blocks that are causing this problem. 

[bfrazer]

I was getting stuck in PAR phase 8 after a minor logic change. 

But it was a pretty sloppy change where I added a new input and threw it into a combinatoria equation that went to alot of places.  I registered the input and the problem went away.