[Prepacking] Re-Designed Prepacker API

[AlexandreSinger]

The original Prepacker API created a lot of global variables which were confusing to work with and hard to maintain.

Created a Prepacker class which maintains the state of the Prepacker and provides methods to access prepacking information.

I also tried to remove the accesses to the global scope from within the prepacker to isolate it from the rest of VTR. This is in an attempt to make it easier to work with.

[AlexandreSinger]

@vaughnbetz This PR has passed CI. This PR abstracts prepacking into a single class which, when initialized, sets up internal variables for tracking molecules. The variables for tracking molecules used to be stored in the atom context; this has been replaced with an instance of the prepacker object which is initialized in the packing stage. I also removed all of the calls to g_vpr_ctx from the API, isolating it from the rest of the flow.

All of this makes it easier to use prepacking in the analytical placement flow and makes it easier to maintain (changes in the packing flow should not break the AP flow).

[vaughnbetz]

Looks very good; just a few commenting changes.
I suggest getting a QoR comparison for safety too though (VTR and/or Titan).

[AlexandreSinger]

@vaughnbetz I have resolved your comments. I have found that, at least for the strong tests, each block will be contained in only one molecule. This matches what I think I see in the prepacker code. I have updated the API interface to reflect this and made it much more efficient by turning the lookups from a multimap (O(log(n))) into a vtr::vector(O(1)). I have added asserts to ensure this assumption. We will see if the CI agrees with this change, I can easily undo it if I am wrong.

I will run the VTR benchmarks soon (I want to ensure a good number of the CI tests complete) to get QoR results, I do not expect any slowdown or QoR change.

[AlexandreSinger]

@vaughnbetz Here are the QoR results for VTR:

	vtr_parse_results_new_yosys.txt	vtr_parse_results_prepack.txt
vtr_flow_elapsed_time	1	0.995878184
odin_synth_time
parmys_synth_time	1	0.910618505
abc_depth	1	1
abc_synth_time	1	1.012554285
num_clb	1	1
num_memories	1	1
num_mult	1	1
max_vpr_mem	1	0.994725417
num_pre_packed_blocks	1	1
num_post_packed_blocks	1	1
device_grid_tiles	1	1
pack_time	1	0.999367909
placed_wirelength_est	1	1
place_time	1	1.015163644
placed_CPD_est	1	1
min_chan_width	1	1
routed_wirelength	1	1
min_chan_width_route_time	1	1.005690237
crit_path_routed_wirelength	1	1
critical_path_delay	1	1
geomean_nonvirtual_intradomain_critical_path_delay	1	1
crit_path_route_time	1	0.990201513

The change in parmys_synth_time seems to be caused by smaller circuits (such as ch_intrinsics.v, diffeq1.v, and raygentop.v) being around 2x faster and bringing down the average. Everything else seems to be good. This makes sense. Although I made getting the molecule for a block O(1), the run time of the packing algorithm is dominated by the legalization of packing a molecule into a cluster (not getting the molecule).

Here is the raw data:
comparison_output.xlsx

When this passes CI, it should be good to merge unless you have any further comments.

[vaughnbetz]

Looks good to me!

[AlexandreSinger]

@vaughnbetz Please merge when you get the chance! Its a bit of a large PR and I want to prevent it from regressing. My next PR will also depend on this one.