Add a new API set_node_type() to RRGraphBuilder

[tangxifan]

Description

This PR focuses on updating routing resource graph builder functions, where we use the refactored data structure RRGraphBuilder to shadow the discreted data structure rr_graph_storage.
This PR aims to fully deprecate the direct use of the legacy API set_type() from rr_node data structure.

After this PR, the set_type API is fully deprecated and the set_node_type from the refactored data structure RRGraphBuilder is the only way to use.

Checklist:

• Removed the legacy API set_type() from rr_node.cpp and rr_node.h
• Added new APIs set_node_type to data structures RRGraphBuilder, whose comments are Doxygen compatible
• Replaced all the use of set_type() in builder functions by set_node_type()

Related Issue

This pull request is a follow-up PR on the routing resource graph refactoring effort #1805

Motivation and Context

After the previous PR #1837 , we have accomplished the refactoring effort on RRSpatialLookup.
We now continue the refactoring effort with a focus on shadowing the rr_graph_storage APIs in RRGraphBuilder data structure.
This is the 1st PR in the effort, which reworks the set_node_type() API

Here is a list about the APIs we will rework:

• set_node_type()
• set_node_ptc_num()
• set_node_pin_num()
• set_node_track_num()
• set_node_class_num()
• set_node_coordinates()
• set_node_cost_index()
• set_node_rc_index()
• set_node_capacity()
• set_node_direction()
• add_node_side()
• reserve_nodes()
• resize_nodes()
• add_node()
• reserve_edges()
• emplace_back_edges()
• alloc_and_load_edges()
• count_rr_switches()
• remap_rr_node_switch_indices()
• make_edges_as_rr_switch_ids()
• partition_edges()
• init_fan_in()

How Has This Been Tested?

Types of changes

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[tangxifan]

TODO: QoR comparison is under going.

[vaughnbetz]

Looks good, thanks. Will merge when the QoR comparison is in; given the change it's highly unlikely to affect QoR but always good to check.

[vaughnbetz]

@tangxifan : just pinging to see if the QoR change data is ready now, so we can check and merge.

[tangxifan]

@vaughnbetz It is running late. We just get a new server and it takes some time to set up. It should be ready early next week. Sorry for the delay.

[vaughnbetz]

No worries; when I do a pass through PRs I just make notes in them and prod people so I can remember why it isn't merged yet. No rush :).

[tangxifan]

As required for QoR checks, the QoR runs have been finished.
Here is a summary of the results

• Basic sanity test

  • Flow run time +29% on average. However, most contributions are from ODIN2 (+15%) and packer (+42%)
  • No changes on critical path delay
  • Peak memory usage +5% on average

• vtr_reg_qor_chain_depop test

  • Flow run time +2% on average. However, most contributions are from place_sta_time (+14%) and critical_path_route_time (+17%)
  • No changes on critical path delay
  • Peak memory usage -3% on average

• titan_quick_qor test:

  • flow run time +19% on average. However, most contributions are from packer (+19%) and placer (+19%), which are not under refactoring
  • No changes on critical path delay
  • Peak memory usage -2% on average

I see some significant changes on runtime but they look quick weird to me. The code changes in this PR in on the RRGraphBuilder, but packer/placer runtime increase for titan benchmarks.

• I am not sure if the RRGraph building is counted in placer runtime. If so, I can change the API to be inline and see if makes a difference or not.
• I am trying to rerun the titan benchmarks and see if there were glitches in previous run.

Attached spreadsheet for the detailed QoR of each test:
vtr_reg_qor_chain_depop_comp.xlsx
vtr_reg_titan_quick_qor_comp.xlsx
vtr_reg_basic_timing_sanity_comp.xlsx

[tangxifan]

Just a note, I resolved code conflicts as another PR merged #1853 .
@hamzakhan-rs We should rerun the QoR tests on this PR.

[hamzakhan-rs]

Just a note, I resolved code conflicts as another PR merged #1853 .
@hamzakhan-rs We should rerun the QoR tests on this PR.

Ok I will rerun the QoR tests on this PR.

[hamzakhan-rs]

@tangxifan I have rerun the tests on this PR and comparison sheets are attached.

Summary of QoR

1. titan_quick_qor test:
   flow run time -14.3% on average.
   critical path delay 0.26%
   Peak memory usage -1.5% on average

2. vtr_reg_qor_chain_depop test
   Flow run time -10.3% on average.
   critical path delay -0.13%
   Peak memory usage +17% on average

titan_quick_qor_comp.xlsx
vtr_reg_qor_chain_depop_comp.xlsx

[vaughnbetz]

Looks good. Will merge when CI goes green.
I imagine machine load is lower now than when the master ran (can't think of any other explanation for the reduced cpu time). In any case the QoR looks fine (too good in fact).

[tangxifan]

Looks good. Will merge when CI goes green.
I imagine machine load is lower now than when the master ran (can't think of any other explanation for the reduced cpu time). In any case the QoR looks fine (too good in fact).

Thank @vaughnbetz Will work on another API refactoring.

[tangxifan]

@vaughnbetz CI is green now. This PR is ready to merge.

[tangxifan]

Link to #1868 So that we keep tracking.