Skip to content
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

[WIP] VIB Upgrades for Tileable Routing Resource Graph on OpenFPGA #2637

Open
wants to merge 131 commits into
base: openfpga
Choose a base branch
from

Conversation

tangxifan
Copy link
Contributor

@tangxifan tangxifan commented Jul 2, 2024

Description

Related Issue

Motivation and Context

image
image

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

@danahow
Copy link

danahow commented Nov 1, 2024

Why are bent wires being added? They are a special case (subset) of hardened wires, explored two decades ago in https://dl.acm.org/doi/10.1145/1046192.1046196 , which showed benefits unconvincing enough the work was not continued. More recent work is not supportive either. No major commercial devices include them. This adds complexity w/o increasing functionality.

Copy link
Contributor Author

@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.

@Wang-Yuanqi-source Please start adding documentation and testcase. We are close to be merged. Most of the codes are clean now. Thank you for the effort!

device_chan_width,
segment_inf_x, segment_inf_y,
device_grid_annotation,
shrink_boundary,
perimeter_cb,
through_channel);
through_channel,
is_vib_arch);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since you already pass the vib_grid at LINE168, the flag is_vib_arch is redundant and can be removed here.

@@ -103,8 +103,9 @@ void build_rr_graph_edges_for_sink_nodes(const RRGraphView& rr_graph,
***********************************************************************/
void build_rr_graph_edges(const RRGraphView& rr_graph,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Now I understand that the mechanism to build edges for VIB will be very different from the current one. We should create a dedicated function for the VIB, e.g., build_rr_graph_vib_edges(). The current build_rr_graph_edges() will be still there but includes two sub-functions: build_rr_graph_regular_edges() and build_rr_graph_vib_edges().

for (size_t iy = 0; iy < grids.height(); ++iy) {

const VibInf* vib = vib_grid.get_vib(layer, ix, iy);
if (vib == nullptr) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Avoid to use any nullptr. Instead, use API like empty() or is_valid()

if (0 == itrack % seg_len) {
seg_start = true;
else{ // bend segment
bend_num++;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I understand that you rely on the bend_num find the pairs of bent wires in X- and Y- channel. What if we have different routing channel width in X- and Y- channel ? And we may have different segment distribution in X- and Y- channel. I see the codes here only work in a restricted condition.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Another question is that how are the bent wires impacting the actual routing channel width? When the routing channel width and its wire distribution is defined in the architecture file, are all the bent wires taken into account?

For example, if 4 bent wires are defined in the X-direction channel, should we also define 4 bent wires in the Y-direction channel, in order to match the number?

Or when 4 bent wires are defined in the X-direction channel, the Y-direction channel will automatically include 4 bent wires without any explicit definition in architecture files?

Choose a reason for hiding this comment

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

If bent wires are defined in X-direction channel, the same number of bent wires should be defined in Y-direction channel.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

O.K. Is there any syntax check or legality checks to ensure this requirement? If not, we should have them somewhere (prefer at parser, if not possible, then in the rr_graph builder)

}

size_t count = 0;
for (size_t i_first_stage = 0; i_first_stage < vib->get_first_stages().size(); i_first_stage++) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I remember that you mention that VIB at the right side and top side of the FPGA will have a different arrangement on connectivity. The codes here does not reflect such corner cases. If so, the estimated number of medium numbers will be very different and the pre-allocation on memory could be wrong.

Choose a reason for hiding this comment

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

I just modify the coordinates of MEDIUM nodes and edges between nodes in the right side and top side.The number of MEDIUM nodes remains the same.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

o.k. it should not impact the total number of nodes then.

@@ -186,6 +197,9 @@ class RRGSB {
void add_opin_node(const RRNodeId& node,
const e_side& node_side);

/* Add a node to the medium_node_ */
void add_medium_node(const RRNodeId& medium_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.

Good effort. Can you also include the MUX name that is defined in your VIB architecture as one of the internal data of GSB? It is debugging and callback. Thanks!

Choose a reason for hiding this comment

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

Yes, I will try to add the information of the MUX name.

for (size_t i_mux = 0; i_mux < vib_grid.num_medium_nodes(i_layer, ix, iy); i_mux++) {
mux_name_map.emplace(vib_grid.medium_node_name(i_layer, ix, iy, i_mux), i_mux);
}
medium_mux_name2medium_index[i_layer][ix][iy] = mux_name_map;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I believe you should cache the information inside VIB or create a dedicated API in VIB, e.g.,

std::string medium_mux_name_by_index(const size_t& index);
size_t medium_mux_index_by_name(const std::string& name);


}

// process right boundary
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I suggest to remove the corner case here. All the I/Os can have their VIB on the top-right corner just like any other tile. This should be the default case.

If any user does not want I/O have their own VIB, they should define it in the VIB arch where they merge the VIB of I/O into adjancent tiles. This should be done through architecture XML, rather than an implicit way

/* Second stages*/
const std::vector<t_second_stage_mux_inf> second_stages = vib->get_second_stages();
for (size_t i_second_stage = 0; i_second_stage < second_stages.size(); i_second_stage++) {
std::vector<t_from_or_to_inf> froms = second_stages[i_second_stage].froms;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Any difference between the first stage and second stage when checking the nodes and wires? If not, the big content inside the for-loop and be replaced by a common function. What do you think? Bug me if I was wrong.

Choose a reason for hiding this comment

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

The checks for the first stage and the second stage are different, because their "from" and "to" node types are different.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

O.K. for now. We will refactor this part later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lang-cpp C/C++ code libarchfpga Library for handling FPGA Architecture descriptions VPR VPR FPGA Placement & Routing Tool
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants