Skip to content

Deploy RRGraphBuilder in RRGraph Clock Builder to replace the use of rr_node_indices #1801

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 7 commits into from
Jul 18, 2021

Conversation

tangxifan
Copy link
Contributor

Description

This PR focuses on updating RRGraph clock builder functions, where we use the refactored data structure RRGraphBuilder to replace the legacy data structure rr_node_indices.
This PR aims to eliminate the use of rr_node_indices in the RRGraph clock builder, as one step further in deprecating the legacy data structure.

Checklist:

  • Added a new API find_sink_nodes() to RRSpatialLookup
  • Eliminate the use of rr_node_indices for RRGraph Clock Builder
  • Delete obsoleted functions in rr_graph2.cpp which are replaced by built-in APIs in RRSpatialLookup

Related Issue

Motivation and Context

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

How Has This Been Tested?

After the previous PR #1779 , we start reworking all the source files that use the legacy data structure rr_node_indices in a high priority, in order to deprecate the legacy data structure as soon as possible.
Current statistics on the files that use rr_node_indices (in total there are 143 lines related):

  • ./route/clock_connection_builders.cpp
  • ./route/clock_network_builders.cpp
  • ./route/clock_network_builders.h
  • ./route/router_lookahead_map_utils.cpp
  • ./route/rr_graph.cpp
  • ./route/rr_graph2.cpp
  • ./route/rr_graph2.h
  • ./route/rr_graph_clock.cpp
  • ./route/rr_graph_clock.h
  • ./route/rr_graph_reader.cpp
  • ./route/rr_graph_util.cpp
  • ./route/rr_graph_uxsdcxx_serializer.h
  • ./route/rr_graph_writer.cpp

This PR will remove the use in

  • ./route/clock_connection_builders.cpp
  • ./route/clock_network_builders.cpp
  • ./route/clock_network_builders.h
  • ./route/rr_graph_clock.cpp
  • ./route/rr_graph_clock.h

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 Jul 14, 2021
@tangxifan
Copy link
Contributor Author

@mithro Not sure why the Yosys+ODINII strong tests always failed in a few second. The artifact log file is empty.

@tangxifan tangxifan requested review from vaughnbetz and hzeller July 15, 2021 17:50
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.

Thanks @tangxifan . Looks generally good, but I have some suggested changes / comments (none too major).

return sink_nodes;
}

/* By default, we always added the channel nodes to the TOP side (to save memory) */
Copy link
Contributor

Choose a reason for hiding this comment

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

This comment looks wrong (talking about channels).

This code also points out why we should rework the underlying rr_node_indices implementation; it's strange to have a multi-dimensional array matrix where some dimensions must always be accessed with a specific index. Hopefully that is on your near-term agenda Xifan. Could put a TODO in to refactor that way, if you think such a comment would be a useful reminder.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry for the typo. Just fixed it.
I think it will be a good time to rethink the rr_node_indices data structure once all the related APIs are replaced.
Actually, it is not too far. I expect only we need another 2 pull requests, before fully shadowing the current rr_node_indices.

I put a TODO to remind us during the refactoring. I will take a deep look into the rr_node_indices data structure and propose something.

}

for (const auto& node : rr_node_indices_[SINK][x][y][node_side]) {
if (RRNodeId(node)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could comment this to say you're inserting only the valid ids in the returned vector.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agree. Added the comment.

*
* Note:
* - Return an empty list if there are no sinks at the given (x, y) location
* - The node list returned only contain valid ids
Copy link
Contributor

Choose a reason for hiding this comment

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

typo: contain -> contains

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for pointing it out. Fixed.


return node_index;
return size_t(node_index);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we change the return type of this function to RRNodeId and remove the cast? (May have to change the calling function too some then).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just checked the dependency of this API. It is used only by another API. It is simple change. Done.

// However, since the SINK node has the same xhigh/xlow as well as yhigh/ylow, we can probably use a shortcut
for (int ix = rr_graph.node_xlow(node_index); ix <= rr_graph.node_xhigh(node_index); ++ix) {
for (int iy = rr_graph.node_ylow(node_index); iy <= rr_graph.node_yhigh(node_index); ++iy) {
node_lookup.add_node(node_index, ix, iy, rr_graph.node_type(node_index), rr_graph.node_ptc_num(node_index), SIDES[0]);
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like we use SIDES[0] to insert the sink node, and look for it later on the TOP side. Hence should we use TOP consistently or SIDES[0] consistently to make sure this is always in alignment? I assume SIDES[0] == TOP so this all works, but it still seems dangerous as if anyone ever edits the order of SIDES we'd subtly break code written this way.

Copy link
Contributor Author

@tangxifan tangxifan Jul 17, 2021

Choose a reason for hiding this comment

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

Agree. We should not expose the side argument to developers because they may feel confused.
You are right on the SIDE[0] which is actually the TOP side. This convention has been there for a while (I do not know who introduced it). I am o.k. to change it if necessary.
Indeed, developers may mess up.
For example, they added a channel node to the BOTTOM side but in find_node(), it will always search the TOP side.

e_side node_side = side;
if (type == IPIN || type == OPIN) {
VTR_ASSERT_MSG(side != NUM_SIDES, "IPIN/OPIN must specify desired side (can not be default NUM_SIDES)");
} else {
VTR_ASSERT_SAFE(type != IPIN && type != OPIN);
node_side = SIDES[0];
}

However, I think it is not a good idea to force the developers to give a dummy side when addethe API. I modified the API so that the side option will have a default value (SIDE[0]) if not specified. In client functions, I remove all the usage of the SIDE[0] for non-IPIN/OPIN nodes.

@@ -320,7 +319,7 @@ void ClockToPinsConnection::create_switches(const ClockRRGraphBuilder& clock_gra

//Create edges depending on Fc
for (size_t i = 0; i < clock_network_indices.size() * fc; i++) {
clock_graph.add_edge(rr_edges_to_create, clock_network_indices[i], clock_pin_node_idx, arch_switch_idx);
clock_graph.add_edge(rr_edges_to_create, clock_network_indices[i], size_t(clock_pin_node_idx), arch_switch_idx);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we change the function prototype to avoid the cast (send in an RRNodeId instead)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See my reply in a previous comment on the t_rr_edge_info

//TODO: CHANX uses odd swapped x/y indices here. Will rework once rr_node_indices is shadowed
rr_graph_builder.node_lookup().add_node(chanx_node, iy, ix, rr_graph.node_type(chanx_node), rr_graph.node_ptc_num(chanx_node), SIDES[0]);
}
}

return node_index;
Copy link
Contributor

Choose a reason for hiding this comment

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

Consider changing return type to RRNodeId, and directly making node_index an RRNodeId (and therefore wouldn't need chanx_node).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, I believe, we can use the API add_node_to_all_locs() as you suggested in another PR #1800. These for loops will be replaced by a simple line:

rr_graph_builder.add_node_to_all_locs(chanx_node)

I leave a TODO comment here to remind me to finish the API replacement after PR #1800 is merged.
Let me know if this is fine for you.

@vaughnbetz
Copy link
Contributor

Note: the Yosys+Odin-II failure is an expected, unrelated failure and is not gating.

@vaughnbetz
Copy link
Contributor

Looks good; thanks.

@vaughnbetz vaughnbetz merged commit 78cd631 into master Jul 18, 2021
@vaughnbetz vaughnbetz deleted the rr_graph_clock_refactor branch July 18, 2021 18:33
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.

2 participants