Add detailed timing report mode to VPR

[kmurray]

Proposed Behaviour

VPR should add a detailed mode to the existing --timing_report_detail option (in addition to the existing netlist and aggregated modes.

This mode should report:

1. For inter-block routing:
   • The routing resource types (e.g. L4, L16)
     • Their coordinates (x/y span)
     • Their incremental delay

For instance the current aggregated mode reports:

top^cur_state~3_FF_NODE.Q[0] (.latch) [clock-to-output]          0.000     0.166
| (intra 'clb' routing)                                          0.045     0.211
| (inter-block routing)                                          0.335     0.546
| (intra 'clb' routing)                                          0.095     0.641
n1168.in[4] (.names)                                             0.000     0.641

With detailed mode this would be extended to something like:

top^cur_state~3_FF_NODE.Q[0] (.latch) [clock-to-output]          0.000     0.166
| (intra 'clb' routing)                                          0.045     0.211
| (L4 CHANX (10,5 -> 14,5) aaaa)                                 0.150     0.361
| (L4 CHANY (14,5 -> 14,9) bbbb)                                 0.185     0.546
| (intra 'clb' routing)                                          0.095     0.641
n1168.in[4] (.names)                                             0.000     0.641

where aaaa and bbbb would be the RR node IDs associated with the relevant wires, and each wire has its delay contribution calculated.

(Potential further enhancement would include providing detailed reporting for the intra-block connections as well, but this is probably less important and may be superseded by future integrated intra/inter block routing).

Current Behaviour

Only aggregated and netlist modes are supported.

Possible Solution

The detailed information on the connection routing structure information is available from the relevant net's traceback/route tree. The delays to the end of each wire segment are available from rc/route tree once delay information has been annotated.

This will likely involve creating a new AnalysisDelayCalculator class which re-builds/calculates the rc/route trees during final analysis, so that it has full access to the internal delays to each RR node. (The current PostClusterDelayCalculator used by placement/routing/analysis only has access to the aggregate driver to sink net_delays).

Context

Providing these additional details makes it easier to debug and understand why certain delays along a timing path are large.

Currently it is very painstaking manual work to figure this information out.

For more history regarding why we have the aggregated mode see #212.

[kmurray]

@renrichard Since you are already looking at the rc/route tree code and cleaning it up, this may be a good next task

@vaughnbetz FYI

[mithro]

@litghost FYI

[kmurray]

Closed with #754