Questions about FPGA Routing Architecture Visualization

[LucaMartis00]

Hello,

I have a question regarding the graphical representation of the routing architecture.

The channel width is set to a fixed value of 20, which corresponds to the number of channels highlighted in yellow. However, in other areas, such as the section highlighted in orange, the number of channels decreases to 10.

Why does this happen? Shouldn't the channel width remain constant across the FPGA, resulting in 20 channels throughout?

I would appreciate your assistance.

[vaughnbetz]

I suspect you are getting some edge effects. If your wires are unidirectional (the most common type), some of the wires at the edge (those that would go left) have their drivers cut off and are unusable. Hence they have been removed, and don't draw.

1. Try a bigger chip and see if you only see this behaviour at the edge.
2. Write out the rr-graph in xml format (see the vpr command line options) and see if there are some wires in the rr-graph that don't display, or they've actually been removed due to the edge effect.

It is surprising this happens only on the right / top edge of the chip and not on the left / bottom though.

[LucaMartis00]

Same behavior with a 13x13 FPGA

What I noticed is that this problem appears only with a segment greater than 1. If I set it to 1, the routing architecture seems fine.

[LucaMartis00]

I generated the RR graph of the FPGA shown in the photo, but I don't fully understand it. It seems that all the wires are present, but I'm not entirely sure.

I have attached the RR graph in a zip file, which contains the .xml format.

rr_graph.zip

[vaughnbetz]

The ptc_nums for a bunch of the rr nodes are odd. E.g.:

The ptc_num has a range, which I haven't seen before. All the wires seem to be there, but the ones with a range of ptc_nums seem to be drawn just using the first ptc_num, or perhaps not drawn (both would look the same I think since they would be drawn on top of each other for the first case). Maybe this is an Open FPGA related feature? Was this rr-graph generated by VPR or brought in from an external tool?

@saaramahmoudi : I know you put a form of ptc_num needed by vtr in the code; could it be leading to this range of values printing out? @soheilshahrouz : adding you in case you have any time to dig into this.

[vaughnbetz]

According to the documentation at https://docs.verilogtorouting.org/en/latest/vpr/file_formats/#routing-resource-graph-file-format-xml, ptc can only be an int, not a list. So I'm not sure what added the ptc list in the attached file.

[saaramahmoudi]

@vaughnbetz
I checked the attached RR graph and it seems to be generated using Openfpga branch of VPR (not the VPR master branch). The ptc definition for Openfpga and vpr is different. Openfpga assign one ptc for each part of L4 wires, meaning that an L4 wire has four ptcs not one, as you see in the rrgraph. For instance, a complete L4 (not a truncated one) would have four ptc numbers like "0,2,4,6" and the number is unique across one tile. One the other hand, vpr assign one ptc number to the whole L4 wire and the number is always unique.

[danahow]

Note that the VPR ptc number will always be the first in the OpenFPGA-generated list. Consequently, when we were using both VPR and OpenFPGA, we would take the string contents in ptc="" and drop the first comma through the end of the string. Now we use only VPR-style so this is not needed, but we keep it for backward compatibility. I believe @saaramahmoudi added twist="" or similar to VPR's rr_graph dump, which is fine, but we haven't started using it. The comments about uniqueness are correct. Thanks.

[vaughnbetz]

I think that's the reason for the unusual drawing then @LucaMartis00 . The other wires are there, but drawn on top of each other (as the ptc number is used to decide where to draw wires in a channel, and it seems the openfpga branch is assigning ptc numbers that overlap if you just take the first one in the list). Do you need to use openfpga to generate the rr-graph? If so, the only way to make it draw more nicely would be to write some code to traverse the rr-graph and fix up the ptc numbers (choose better ones to draw more nicely).

[LucaMartis00]

Hi, thanks for your help.
Yes, I use the VPR version of OpenFPGA to generate the graph.
If I understand correctly, the wires are present but are overlapped, so I cannot see them?

One question about the meaning of L4: does it mean that a wire behaves as if it connects one CLB to another without interruptions?

[vaughnbetz]

Yes, some wires are drawn on top of each other. If you right click on them to highlight them you will probably see that sometimes a shorter wire is highlighted and sometimes a longer one, but they are overlapped.

L4 means a wire that passes by 4 grid units before it ends. Since CLBs are usually specified as 1 grid unit in arch files, that means an L4 wire would go past 4 CLBs without interruptions.

[LucaMartis00]

Sorry, but I still don't fully understand the meaning of ends and interrupt.

The "wire" passes through the switch blocks and isn't even connected to the CLBs it passes by.

[vaughnbetz]

If you're using a unidirectional architecture (the most common type) a wire can only be driven at one end, as the driver is not-tristatable (it is a mux with no tristate). It can drive the inputs of CLBs it passes by, but only the CLBs at one end could drive it in this case.

[LucaMartis00]

Thank you very much, it's much clearer now.

I also have some doubts about the Fs parameter of the switch block. Should I open a new issue or continue in this one?

[vaughnbetz]

I'd just write them here if they are questions / concerns.

[LucaMartis00]

I’ve included in the zip file the architecture I’m using. vpr_arch.zip

The value of Fs is set to 3, so if I understand correctly, I would expect each input wire to the switch block to be connected to three outputs. However, this doesn’t happen.
For example, in this case, it’s connected to only two outputs.
Why does this happen?

[vaughnbetz]

That is odd ... the straight through connections (e.g. left to right) seem to be missing, but I don't see any reason in the architecture file of why they would be missing. Does this happen for all wires or just some? For unidirectional routing architectures there is a step that tries to rearrange muxes to balance how many inputs they have, and the rr-graph generator has to ensure each wire is driven only at one end, so that is part of the rearrangement. I'm not sure if that could lead to this behaviour or not, but I am surprised by it.
Is this generated on the master branch, or the openFPGA branch? If the openFPGA branch, does the same thing happen on the master branch?