Implementation

[xrisas1]

Hi guys,

I'm getting quite a problem getting my design pass timing. What makes things bad is that my Virtex-6 LX240T is getting quite full 91-93% occupied slices. I thought I did not have a chance fitting the design and pass timing, but now I am very close.

In the first run I got this strange error:

FATAL_ERROR:Pack:pkimblogicmend.c:1860:1.14 - Failed to get an output signal on BEL block PhysOnlyGnd.B6LUT in comp
cpu_i/sc_axi4lite_0/sc_axi4lite_0/USER_LOGIC_I/sc_top_inst/sc_core_inst/cam_addr_sel/psumrar<6>_9<3>. Process will
terminate. For technical support on this issue, please open a WebCase with this project attached at
http://www.xilinx.com/support.

Following the advice from http://forums.xilinx.com/t5/Spartan-Family-FPGAs/Mapping-Error/m-p/227529#M16604, as I mention in that post, I changed the cost table from 3 to 2 and it bypassed the error above, being able to fully route the design but failed timing with some small slack. From then I tried around 20 different cost tables, half of them giving me the Pack error above and the other half failing to fully route the design.

I am a bit reluctant to go back and change the code at this point, so I would prefer to have the tools sort it out for me.

As an example, for the designs that don't fail Map with the Pack error I get:

---

Starting Multi-threaded Router

Phase 1 : 682230 unrouted; REAL time: 4 mins 43 secs

Phase 2 : 599052 unrouted; REAL time: 5 mins 40 secs

Phase 3 : 331619 unrouted; REAL time: 10 mins 12 secs

Phase 4 : 335799 unrouted; (Setup:8956, Hold:87436, Component Switching Limit:0) REAL time: 11 mins 41 secs
WARNING:Route:464 - The router has detected a very dense, congested design. It is extremely unlikely the router will be able to finish the
design and meet your timing requirements. To prevent excessive run time the router will change strategy. The router will now work to
completely route this design but not to improve timing. This behavior will allow you to use the Static Timing Report and FPGA Editor to
isolate the paths with timing problems. The cause of this behavior is either overly difficult constraints, or issues with the
implementation or synthesis of logic in the critical timing path. If you are willing to accept a long run time, set the option "-xe c" to
override the present behavior.

Updating file: cpu_top.ncd with current partially routed design.
WARNING:Route:543 - This design is experiencing routing congestion. Please review the Xilinx Routing Optimization White Paper, WP381 on
www.xilinx.com, for guidelines and techniques in resolving this issue.
WARNING:Route:562 -
Par has gone into non timing driven mode hence it will not fix hold errors.
To bypass this, please run Par in -xe mode.
Phase 5 : 10950 unrouted; (Setup:16434858, Hold:35384, Component Switching Limit:0) REAL time: 4 hrs 33 mins 46 secs
Total REAL time to Router completion: 4 hrs 34 mins 2 secs
Total CPU time to Router completion (all processors): 12 hrs 45 mins 23 secs

---

While for the one out of 20 cost tables that it gets to route the design I get:

---

Starting Multi-threaded Router

Phase 1 : 682148 unrouted; REAL time: 4 mins 9 secs

Phase 2 : 598882 unrouted; REAL time: 4 mins 49 secs

Phase 3 : 327510 unrouted; REAL time: 8 mins 23 secs

Phase 4 : 330780 unrouted; (Setup:0, Hold:77811, Component Switching Limit:0) REAL time: 9 mins 25 secs

Updating file: cpu_top.ncd with current fully routed design.

Phase 5 : 0 unrouted; (Setup:81688, Hold:62677, Component Switching Limit:0) REAL time: 4 hrs 53 mins 3 secs

Phase 6 : 0 unrouted; (Setup:81688, Hold:62677, Component Switching Limit:0) REAL time: 4 hrs 53 mins 23 secs

Phase 7 : 0 unrouted; (Setup:81688, Hold:62677, Component Switching Limit:0) REAL time: 4 hrs 53 mins 23 secs

Phase 8 : 0 unrouted; (Setup:81688, Hold:62677, Component Switching Limit:0) REAL time: 4 hrs 53 mins 23 secs

Phase 9 : 0 unrouted; (Setup:81688, Hold:62677, Component Switching Limit:0) REAL time: 4 hrs 53 mins 23 secs

Phase 10 : 0 unrouted; (Setup:81688, Hold:2446, Component Switching Limit:0) REAL time: 5 hrs 50 mins 45 secs

Phase 11 : 0 unrouted; (Setup:80139, Hold:1761, Component Switching Limit:0) REAL time: 5 hrs 57 mins 2 secs
Total REAL time to Router completion: 5 hrs 57 mins 3 secs
Total CPU time to Router completion (all processors): 7 hrs 17 mins 44 secs

---

So my question is : Can I somehow force PAR pick up the fully routed design (cpu_top.ncd from phase 5) and make it work harder to resolve timing?

Currently using ISE 13.4.

I guess that's a long shot, but let's see if somebody knows a trick.

Thanks.

[xrisas1]

Just found out what smartGuide actually is..

I'll give it a try to see if it can improve timing.

[bwade]

Have you tried running par with "-xe c" as recommended by the par warning? That overrides the behavior where it gave up on timing to fight congestion. Par does have a reentrant mode using the -k option but I would try "-xe c" first.

[xrisas1]

Well, yes...

But how on earth can I be getting the exact same message (after waiting for half a day..?):

Started : "Place & Route".
Running par...
Command Line: par -w -intstyle ise -ol high -xe c -smartguide "C:/work/xxx/cpu_top_guide.ncd" -mt 4 cpu_top_map.ncd cpu_top.ncd cpu_top.pcf

WARNING:Par:492 - Multi-threading ("-mt" option) is not supported for the SmartGuide flow. PAR will use only one
processor.

Constraints file: cpu_top.pcf.
Loading device for application Rf_Device from file '6vlx240t.nph' in environment C:\Xilinx\13.4\ISE_DS\ISE\.
"cpu_top" is an NCD, version 3.2, device xc6vlx240t, package ff1156, speed -1
INFO:Par:338 -
Extra Effort Level "c"ontinue is not a runtime optimized effort level. It is intended to be used for designs that are
not meeting timing but where the designer wants the tools to continue iterating on the design until no further design
speed improvements are possible. This can result in very long runtimes since the tools will continue improving the
design even if the time specs can not be met. If you are looking for the best possible design speed available from a
long but reasonable runtime use Extra Effort Level "n"ormal. It will stop iterating on the design when the design
speed improvements have shrunk to the point that the time specs are not expected to be met.

Loading database..

.

.

.

.

.

Starting Router

Phase 1 : 37343 unrouted; REAL time: 5 mins 5 secs

Phase 2 : 5772 unrouted; REAL time: 5 mins 34 secs

Phase 3 : 148 unrouted; REAL time: 6 mins 23 secs

Phase 4 : 4041 unrouted; (Setup:0, Hold:2446, Component Switching Limit:0) REAL time: 7 mins 51 secs
Intermediate status: 236 unrouted; REAL time: 6 hrs 11 mins 6 secs

Intermediate status: 223 unrouted; REAL time: 6 hrs 48 mins 2 secs

Intermediate status: 243 unrouted; REAL time: 7 hrs 26 mins 43 secs

Intermediate status: 263 unrouted; REAL time: 8 hrs 10 mins

Intermediate status: 280 unrouted; REAL time: 8 hrs 59 mins 5 secs

Intermediate status: 299 unrouted; REAL time: 9 hrs 49 mins 36 secs

Intermediate status: 280 unrouted; REAL time: 10 hrs 49 mins 24 secs

WARNING:Route:463 - The router has detected a very dense, congested design. It is extremely unlikely the router will be able to finish the
design and meet your requirements. To prevent excessive run time the router will exit with a partially routed design. This behavior will
allow you to identify difficult designs earlier. The cause of this behavior is either overly difficult constraints, putting too much
logic into this device, or an issue with the implementation. If you would prefer a fully routed design, ease the constraints (if any),
remove some logic from the design, or change the placement before running router again. If you are willing to accept a long run time, set
the option "-xe c" to override the present behavior.
WARNING:Route:543 - This design is experiencing routing congestion. Please review the Xilinx Routing Optimization White Paper, WP381 on
www.xilinx.com, for guidelines and techniques in resolving this issue.
WARNING:Route:563 -
Router will not fix hold error

Phase 5 : 303 unrouted; (Setup:395708, Hold:1816, Component Switching Limit:0) REAL time: 11 hrs 8 mins 15 secs
Total REAL time to Router completion: 11 hrs 8 mins 17 secs
Total CPU time to Router completion: 11 hrs 7 mins

It's a bit funny to see that only a few hundred signals are causing the problem...

[xrisas1]

I also tried removing the SmartGuide, so:

Command Line : map -intstyle ise -p xc6vlx240t-ff1156-1 -w -logic_opt off -ol
high -xe c -t 2 -xt 0 -register_duplication off -r 4 -global_opt off -mt 2
-detail -ir off -ignore_keep_hierarchy -pr b -lc off -power off -o
cpu_top_map.ncd cpu_top.ngd cpu_top.pcf

resulted in the same nasty pack error during map..

I also tried smartXplorer usinf the timing strategies. Have a look on what I get:

Strategy	Host	Output	Status	Timing  Score	Worst Case  Slack	Luts	Slice  Registers	Total  RunTime
MapRegDup	XXX	run3	Done	2219577	-3.130ns	99,266 (65%)	108,399 (35%)	18h 7m 57s
MapRunTime	XXX	run1	Failed Par	None	-6.615ns	98,898 (65%)	108,367 (35%)	15h 26m 34s
MapIOReg	XXX	run2	Failed Map	None	None	None	None	1h 33m 9s
MapExtraEffortIOReg	XXX	run4	Failed Par	None	-6.591ns	95,966 (63%)	108,361 (35%)	16h 41m 45s
MapLogOptRegDup	XXX	run5	Failed Map	None	None	None	None	1h 48m 41s
MapExtraEffort2	XXX	run6	Failed Map	None	None	None	None	1h 44m 26s
MapLogicOpt	XXX	run7	Failed Map	None	None	None	None	1h 34m 8s

Map Failes means the pack error, par failed means a few hundred signals unrouted and one pass ok but failing timing.

Unbelievable.

[djktp10]

My design has 70+% LUT usage (V6, too), and since it's ASIC RTL code originally, there is too much combinational logic. I set frequency: 20M. The result is: I always met congest design warning just like you, and PR can't finish. Maybe we just can't put a too large design into a chip, and expect it can finish PR.