You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can visualize the routing between clusters, but can't visualize it within clusters (flat routing). There is some ability to visualize clustering decisions, and that also may allow us to see some of the routing inside clusters, but I believe the graphics for this are incomplete.
Proposed Behaviour
Investigate exactly how much you can see inside clusters right now, and make the routing visible.
Possible Solution
Draw the OPINs and IPINs and edges that represent the connectivity in the cluster, using the rr-graph (to show the rr-graph nodes and edges) and the routed nets (to show the used OPINs, IPINs, etc.). This would require significant updates to the code that can draw OPINs and IPINs to have it check if the OPINs and IPINs are inside the cluster, and pick reasonable drawing locations for everything based off the rr-graph and/or architecture file. If the OPINs and IPINs are drawn properly, and the edges between them can also be drawn properly, I think the various routing, rr-graph, congestion and timing views would all work, as they call these low-level drawing routines.
Context
We can perform flat routing, but can only partially visualize it. This would fix that.
The text was updated successfully, but these errors were encountered:
We can visualize the routing between clusters, but can't visualize it within clusters (flat routing). There is some ability to visualize clustering decisions, and that also may allow us to see some of the routing inside clusters, but I believe the graphics for this are incomplete.
Proposed Behaviour
Investigate exactly how much you can see inside clusters right now, and make the routing visible.
Possible Solution
Draw the OPINs and IPINs and edges that represent the connectivity in the cluster, using the rr-graph (to show the rr-graph nodes and edges) and the routed nets (to show the used OPINs, IPINs, etc.). This would require significant updates to the code that can draw OPINs and IPINs to have it check if the OPINs and IPINs are inside the cluster, and pick reasonable drawing locations for everything based off the rr-graph and/or architecture file. If the OPINs and IPINs are drawn properly, and the edges between them can also be drawn properly, I think the various routing, rr-graph, congestion and timing views would all work, as they call these low-level drawing routines.
Context
We can perform flat routing, but can only partially visualize it. This would fix that.
The text was updated successfully, but these errors were encountered: