[xilinx] par [placer] consistency

That's a pretty common problem.

That's true.

What you need to do is put good timing exceptions into your constraints file so that PAR doesn't expend effort trying to optimize timing on paths that don't matter and can instead focus on the truly critical paths.

I've found that identifying multi-cycle paths is a big help in getting more consistent PAR results.

That said, If you're having trouble meeting timing with a 50MHz clock constraint you may have some seriously long paths in your design. Adding timing exceptions may not help and you might have some pipeline optimization to do.

Eric

Check out some of the new features in ISE 9 :

One of the new features is smartcompile - it is intended to re-use previous place and route data as much as it possibly can - so critical paths will be retained. Run to run differences should be minimised (unless you are modifying your critical path logic).

Hope this helps, John

I guess I could make it more consistent if I'll force only the location of BRAMs. However, a [good] timing driven placer should take care of that ....

Agreed. But in this design I don't have multi-cycle paths.

To be honest, the design is using both edges of the clock so you can call it 100MHz if you want. The failing one is such a path, and it goes through [only] 4 levels of logic:

[...] Requirement: 10.000ns Data Path Delay: 10.679ns (Levels of Logic = 4) Clock Path Skew: 0.000ns [...] Total 10.391ns (3.344ns logic, 7.047ns route) [...]

--
mmihai
http://www.delajii.net/consulting

Inspired by a recent thread in this newsgroup (look for "Xilinx ISE

9.1 subject") I've tried "par" with different (default is 1) "cost table" values (-t option) and it seems this option helps in meeting the target timing. With "-t 2" I'm getting:

Timing summary:

---------------

Timing errors: 0 Score: 0

Constraints cover 70048 paths, 0 nets, and 5448 connections

Design statistics: Minimum period: 19.892ns (Maximum frequency: 50.271MHz)

Can anyone detail what "cost table" number is doing?

Thanks,

--
mmihai
http://www.delajii.net/consulting

It's quite normal to get timing variations of a few percent from (a) extremely minor changes to the design and (b) changes to the "cost table" setting (or random seed).

If I fail to meet timings by less than 10%, one option is to run MPPR overnight, to place/route with 10 or more different seeds - usually at least one makes it through timings. Failing that, if I don't want to modify the design, I look at the best failing pass in FPGA Editor, and often the problem is only a few absurdly badly placed components, which I can unroute, move, then let reentrant routing take over.

As I understand it, the placer places components apparently randomly, then evaluates the "cost" i.e. difficulty of routing, according to a number of factors, placing a (slightly arbitrary) cost weighting on things like distance between related components, and congestion. Then it repeatedly rearranges components to reduce that cost.

The slightest design change can completely change the start position, so this procedure can fail to find the same "minimum cost" from the same weighting factors. But a different set of weighting factors may produce a better minimum from the new start.

What's missing in the PAR process is feedback from a failed routing pass about specific placement problems, back into the placer, to allow it to re-place those components, and try again.

- Brian

You can make up for the lack of feedback in the MPPR by doing a little manual component placement. In your case it is likely that the block RAMs are in the critical timing paths. If you take the location of the placed block RAMs from a successful PAR (one that meets timing) and add them as LOC constraints in your .ucf file (or in the source code if they are instantiated), you'll probably find that the place&route process will go better.

HTH, Gabor