Skip to content

Add a new API set_node_ptc_num() to RRGraphBuilder #1865

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from
Closed

Add a new API set_node_ptc_num() to RRGraphBuilder #1865

wants to merge 5 commits into from

Conversation

m-hariszafar
Copy link

@m-hariszafar m-hariszafar commented Oct 1, 2021

Description

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

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

Checklist:

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

Related Issue

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

Motivation and Context

This PR is the continuation of the refactoring effort with a focus on shadowing the rr_graph_storage APIs in the RRGraphBuilder data structure.
This PR reworks the set_node_ptc_num() API among the other APIs in #1847

How Has This Been Tested?

  • All vtr basic and strong tests are passing.

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

@github-actions github-actions bot added the VPR VPR FPGA Placement & Routing Tool label Oct 1, 2021
@m-hariszafar
Copy link
Author

QoR tests are completed and a quick summary is given below. QoR comparison files are also attached.

titan_quick_qor test:
flow run time +2.05% on average.
critical path delay +0.26% on average.
Peak memory usage -1.8% on average

vtr_reg_qor_chain_depop test:
Flow run time -0.31% on average.
critical path delay -0.14% on average.
Peak memory usage -3.34% on average

Here are the attached files
vtr_reg_qor_chain_depop.xlsx
titan_quick_qor.xlsx

@m-hariszafar m-hariszafar marked this pull request as ready for review October 5, 2021 05:48
@m-hariszafar
Copy link
Author

@tangxifan

@@ -65,6 +65,13 @@ class RRGraphBuilder {
node_storage_.set_node_coordinates(id, x1, y1, x2, y2);
}

/** @brief Set the node_ptc_num; The ptc (pin, track, or class) number is an integer
* that allows you to differentiate between wires, pins or sources/sinks with overlapping x,y coordinates or extent.
* This is useful for drawing rr-graphs nicely.*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The set_node_ptc_num is a tricky API because the set_ptc_num carries different meanings for different type of nodes.
You can see that there are other APIs which try to clarify this, for example,

  • set_node_track_num() is for CHANX and CHANY nodes
  • set_node_pin_num() is for OPIN and IPIN nodes
  • set_node_class_num() is for SOURCE and SINK nodes

Therefore, I am thinking about if we should

  • refactor all the APIs above in one pull request
  • evaluate if we should deprecate the API set_node_ptc_num() and use other APIs instead. If we cannot, I am o.k. to keep the API.

@vaughnbetz Please share your thoughts.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hariszafar-lm I have talked to @vaughnbetz today. He agrees on the roadmap here. Please give a try. Also remember to fix the merging conflicts.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tangxifan Sure, I'll start it from today. thanks

Copy link
Contributor

@vaughnbetz vaughnbetz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should replace some (maybe all) set_node_ptc_num calls with calls to the more specific set_node_xx_num methods.

@@ -106,7 +106,7 @@ RRNodeId RoutingToClockConnection::create_virtual_clock_network_sink_node(int x,
}
int ptc = max_ptc + 1;

rr_graph.set_node_ptc_num(node_index, ptc);
rr_graph_builder.set_node_ptc_num(node_index, ptc);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This node is a SINK, so we should be able to use the set_node_class_num() api here now. Best to avoid the set_node_ptc_num () (which is more vague) as much as possible.

@@ -1433,7 +1433,7 @@ static void build_rr_sinks_sources(RRGraphBuilder& rr_graph_builder,
float R = 0.;
float C = 0.;
L_rr_node.set_node_rc_index(inode, find_create_rr_rc_data(R, C));
L_rr_node.set_node_ptc_num(inode, iclass);
rr_graph_builder.set_node_ptc_num(inode, iclass);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use set_node_class_num instead (this is for SINKs and SOURCEs).

@@ -1671,7 +1671,7 @@ static void build_rr_chan(RRGraphBuilder& rr_graph_builder,
float C = length * seg_details[track].Cmetal();
L_rr_node.set_node_rc_index(node, find_create_rr_rc_data(R, C));

L_rr_node.set_node_ptc_num(node, track);
rr_graph_builder.set_node_ptc_num(node, track);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use set_node_track_num() instead.

Copy link
Author

@m-hariszafar m-hariszafar Oct 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @tangxifan and @vaughnbetz,
I replaced this one with set_node_track_num() and it is firing an exception of Attempted to set RR node 'track_num' for non-CHANX/CHANY type '(null)'. Do we have an alternative or we should keep with the previous one set_node_ptc_num()?
As it is passing with set_node_ptc_num().

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is failing for all basic to strong tests.
test-runs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hariszafar-lm This is because the set_node_type() is called after this API. If you move the LINE 1675 before this line. it should work.

@@ -1481,7 +1481,7 @@ static void build_rr_sinks_sources(RRGraphBuilder& rr_graph_builder,
float R = 0.;
float C = 0.;
L_rr_node.set_node_rc_index(inode, find_create_rr_rc_data(R, C));
L_rr_node.set_node_ptc_num(inode, ipin);
rr_graph_builder.set_node_ptc_num(inode, ipin);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use set_node_pin_num() instead

@@ -604,7 +604,7 @@ class RrGraphSerializer final : public uxsd::RrGraphBase<RrGraphContextTypes> {
RRNodeId node_id = node.id();

rr_graph_builder_->set_node_coordinates(node_id, xlow, ylow, xhigh, yhigh);
node.set_ptc_num(ptc);
rr_graph_builder_->set_node_ptc_num(node_id, ptc);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only call that really needs to set a ptc_num, no matter what type of node it is. If the node type is already set, we could replace this with an if statement that checks the type and calls the right set_node_xx_num() call, and then delete the set_node_ptc_num() method.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that isn't easily doable, we can leave this call and the method.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tangxifan what do you suggest on this? Either we should keep it to the set_node_ptc_num() method or else?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. We should keep the set_node_ptc_num() API here

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, thanks for quick response

@@ -1671,7 +1671,7 @@ static void build_rr_chan(RRGraphBuilder& rr_graph_builder,
float C = length * seg_details[track].Cmetal();
L_rr_node.set_node_rc_index(node, find_create_rr_rc_data(R, C));

L_rr_node.set_node_ptc_num(node, track);
rr_graph_builder.set_node_ptc_num(node, track);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hariszafar-lm This is because the set_node_type() is called after this API. If you move the LINE 1675 before this line. it should work.

@tangxifan
Copy link
Contributor

@hariszafar-lm Also, you need to resolve the merging conflicts

@tangxifan
Copy link
Contributor

Link to #1868 So that we keep tracking.

@tangxifan
Copy link
Contributor

Close ad PR #1872 merged

@tangxifan tangxifan closed this Dec 17, 2021
@tangxifan tangxifan deleted the api_set_node_ptc_num branch December 17, 2021 22:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
VPR VPR FPGA Placement & Routing Tool
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants