[WIP][AP][APPack] Density Estimation Upstream

[AlexandreSinger]

This was code written for a TODAES publication which found that APPack struggled when the device was aggressively sized.

This PR brings in improvments to APPack which allow it to estimate how much space is available on the device and use that information to select different parameters to more aggressively pack. For example, if it detects that the device is limited in CLBs, it will increase the max displacement threshold for CLBs proportional to how limited the CLBs are. If the limitation is extreme, it automatically turns on unrelated clustering early.

This should help the auto-selected device sizes be more aligned with the traditional flow as well.

[AlexandreSinger]

Note: I marked this as WIP since I need to do quite a bit of testing. I wanted to do the testing before code cleanups.

[AlexandreSinger]

QoR on titan_quick_qor:

	baseline.txt	parse_results.txt
vtr_flow_elapsed_time	1.000	0.976
num_LAB	1.000	0.983
num_DSP	1.000	1.107
num_M9K	1.000	1.000
num_M144K	1.000	1.000
max_vpr_mem	1.000	0.977
num_pre_packed_blocks	1.000	1.000
num_post_packed_blocks	1.000	0.980
device_grid_tiles	1.000	0.932
pack_time	1.000	1.014
placed_wirelength_est	1.000	1.037
place_time	1.000	0.979
placed_CPD_est	1.000	1.025
ap_time	1.000	0.981
routed_wirelength	1.000	1.035
critical_path_delay	1.000	1.006
geomean_nonvirtual_intradomain_critical_path_delay	1.000	1.015
crit_path_route_time	1.000	1.035

Raw results:
comparison_output.xlsx

This clearly did its job, it decreased the number of grid tiles by 7%. CPD stayed largely the same, but we lost some wirelength for this.

When AP was first made the default, the device sizes increased by ~12%: #3570 (comment)

This PR would recover most of this increase (1 / 0.93 = 1.08 => AP overall increases the device size by 4%).

I think the terms that I am using for the thresholding can be tuned a bit better. I would prefer to keep the WL gain if I can and we can also see if we can recover more of the device size.

NOTE: The reason to focus on device width is to try and make the device sizes more stable. If we can predict if we will overfill the device, we should try not to do that.

[AlexandreSinger]

QoR on titan_quick_qor again after tuning the multiplier from 30 to 10:

	baseline.txt	parse_results.txt
vtr_flow_elapsed_time	1.000	1.010
num_LAB	1.000	1.011
num_DSP	1.000	1.128
num_M9K	1.000	1.000
num_M144K	1.000	1.000
max_vpr_mem	1.000	1.002
num_pre_packed_blocks	1.000	1.000
num_post_packed_blocks	1.000	1.007
device_grid_tiles	1.000	0.979
pack_time	1.000	1.006
placed_wirelength_est	1.000	1.012
place_time	1.000	1.017
placed_CPD_est	1.000	1.029
ap_time	1.000	1.011
routed_wirelength	1.000	1.012
critical_path_delay	1.000	1.029
geomean_nonvirtual_intradomain_critical_path_delay	1.000	1.036
crit_path_route_time	1.000	1.016

Notice that the number of DSPs is up (even higher than before). I have found that this is likely caused by the spaces between the columns of DSPs leading to more DSPs to be created (since the max distance threshold is cutting their connectivity terms).

This seems to have gotten worse on titan. We still reduce the number of device tiles, but not by as much.

I think I want to investigate adding a dense-grid-like feature to the max displacement threshold so we can ignore the space between columns. This should resolve this issue and make DSPs more stable.