Cleaned up RRGraph Drawing Code - #3206
Conversation
|
It's probably good to add SOURCE and SINK viewing, probably with another checkbox to control clutter. You'd probably draw sources and sinks in some visually distinct way (circle for one and ellipse for the other?) with edges to pins where they connect. Physically they are inside the block, so in the interior of cluster-level blocks makes sense. For primitive level they would ideally be drawn in the primitive they belong to. But you'll have to figure out which primitive that is ... the net_rr_terminals data structure loader also figures that out so you could look at it. |
vaughnbetz
left a comment
There was a problem hiding this comment.
Nice cleanup!
Some comments embedded.
Biggest one: check the highlighting of rr_nodes works properly; you can simplify the code or change how it works, but we should be able to highlight nodes by (right) clicking on them and we should see their fanin and fanout edges highlighted too.
Future-proofing / next: @amin1377 has added support for a new MUX type. After this PR is in, you should test with an openFPGA tileable rr-graph on a small device to ensure it draws properly, and you should add MUX support. MUXes are like 0-length wires; we can draw them as points in a switch block I think but we'll have to allocate space for them etc. so it is probably a reasonable amount of work.
Future proofing 2: @soheilshahrouz has added support for CHANZ nodes. You should make sure those draw too in a future PR. At least we shouldn't crash, and most code that checks for CHANX and CHANY should have a CHANZ case too.
| if (to_type == e_rr_type::IPIN) { | ||
| color = blk_LIGHTSKYBLUE; | ||
| if (draw_state->draw_rr_node[to_node].node_highlighted && draw_state->draw_rr_node[inode].color == DEFAULT_RR_NODE_COLOR) { | ||
| // If the IPIN is clicked on, draw connection to all the CHANX |
There was a problem hiding this comment.
I think the overall highlighting code needs to be tested and this comment needs to be hoisted higher and updated.
I believe you can right click on an rr-node, and its fanin and fanout will be highlighted in certain colours. The highlighted node itself is drawn in magenta. You should test exactly what happens now, and see if you like it. I think the code can be simplified (which you've done) but you need to test we're doing some reasonable highlighting (idea: right click highlights and rr-node and its fan-in edges and fan-out edges).
There was a problem hiding this comment.
Maybe the highlighting can be simplified to something that just looks at the state of the prior and current rr-nodes (without paying attention to their type) and decides if an edge should be highlighted or not. I suspect we're being overly complex with the code that checks the node types (CHANX etc.). If we can simplify, we could just move it to a helper function to find the colour.
There was a problem hiding this comment.
I checked that the RRNode highlighting works. I think currently we have a global variable vtr::vector<RRNodeID, t_draw_rr_node> draw_rr_node; which stores information on whether the RRNode is highlighted or not.
|
Thanks. Let's merge this and fine-tune any rough edges after.
|
|
@vaughnbetz: Sorry for the late reply, I’m not sure how I missed your comment. You’re right: we don’t write out the RR Graph with intra-cluster resources because it’s design-specific, and we don’t have an echo file for that. It would be very helpful to have one, so I’ve created an issue for it and assigned it to myself. |
|
@vaughnbetz: Currently, the GUI does not provide an option to display only intra-cluster routing or only inter-cluster routing (when the flat router is used). Do you think it would be useful to add such an option? |
I've added that option. See #3236 |







Edges for each side are now drawn between inter-cluster and intra-cluster nodes. I’ve simplified the RRGraph drawing code by introducing reusable helper functions draw_rr_edge and draw_rr_node, while preserving all existing functionality and color schemes. I’ve also disabled the code that was drawing sources and sinks, as it didn’t seem to render correctly to begin with. Would it make sense to reimplement source/sink visualization, or is it something we want to leave out for now? In the next PR, I will probably hook up the new buttons to RRGraph drawing, so I left the toggle_RR variable unchanged for now.