high speed place and route about xilinx

[bjzhangwn@gmail.com]

Now I am troubled that I must wait several hours to compile large
circuits,and the place and route result is different from each
time,for example the p&r time for this time is may be 2hrs and may be
5 or 6 hrs next time only becase of little change,can some give me
some tips or advice ,thks.

 

[BobH]

On 10/9/2011 7:49 AM, bjzhangwn@gmail.com wrote:

Now I am troubled that I must wait several hours to compile large
circuits,and the place and route result is different from each
time,for example the p&r time for this time is may be 2hrs and may be
5 or 6 hrs next time only becase of little change,can some give me
some tips or advice ,thks.

I am using version 11.5, so your setup may be different. The next time
you get a run that completes in an acceptable time and meets your timing
constraints, save the console output to a file. Look through the place
and route area of the log and there should be information about the
placement choices made in this run. There is a comment in the log file
about using that output for constraining the place and route of future
runs. I have not tried this method, but have seen the stuff in the log
files along with the instructions (terse). I assume that you could
manually cut the constraint information from the log file with a text
editor and paste it into the .ucf file that has your pin and timing
constraints in it.

Good Luck,
BobH

 

[Nico Coesel]

"bjzhangwn@gmail.com" <bjzhangwn@gmail.com> wrote:

Now I am troubled that I must wait several hours to compile large
circuits,and the place and route result is different from each
time,for example the p&r time for this time is may be 2hrs and may be
5 or 6 hrs next time only becase of little change,can some give me
some tips or advice ,thks.

Check your constraints. See if the constraints cover what you think
they should cover.

Having everything on a high speed clock usually is a bad idea. I
usually use the DCM to create lower frequency clocks to feed low speed
logic. Because the clock edges are still aligned the clock domain
crossing issues aren't that severe.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

Are you meeting timing? If so, reduce the effort level for map / par so it doesn't "try harder" for nothing. In fact, I've seen higher effort settings produce worse results, and take longer to run, than lower effort levels for the same design, so it might be worth a try even if you're not meeting timing! (Results depends on the version of tools, your code, constraints, etc..)