Setting IPIN Tdel

[amin1377]

When reading a custom RR graph, I noticed that the routing results differed between reading an RR graph from file and generating the RR graph internally. After investigating, it became apparent that the discrepancy is caused by the router lookahead assigning different base costs for IPINs in the two cases.

When reading an RR graph, the Tdel assigned to an IPIN’s rr_indexed_data is set to the delay of the most frequent switch connected to that IPIN.
However, when the RR graph is generated, the Tdel is taken from the switch specified for IPINs in the architecture file.

This doesn't cause a problem for VPR's default RR Graph generator, but when building a custom RR graph (which I am implementing in a separate PR), the switches connected to IPIN nodes may not match those specified in the architecture file, leading to inconsistent Tdel values and therefore inconsistent routing results.

This PR updates the behavior so that reading and generating RR graphs use a consistent approach for assigning Tdel to IPINs.

[soheilshahrouz]

How does the custom RR graph generator decide which switch to use for different IPINs?

[amin1377]

How does the custom RR graph generator decide which switch to use for different IPINs?

The switch to be used is determined by the switch pattern file provided to VTR, which specifies the connection patterns and the corresponding switch delays.

[soheilshahrouz]

There are a few things I can't understand:

Why don't we compute the average IPIN switch delay just like wire switches? I think this would give us a more accurate CPD estimate in placement. If a path goes through multiple IPINs, an average would a better representative than mode.

It seems that default RR graph generation doesn't allow the switch used for IPINs to have fanin-dependent delay specification. Why? How IPIN switches in custom RR graph generator differ from each other? Are they intrinsically different, or they only have different delays based on their fanin?

[amin1377]

Regarding the first point, we can modify the algorithm to use the average, similar to how it is done for CHANX/CHANY. I didn’t do that because I wanted to remain consistent with the approach used when reading the RR graph.

As for the second point, in a custom RR graph we do not take the switch delay from the architecture file. Instead, we obtain it from another file, where different delays can be specified for each connection to an IPIN.

[soheilshahrouz]

If different inputs to an IPIN have different delays, I think using the average is more accurate. I assume each edge with a distinct delay corresponds to a separate RR switch. Multiple of these switches may appear the same number of times, and using the mode causes one of them to be selected randomly.

[soheilshahrouz]

Can you describe how this extra file specifies the delay characteristics of IPIN swithches?

[amin1377]

@soheilshahrouz: As you suggested, I compute the Tdel as the average delay of the switches connected to the IPINs. I didn’t use the same approach as CHANs (where delays are quantized and the maximum delay in the most-populated bin is used), since the number of IPIN switches is significantly smaller than CHAN switches, and the additional quantization step doesn’t seem necessary.

[amin1377]

For RR graphs built using VPR’s default RR graph builder, we don’t expect any QoR changes (since the same switch type is used to connect channels to IPINs). Just to be sure, I ran the Titan_other benchmarks and compared the results with the master branch, and they were the same: Link