Fix for Handling Missing Switch Types in RR Graph Builder

[amin1377]

Previously, when the run-flat option was used and the RR graph was read from a file, the assumption was that all switch types (both inter-cluster and intra-cluster) were listed under the switch tag in the RR graph file. Consequently, when adding intra-cluster edges, if the RR graph builder encountered an edge that didn't have a corresponding switch type, it would throw an error.

In this PR, we removed this assumption. Now, if the RR graph builder cannot find a switch type, it will add a new RR switch type.

To test this PR, I used the Titan Murax circuit. The first run was with run-flat enabled, and the graph was built from scratch. For the second run, I first wrote the RR graph with run-flat disabled, so the RR graph file did not contain any of the intra-cluster switches. Then, I ran VPR with run-flat enabled again and read in the aforementioned RR graph. The routing results between these two runs were the same.

[vaughnbetz]

One routing failure in vtr_reg_strong when ASSERT_LEVEL is 3. spree doesn't route (either serial or parallel, so makes two failures and a bunch of QoR failures). Maybe an assert fired?
regression_tests/vtr_reg_strong/strong_flat_router...[Fail]
2024-08-02T14:00:49.4647643Z �[32;1m14:00:49�[0m | [Fail]
2024-08-02T14:00:49.4649126Z �[32;1m14:00:49�[0m | k6_frac_N10_frac_chain_mem32K_40nm.xml/spree.v/common vpr_status Task value 'exited with return code 1' does not match golden 'success'
2024-08-02T14:00:49.4650354Z �[32;1m14:00:49�[0m | [Fail]
2024-08-02T14:00:49.4652150Z �[32;1m14:00:49�[0m | k6_frac_N10_frac_chain_mem32K_40nm.xml/spree.v/common routed_wirelength relative value -9.344921035417251e-05 outside of range [0.6,1.5], above absolute threshold 5.0 and not equal to golden value: 10701.0
2024-08-02T14:00:49.4653787Z �[32;1m14:00:49�[0m | [Fail]
2024-08-02T14:00:49.4655506Z �[32;1m14:00:49�[0m | k6_frac_N10_frac_chain_mem32K_40nm.xml/spree.v/common logic_block_area_total relative value -1.0868915445272294e-07 outside of range [0.8,1.3] and not equal to golden value: 9200550.0
2024-08-02T14:00:49.4657081Z �[32;1m14:00:49�[0m | [Fail]
2024-08-02T14:00:49.4658690Z �[32;1m14:00:49�[0m | k6_frac_N10_frac_chain_mem32K_40nm.xml/spree.v/common logic_block_area_used relative value -1.877042456823331e-07 outside of range [0.8,1.3] and not equal to golden value: 5327530.0
2024-08-02T14:00:49.4660240Z �[32;1m14:00:49�[0m | [Fail]
2024-08-02T14:00:49.4661907Z �[32;1m14:00:49�[0m | k6_frac_N10_frac_chain_mem32K_40nm.xml/spree.v/common min_chan_width_routing_area_total relative value -6.770893283950952e-07 outside of range [0.7,1.3] and not equal to golden value: 1476910.0
2024-08-02T14:00:49.4663420Z �[32;1m14:00:49�[0m | [Fail]
2024-08-02T14:00:49.4665071Z �[32;1m14:00:49�[0m | k6_frac_N10_frac_chain_mem32K_40nm.xml/spree.v/common min_chan_width_routing_area_per_tile relative value -0.0001327099504593755 outside of range [0.7,1.3] and not equal to golden value: 7535.23

[vaughnbetz]

I took a look at the spree vpr logs, and it does seem to be complaining about an out of range switch id (didn't copy down the exact message, sorry). So I think there is a bug in that run somewhere.

[vaughnbetz]

Thanks for addressing the changes ... now waiting for CI to run. In the interim, can you confirm the spree tests pass when you run them by hand?

[amin1377]

@vaughnbetz After the fix, I ran spree and it was working on my local machine.