Table of Contents

Turns a mapped NCD file into a fully placed and routed NCD suitable for use as input to bitgen.


par -w -intstyle ise -ol high -mt 4 [input mapped NCD file] [output routed NCD file] [input PCF file]

As with map, the -mt switch specifies how many threads to use. Up to 4 are supported.

On Linux, par seems to trap ^C. For example, I tried to kill my make job and it appeared to stop. However, par had trapped the ^C and continued to run. Once PAR finally finished it received the signal leading to a “Ctrl-C interrupt detected.” message far after the make job had ended. This can be especially bad if you run a second par job and they interleave.

Sometimes I get slow builds (unsure if this was par component or not) because a signal wasn't on combinatorial logic sensitivity list


Don't believe there is any documentation on what the phases actually mean.



14.5: can get stuck / very long PAR time when you try to use two unrelated clocks together. Sometimes it will succeed, sometimes will fail but always will significantly increase run time. I also found a few other things like assigning arrays would lead to this condition even if the array result was not used. Its unclear to me if this is a CDC issue that I don't understand or simply that a slower routing algorithm was taking over due to design size being pushed over limit or simply a bug.


INFO:LIT:243 - Logical network
   my_module/my_tig_path<33><0> has no load.

seems to be the (another?) cause. This was unintential in the original test case but intentional in the reduced case. I didn't intend it to do it originally but was surprised that the reduced test case (assigning to signal without using it) still showed an issue. This net has a keep constraint on it that xst would have otherwise optimized out. Probably something not well tested with par

Another way this can creep up in my projects is I use **_tig_path matching for TIG signals rather than marking each explicitly. However, if you forget to also add a KEEP constraint the signals will be combined and it will not match. If one had explicitly marked it a TIG path in the .ucf it would fail because nothing matched the constraint. But, because its a wildcard, it would simply optimize out and then not match


all signals should typically be routed by phase 5

ex: Phase 5 : 0 unrouted; (Setup:143688, Hold:821862, Component Switching Limit:0) REAL time: 1 mins 21 secs


Phase 10  : 0 unrouted; (Setup:118117, Hold:821458, Component Switching Limit:0)     REAL time: 2 mins 47 secs
WARNING:Route:466 - Unusually high hold time violation detected among 87 connections. The top 20 such instances are printed below. The
   router will continue and try to fix it

was caused by bad TO FROM .ucf constraint when trying to do CDC

Fails without error

Sometimes PAR can fail but claims there are 0 errors. This section has examples to help figure out why PAR failed

WARNING:Route:436 - The router has detected an unroutable situation for one or more connections. The router will finish the rest of the
   design and leave them as unrouted. The cause of this behavior is either an issue with the placement or unroutable placement constraints.
   To allow you to use FPGA editor to isolate the problems, the following is a list of (up to 10) such unroutable connections:
	 Unroutable 	 signal: clk_75m_unbuf 	 pin:  sata_bus/sata_core/SATA_LINK_LAYER_i/SATA_PHY_i/rst_3/CLK
xilinx/par.txt · Last modified: 2014/07/16 20:38 by mcmaster-guest
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution 4.0 International
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki