-
Notifications
You must be signed in to change notification settings - Fork 108
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
Fix unroutability issues with new VPR #1711
Fix unroutability issues with new VPR #1711
Conversation
111e664
to
79c2a42
Compare
@litghost By removing the |
That makes sense. I'm going to work on fixing the vendor tool tests today, and after that we can re-run the CI here. |
@@ -1019,6 +1023,20 @@ def get_number_graph_edges(conn, graph, node_mapping): | |||
if dest_graph_node not in node_mapping: | |||
continue | |||
|
|||
src_node, src_node_type = node_mapping[src_graph_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.
Need a comment on what this is going?
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.
Consider factoring in a function?
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.
Factored in a function and added a docstring to it
src_node_is_site_pin = src_node_type in pin_node_types | ||
sink_node_is_site_pin = sink_node_type in pin_node_types | ||
|
||
# It may happen that a same CHAN <-> PIN edge is generated and this is unaccepted |
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.
This is bad, because that means that the underlying rr graph is less connected than the true hardware routing graph. Also this code is too pessimistic. VPR supports allowing multiple CHAN <-> PIN
edges if a different switch is used. So you need to account for that.
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 have added an assertion to check whether the switch is the same for the same CHAN <-> PIN
pair.
This was meant to avoid the error generated here
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.
Comments in. This fix is good, but actually points out a break in the VPR data model, I've filled an issue here: verilog-to-routing/vtr-verilog-to-routing#1577
(CHAN, PIN) pair with the same switch. | ||
|
||
It may happen that a same CHAN <-> PIN edge is generated and this is unaccepted | ||
by VPR, as it allows only multiple edges between CHAN nodes. |
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 error you linked now accommodates multiple CHAN <-> PIN edges? So this comment is 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.
Hmm, actually I think I found a bug in VPR, making this whole check useless. Testing it now
3fe9ba0
to
4578076
Compare
pin_name = pin.split(".")[-1] | ||
|
||
if pin_name not in pin_sides_dict[tile_name]: | ||
pin_sides_dict[tile_name][pin_name] = list() |
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.
Should use a set rather than a list here?
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, makes sense, fixed.
|
||
pins = loc.text.split() | ||
for pin in pins: | ||
pin_name = pin.split(".")[-1] |
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.
Please add a comment showing an example of pin
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.
Done
In particular, the issue seems to affect IO Pads.
This pin node results in having three corresponding graph nodes (sides locations). |
How close are you to debugging the new base cost calculation? If it is going to be a bit, let's recut master+wip and put in this fix. |
69b9f39
to
f41e3b9
Compare
f41e3b9
to
fa3e5be
Compare
Ibex route time dropped, and CPD increased, before:
after:
Theories? |
@litghost I'll need to look a closer look to this one. One possibility might be that the different way we connect site PINs to CHAN could have caused this? I cannot think about other reasons, as, apart from the different RR graph generated produced by VPR with one index for all the sides, there shouldn't have been other changes that influence the RR graph and the router. |
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 cannot think about other reasons, as, apart from the different RR graph generated produced by VPR with one index for all the sides, there shouldn't have been other changes that influence the RR graph and the router.
That's why I'm pointing this out. It surprised me :(
@litghost By building the ibex test locally with a clean repo, using this PR, the ibex CPD I get is |
…eam. Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
fa3e5be
to
a419837
Compare
Signed-off-by: Alessandro Comodi <acomodi@antmicro.com>
a419837
to
d299ba7
Compare
@litghost, with the bug with the non-deterministic ibex sv2v translation (fixed in #1782) and #1776 We cannot rely too much on results between different builds when comparing LiteX and Ibex designs. All other tests are deterministic, therefore, from #1711 (comment) we can take as valid only the We could compare other designs (e.g. scalable_proc) and, if everything looks fine and the code in this PR is ok, we could merge this, as it keeps holding the VtR+SymbiFlow CI going green. |
The newest VPR has fixed an issue with IPIN/OPIN RR nodes for which multiple RR nodes were emitted for the same site pin, due to the possible multiple side locations of the pin.
Therefore, with the new VPR, we cannot count on the presence of multiple nodes for the same pin during the routing import, to create the correct connections between the interconnection nodes and the site nodes.
This PR fixes this issue, assigning the same node ID to the directional graph nodes allowing to have multiple CHAN nodes connected to an IPIN/OPIN.
The corresponding VPR issue is the following one: verilog-to-routing/vtr-verilog-to-routing#1571.
This PR is expected to fail as with the current version of VPR, multiple nodes corresponding to the same site pin are emitted during the creation of the virtual RR graph.