[LibArchFPGA] Updating Model Data Structures

[AlexandreSinger]

The logical models (the technology-mapped logical blocks) for an architecture were stored using two independent linked lists. One for the library models (the models that all architectures have, such as luts and ffs) and one of the user models. This linked lists were hard to traverse and were injecting pointers all across VPR.

Created a new class to store and manage the logical models. This class maintains a unique ID for each logical model (similar to the netlist data structures in VPR). It also contains helper methods to make working with the logical models easier.

Due to the nature of this change, this modified around 100 files; however, the most important changes can be found in libs/libarchfpga/src/logic_types.h and libs/libarchfpga/src/logic_types.cpp.

[vaughnbetz]

Looks good to me. Good to validate carefully though -- if we don't get the same results we need to check that we have some logical equivalence or simulation equivalent tests.

[AlexandreSinger]

This has passed the Nightly Tests: https://github.com/verilog-to-routing/vtr-verilog-to-routing/actions/runs/14716009917

Here are the results on Titan:

	baseline_parse_results.txt	models_update_parse_results.txt
vtr_flow_elapsed_time	1	1.10265811992652
num_LAB	1	1
num_DSP	1	1
num_M9K	1	1
num_M144K	1	1
max_vpr_mem	1	1.00021716093015
num_pre_packed_blocks	1	1
num_post_packed_blocks	1	1
device_grid_tiles	1	1
pack_time	1	1.07726379083761
placed_wirelength_est	1	1
place_time	1	1.11525937543165
placed_CPD_est	1	1
routed_wirelength	1	1
critical_path_delay	1	1
geomean_nonvirtual_intradomain_critical_path_delay	1	1
crit_path_route_time	1	1.09588981338162

After this change, we have identical QoR (which is fantastic for a change this big). The runtime increased by 10%; however I think this is machine load. I think someone was running heavy things on wintermute last night and it caused my runs to slow down. Notice that the critical path route time increased by 10%; however this code does not modify practically anything in routing. I do not think there is much to worry about here, but I will look around to be safe.

[vaughnbetz]

Sounds good. Pack time increased less than other times so probably machine load -- may be a small pack speed up. You might want to try one design on your own machine to see a high fidelity cpu comparison.

[AlexandreSinger]

Running directrf on my local machine now. Will get the results this evening. If they seem ok I will merge this PR. I want to merge this massive PR asap to prevent regression.

[AlexandreSinger]

@vaughnbetz Let this be a testament to the importance of testing. My local tests confirm that my changes did make things slightly slower. Thinking through what could have caused this, I realized my mistake. I think this being a map is actually a very bad idea. Since these are strings, these are getting lexicographically sorted! This can be very expensive since these are doing character by character comparisons within the binary tree. This should be an unordered map instead! I will give this a try and rerun on my circuit!

[vaughnbetz]

Did the unordered map chanfe equalize the speed?

[AlexandreSinger]

@vaughnbetz Yes it did. Prior to this change, when I tested it locally, directrf was 5 minutes slower (3% slower) in overall run time with the exact same result.

After changing to an unordered_map, it is only 20 seconds slower (0.2% slower) in overall run time. For a 3 hour benchmark, I consider that practically equalized. I went through the entire code as well to be extra safe.

The only place I can think of where we lost some performance was were we perform string comparisons. Since models store their names as C-strings (char *), but my interface returns an std::string for convenience, this may perform unecessary string copies. If these were just stored as strings, it would prevent these copies; but these are very uncommon. I will raise an issue to detail some future work for this cleanup!

[AlexandreSinger]

I also double checked by running the VTR benchmarks to be safe to ensure we get identical results. Which we do.

[vaughnbetz]

Sounds good, thanks!