Skip to content

RRGraphView edges(), num_edges(), configurable_edges(), non_configurable_edges(), num_configurable_edges(), num_non_configurable_edges() Implementation #1917

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

Merged
merged 22 commits into from
Dec 14, 2021

Conversation

behzadmehmood-rs
Copy link
Contributor

@behzadmehmood-rs behzadmehmood-rs commented Nov 18, 2021

Description

In this PR, I am implementing RRGraphView::edges(), RRGraphView::num_edges(), RRGraphView::configurable_edges(), RRGraphView::non_configurable_edges(), RRGraphView::num_configurable_edges() and RRGraphView::num_non_configurable_edges() throughout VTR. Each device_ctx.rr_nodes[node].edges() call has been replaced with rr_graph.num_edges(RRNodeId(node)). The same pattern was followed for the other functions in this PR. In order to do this, I followed a pattern similar to that in the last PR.

Related Issue

Motivation and Context

These changes are a continuation of the RRGraphView API implementation effort.

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

@github-actions github-actions bot added the VPR VPR FPGA Placement & Routing Tool label Nov 18, 2021
@behzadmehmood-rs behzadmehmood-rs changed the title Added API for num_configurable_edges RRGraphView::num_configurable_edges() Implementation Nov 18, 2021
@behzadmehmood-rs behzadmehmood-rs changed the title RRGraphView::num_configurable_edges() Implementation RRGraphView configurable_edges(), non_configurable_edges(), num_configurable_edges(), num_non_configurable_edges() Implementation Nov 19, 2021
@@ -90,10 +90,6 @@ inline t_edge_size t_rr_node::num_non_configurable_edges() const {
return storage_->num_non_configurable_edges(id_);
}

