-
Notifications
You must be signed in to change notification settings - Fork 393
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
base: openfpga
Are you sure you want to change the base?
[WIP] VIB Upgrades for Tileable Routing Resource Graph on OpenFPGA #2637
Conversation
Add bend wires
Add vib info
Add vib info
Add vib info
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. |
There was a problem hiding this 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); |
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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++; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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++) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Description
Related Issue
Motivation and Context
How Has This Been Tested?
Types of changes
Checklist: