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
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