Dangling interconnect occurs when connecting a wire to a switch of type short

[WhiteNinjaZ]

Current Behavior

For some reason, when an interconnect is specified between a wire and a wire with an arch_wire_switch of type short there are some cases when unspecified interconnect occurs. For example, if a user specifies a custom SB that connects segments from bottom to left using an arch_wire_switch of type short, a connection will also be made from the bottom to the right as shown in the image below. The architecture I used to create this example had only one switch block who's permutation function only allowed for a single connections to occur from bottom to left (i.e. type="bl"). There are two types of wire connections shown: far right to upper left(in red)--a wire with a arch_wire_switch of a normal mux type (showing that normal interconnect works as expected), far left to mid right and mid left (in purple)--a wire connecting to a segment with a short interconnect:

This phenomenon also occurs on the edges of the FPGA when there is nothing for the shorted wire to connect too:

This phenomenon occurs in both custom and default switch block types and for both bi-direction and uni-directional architectures. From what I can tell it occurs when interconnect that travels from tl, rb, lb, and bl are specified.

Possible Solution

Not sure if this is a RR generation bug (i.e. extra edges are created) or a graphics bug (extra edge is drawn but does not actually exist in the RR graph). I have noticed that although an extra connection is drawn, it appears that the wire is not actually physically connected in the architecture. It also appears that the extra connection is always made between an outgoing wire to an outgoing wire.

[vaughnbetz]

@WhiteNinjaZ : can you look at the rr-graph.echo file (or write out an xml) to see if the edges exist or not. If they aren't (then graphics issue): Sebastian, can you take a look?

[WhiteNinjaZ]

@WhiteNinjaZ : can you look at the rr-graph.echo file (or write out an xml) to see if the edges exist or not. If they aren't (then graphics issue): Sebastian, can you take a look?

@vaughnbetz The echo files didn't seem to provide much useful info regarding the SB interconnect, however turning on verbose (i.e. setting constexpr bool verbose = true; on line 863 of build_switchblocks.cpp) did seem to give some useful data. The following is taken from vpr.out and shows the interconnect for the switch block in the first picture above:

## Build routing resource graph
...
SB_LOC: 2,1 BOTTOM->LEFT
  num_conns: 1
  make_conn: 6 -> 7 switch=2
...

As you can see, there is only one edge from the bottom->left (switch 2 is a switch of short type) and no edge from the bottom->right is given, so it must be a graphics issue. @SebastianLievano can you take a look. Here is an example of an architecture file that demonstrates the issue (note: I was originally using the functionality of PR #2067 to demonstrate this issue since the changes made in that PR allow for a finer control of specifying that only certain segments are shorted together. The xml I give here though will work with the current version of VTR and demonstrates the same issue. I used a width of 20 in my tests with stereovision3.v as the verilog file): short_bug_example.xml

[vaughnbetz]

Thanks. If you also click on the two wires in question to get their rr_node ids, you can check if there is an edge between those two nodes in the rr-graph. That's a good check to do as well since you're checking the final data structure; it will help localize the problem between sb->rr-graph creation (stamping out the sb across the whole chip) or draw/visualization.

[WhiteNinjaZ]

Sure, I had vtr write out an xml of the graph (using --write_rr_graph) and I can confirm that the there is no edge from the bottom segment's node (pictured) to the right segment's node.

I give a verbose methodology bellow as well as the rr-graph in case it might be helpful for debugging For the shorted wire in question (looking at Sb (2,1)): Bottom wire is RR node 1246, left is 1099, and right is 1117. There is an edge from 1246->1099(B->L) and from 1099->1246 (since shorts are bi-directional), but there is no edge from 1246->1117 (no physical phantom connection in the RR). Node 1117 (the wire with a phantom connection pictured) only has edges connecting to logic blocks through the CB's as should be expected. check_rr.xml

[vaughnbetz]

Thanks. @SebastianLievano : when you're free it would be good for you to sync up with Joshua so you can reproduce and debug the graphics issue.

[SebastianLievano]

NOTE: All of this was tested and done in the example architecture/circuit you provided

So I looked pretty deeply into the code for the issue, and me and Prof. Betz came to the conclusion that there may be something wrong with when you are creating these connections, at least in terms of their directions. These lines of code here are what is drawing the dangling interconnect. As you can see, they only run when the direction of the node is not bi-directional (i.e The node has one set direction). This is in the rr_edge drawing function draw_chanx_to_chany_edge .

This function (draw_chanx_to_chany_edge) is called twice for any pair of nodes that end up producing a dangling interconnect, once with the enum e_edge_dir parameter set to FROM_X_TO_Y and once with it set to FROM_Y_TO_X. In the example circuit provided, all of the dangling interconnects occur in the FROM_X_TO_Y drawing calls. However, it could be that FROM_Y_TO_X can also create dangling interconnects but no such errors occured in the example circuit.

Anyways, the main point here is that the edge between these two nodes is being drawn twice, once in each direction. However, the node is not set as being Bidirectional, leading to the second interconnect being drawn offset from the first interconnect, as opposed to being drawn overlapping like they should be.

Any thoughts/opinions on this?? @WhiteNinjaZ @vaughnbetz

[vaughnbetz]

Thanks @SebastianLievano . @WhiteNinjaZ : as Sebastian says we discussed this in some detail. I'm pretty sure you are created two edges (a bidirectional connection) between two rr_nodes, but the architecture / segments are marked as unidirectional. The drawing code assumes wires have start (drive) points at one end in that case. One edge draws properly (the one driving the start point of the receiving wire) but the backward edge (from the receiving wire to the source wire) doesn't.

We could potentially make the drawing code handle this case, but it is a bit bizarre. We draw little buffers to show which way a direction edge/wire is going, and those are going to be wrong when you have a backward connection to a directional wire. It also doesn't really make electrical sense as a directional wire is driven by a single mux, so all the fanin to that mux should be nearby. That won't be the case for these backward edges.

Now I guess the custom switch block you created is making a short, so it really is bidirectional. But the drive point (mux) should really be one either the first wire sub-segment or the second, so you could just add one of the other short connections (the one that goes to from the start wire to the end wire). That may fix the drawing problem.

If we need to keep the two edges, we can probably update the drawing code to draw this but we'll have to examine all the logic. Basically we would have to get rid of the assumption that an architecture is all unidirectional or all bidirectional; these switches mix some bidirectional edges into a mostly unidirectional architecture.

This is probably worth discussing in a Thursday meeting.