inline t_edge_size t_rr_node::num_configurable_edges() const {
Copy link
Contributor

Choose a reason for hiding this comment

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

Good. Can you double check this removal in the #1916?

@behzadmehmood-rs behzadmehmood-rs marked this pull request as ready for review November 25, 2021 04:45
@behzadmehmood-rs behzadmehmood-rs marked this pull request as draft November 25, 2021 04:53
@behzadmehmood-rs behzadmehmood-rs changed the title RRGraphView configurable_edges(), non_configurable_edges(), num_configurable_edges(), num_non_configurable_edges() Implementation RRGraphView edges(), num_edges(), configurable_edges(), non_configurable_edges(), num_configurable_edges(), num_non_configurable_edges() Implementation Nov 30, 2021
Copy link
Contributor

@tangxifan tangxifan left a comment

Choose a reason for hiding this comment

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

@behzadmehmood-rs Please check my comments on the rr_graph_uxsdcxx_serializer.h
This PR is almost there.
After applying these comments, please wait until the CI is green before starting QoR tests.

@behzadmehmood-rs
Copy link
Contributor Author

behzadmehmood-rs commented Dec 10, 2021

QoR tests are complete and quick summary is given below. QoR comparison files are also attached.
vtr_reg_qor_chain_depop test:
Flow run time 12.17% on average.
critical path delay 0% on average.
Peak memory usage -0.1% on average
titan_quick_qor test:
flow run time 33.31% on average.
critical path delay 0% on average.
Peak memory usage -0.01% on average
titan_quick_qor.xlsx
vtr_reg_qor_chain_depop.xlsx

@tangxifan
Copy link
Contributor

@behzadmehmood-rs Thanks for the effort. It looks fine. Can you compare to current master also (see if the runtime overhead is indeed due to this PR or not)?

@tangxifan tangxifan marked this pull request as ready for review December 10, 2021 06:22
@behzadmehmood-rs
Copy link
Contributor Author

@behzadmehmood-rs Thanks for the effort. It looks fine. Can you compare to current master also (see if the runtime overhead is indeed due to this PR or not)?

Sure, will do that.

@behzadmehmood-rs
Copy link
Contributor Author

behzadmehmood-rs commented Dec 13, 2021

@behzadmehmood-rs Thanks for the effort. It looks fine. Can you compare to current master also (see if the runtime overhead is indeed due to this PR or not)?

QoR tests for master branch are complete and quick summary is given below. QoR comparison files are also attached.
vtr_reg_qor_chain_depop test:
Flow run time 12.24% on average.
critical path delay 0% on average.
Peak memory usage -0.02% on average
titan_quick_qor test:
flow run time 21.61% on average.
critical path delay 0% on average.
Peak memory usage -0.01% on average

titan_quick_qor.xlsx
vtr_reg_qor_chain_depop.xlsx

Copy link
Contributor

@tangxifan tangxifan left a comment

Choose a reason for hiding this comment

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

@behzadmehmood-rs I see the runtime overhead. They are mainly from placement and routing. It indicates that our modification slows down the algorithm. I suspect the use of RRGraphView in rr_node.cpp is the source. Would you mind revert it to previous codes for validate()? See if this is the cause or not.

@behzadmehmood-rs
Copy link
Contributor Author

@behzadmehmood-rs I see the runtime overhead. They are mainly from placement and routing. It indicates that our modification slows down the algorithm. I suspect the use of RRGraphView in rr_node.cpp is the source. Would you mind revert it to previous codes for validate()? See if this is the cause or not.

Sure, will do that.

@behzadmehmood-rs
Copy link
Contributor Author

@behzadmehmood-rs I see the runtime overhead. They are mainly from placement and routing. It indicates that our modification slows down the algorithm. I suspect the use of RRGraphView in rr_node.cpp is the source. Would you mind revert it to previous codes for validate()? See if this is the cause or not.

QoR tests after reverting changes for validate() are complete and quick summary is given below. QoR comparison files are also attached.
vtr_reg_qor_chain_depop test:
Flow run time 9.93% on average.
critical path delay 0% on average.
Peak memory usage -0.08% on average
titan_quick_qor test:
flow run time 20.46% on average.
critical path delay 0% on average.
Peak memory usage -0.02% on average

titan_quick_qor.xlsx
vtr_reg_qor_chain_depop.xlsx

@behzadmehmood-rs
Copy link
Contributor Author

@tangxifan I have compared results after reverting changes for validate() and uploaded the files. Should I push changes to the branch?

@tangxifan
Copy link
Contributor

@tangxifan I have compared results after reverting changes for validate() and uploaded the files. Should I push changes to the branch?

Is it compared to the current master or a branch which is created before the whole refactoring effort?

@behzadmehmood-rs
Copy link
Contributor Author

@tangxifan I have compared results after reverting changes for validate() and uploaded the files. Should I push changes to the branch?

Is it compared to the current master or a branch which is created before the whole refactoring effort?

It is compared with test_sanity_basic branch

@tangxifan
Copy link
Contributor

@behzadmehmood-rs Sure. Can you let me know any changes on the runtime when reverted?

@behzadmehmood-rs
Copy link
Contributor Author

behzadmehmood-rs commented Dec 14, 2021

@behzadmehmood-rs Sure. Can you let me know any changes on the runtime when reverted?

@tangxifan following changes were made.

rr_node
rr_node_impl

@tangxifan
Copy link
Contributor

@behzadmehmood-rs Can you show me the changes on runtime? I am cool with the code changes.

@behzadmehmood-rs
Copy link
Contributor Author

behzadmehmood-rs commented Dec 14, 2021

@tangxifan I have compared results after reverting changes for validate() and uploaded the files. Should I push changes to the branch?

Is it compared to the current master or a branch which is created before the whole refactoring effort?

QoR comparison results with master branch and the current branch after reverting cahnges for validate() are given below. QoR comparison files are also attached.
vtr_reg_qor_chain_depop test:
Flow run time -2.06% on average.
critical path delay 0% on average.
Peak memory usage -0.06% on average
titan_quick_qor test:
flow run time -0.95% on average.
critical path delay 0% on average.
Peak memory usage -0.02% on average

titan_quick_qor_master.xlsx
vtr_reg_qor_chain_depop_master.xlsx

@tangxifan
Copy link
Contributor

This looks good to me now. Please revert the changes. Thanks a lot!

@behzadmehmood-rs
Copy link
Contributor Author

This looks good to me now. Please revert the changes. Thanks a lot!

I have pushed reverted changes.

@tangxifan
Copy link
Contributor

tangxifan commented Dec 14, 2021

@behzadmehmood-rs No worries. Can you fix the errors in CI?
Waive red flag on the strong sanitized test.
Once CI is green, I will propose to merge.

@behzadmehmood-rs
Copy link
Contributor Author

behzadmehmood-rs commented Dec 14, 2021

@behzadmehmood-rs No worries. Can you fix the errors in CI? Waive red flag on the strong sanitized test. Once CI is green, I will propose to merge.

@tangxifan kindly review.

@tangxifan
Copy link
Contributor

@behzadmehmood-rs Look good to me. I propose to merge this week. Good work.

@tangxifan
Copy link
Contributor

@vaughnbetz I have reviewed this PR several times. QoR test is clean. I propose to merge. If you see any issue, feel free to comment. I will actively work on it.

@tangxifan tangxifan merged commit 6aa5209 into verilog-to-routing:master Dec 14, 2021
@tangxifan tangxifan deleted the api_num_configurable_edges branch December 14, 2021 22:08
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