Chan x/y placement cost factors using prefix sum

[soheilshahrouz]

Implements the prefix sum idea used for chanz in #2781 for chanx/y.

[vaughnbetz]

Looks good; if the QoR is OK we can merge, but I suggest some tweaks.

[vaughnbetz]

You could try experimenting with removing the pow and see if it yields any cpu speedup; we run with a place_cost_exp of 1 pretty much all the time so if the pow is costing us we could remove it.

[soheilshahrouz]

titan_quick_qor over 3 seeds

Metric	master.txt	feature.txt
vtr_flow_elapsed_time	1	1.001301668
num_LAB	1	1
num_DSP	1	1
num_M9K	1	1
num_M144K	1	1
max_vpr_mem	1	0.9999549581
num_pre_packed_blocks	1	1
num_post_packed_blocks	1	1
device_grid_tiles	1	1
pack_time	1	1.007941195
placed_wirelength_est	1	0.9979723975
place_time	1	1.001301333
placed_CPD_est	1	1.019405141
routed_wirelength	1	0.9981684731
critical_path_delay	1	1.020593524
geomean_nonvirtual_intradomain_critical_path_delay	1	0.9936476626
crit_path_route_time	1	1.016755021

[vaughnbetz]

QoR seems OK except cpd is up 2%. Probably noise but what does the circuit by circuit result look like?

[soheilshahrouz]

QoR seems OK except cpd is up 2%. Probably noise but what does the circuit by circuit result look like?

Here the link to circuit by circuit comparison. In the most extreme case, CPD is increased by ~40%.

[vaughnb-cerebras]

Thanks. It looks like there is just a couple of circuits with noise. I'm OK with merging.

[vaughnb-cerebras]

Suggest making the changes listed in the code review, doing a quick re-check to be safe on QoR, and then merging.

[soheilshahrouz]

titan_quick_qor on 464dd62

Metric	Baseline	Value
vtr_flow_elapsed_time	1	1.032769487
num_LAB	1	1
num_DSP	1	1
num_M9K	1	1
num_M144K	1	1
max_vpr_mem	1	0.9999541852
num_pre_packed_blocks	1	1
num_post_packed_blocks	1	1
device_grid_tiles	1	1
pack_time	1	1.011271438
placed_wirelength_est	1	0.997215378
place_time	1	1.043569677
placed_CPD_est	1	1.009797219
routed_wirelength	1	0.997584742
critical_path_delay	1	1.007112939
geomean_nonvirtual_intradomain_critical_path_delay	1	0.995636464
crit_path_route_time	1	1.011247505

The increase in CPD is now 1%, but palcement time increased by 4%.

[vaughnbetz]

Probably really 3% as pack and route time are up 1%. Any ideas to optimize? Take out the pow?

Special case all channels equal width (check and store) and compute the pow and reciprocal in advance?

[soheilshahrouz]

titan_quick_qor
Comparison between master (045a9e8) and this branch (49d4396)

It seems that multiplying crossing only once at the end has reduced the placement time.

Metric	master.txt	feature.txt
vtr_flow_elapsed_time	1	0.9960061822
num_LAB	1	1
num_DSP	1	1
num_M9K	1	1
num_M144K	1	1
max_vpr_mem	1	1.000009388
num_pre_packed_blocks	1	1
num_post_packed_blocks	1	1
device_grid_tiles	1	1
pack_time	1	0.9980662387
placed_wirelength_est	1	1.001936399
place_time	1	0.9943848951
placed_CPD_est	1	0.9966367297
routed_wirelength	1	1.002183219
critical_path_delay	1	0.993269001
geomean_nonvirtual_intradomain_CPD	1	0.9936908393
crit_path_route_time	1	0.9978216647

[soheilshahrouz]

For reciprocal calculation, we can use fast inverse sequare root algorithm and multiply the result by itself to get the reciprocal. A few integer operations and a floating point multiplication is probably faster than a floating point division.

[vaughnbetz]

Cool, thanks. I think we should merge this; the fast reciprocal square root is probably not worth the effort/complexity.

There are some QoR failures, but they all seem to be on tiny circuits so I think OK, and the one in basic is a big win.

[soheilshahrouz]

@vaughnbetz ready to merge into master