[Analysis] Printing Nets timing Information

[amin1377]

In this PR, a new function is added to generate a report showing the pin delay and slack for each net in the following format:

netname : Fanout : source_instance <slack_on source pin> : <load pin name1> <slack on load pin name1> <net delay for this net> : <load pin name2> <slack on load pin name2> <net delay for this net> : ...

Below is part of the output for the Titan ucsb_152_tap_fir_stratixiv_arch_timing circuit:

In_X[0] : 1 : In_X[0].inpad[0] 2.580953e-10 : x0[0].d[0] 2.580953e-10 2.093905e-09,
In_X[1] : 1 : In_X[1].inpad[0] 2.572866e-10 : x0[1].d[0] 2.572866e-10 2.094713e-09,
In_X[2] : 1 : In_X[2].inpad[0] 2.515523e-10 : x0[2].d[0] 2.515523e-10 2.100448e-09,
In_X[3] : 1 : In_X[3].inpad[0] 2.521192e-10 : x0[3].d[0] 2.521192e-10 2.099881e-09,
In_X[4] : 1 : In_X[4].inpad[0] 4.161274e-10 : x0[4].d[0] 4.161274e-10 1.935873e-09,
...
Out_Y[13] : 1 : Out_Y[13].q[0] -3.956270e-09 : out:Out_Y[13].outpad[0] -3.956270e-09 3.496270e-09,
Out_Y[14] : 1 : Out_Y[14].q[0] -4.240224e-09 : out:Out_Y[14].outpad[0] -4.240224e-09 3.780224e-09,
Out_Y[15] : 1 : Out_Y[15].q[0] -4.154614e-09 : out:Out_Y[15].outpad[0] -4.154614e-09 3.694614e-09,
...
Adder23Bit:Adder37|AddOut[0] : 3 : Adder23Bit:Adder37|AddOut[0].q[0] -1.045012e-09 : Register22Bit:Reg350|RegOut[0].d[0] 2.645368e-10 6.274631e-10 : Negator24Bit:Neg18|Add0~2.dataf[0] -5.802634e-10 3.513879e-10 : Negator23Bit:Neg19|Add0~2.dataf[0] -1.045012e-09 6.259270e-10,
...

[AlexandreSinger]

Hi @amin1377 , this is a very great PR! Some comments below.

[amin1377]

Thanks for the comments Alex, always appreciate it! I’ve addressed them; feel free to resolve if you don’t have any further suggestions.

[AlexandreSinger]

LGTM, thanks Amin.

I recommend also adding this to the documentation (currently it is only in the help menu), but I leave it up to you how much visibility you want to give this option.

[tpagarani]

@amin1377 can we also add WL/BBox information as well for each net. This could be helpful in building a net delay mode for physical resynthesis.

[amin1377]

LGTM, thanks Amin.

I recommend also adding this to the documentation (currently it is only in the help menu), but I leave it up to you how much visibility you want to give this option.

Thanks for pointing this out, Alex! I added the following to the command line usage help:

.. option:: --generate_net_timing_report {on | off}

    Generates a net timing report for each net in the design. For each net, the timing information written in the following format:

    .. code-block:: none

        netname : Fanout : 
        (bounding_box_xmin,bounding_box_ymin,bounding_box_layer_min),(bounding_box_xmax,bounding_box_ymax,bounding_box_layer_max) : 
        source_instance <slack_on source pin> : 
        <load pin name1> <slack on load pin name1> <net delay for this net> : 
        <load pin name2> <slack on load pin name2> <net delay for this net> : ...

[amin1377]

@amin1377 can we also add WL/BBox information as well for each net. This could be helpful in building a net delay mode for physical resynthesis.

I changed the format for each net to the following in order to include the bounding box information:

netname : Fanout : (bounding_box_xmin,bounding_box_ymin,bounding_box_layermin),(bounding_box_xmax,bounding_box_ymax,bounding_box_layermax) : source_instance <slack_on source pin> : <load pin name1> <slack on load pin name1> <net delay for this net> : <load pin name2> <slack on load pin name2> <net delay for this net> : ...

[vaughnbetz]

Any reason for this particular format? A .csv file would be easier to load into a spreadsheet an examine.

[amin1377]

My initial intention was to maintain compatibility with the format expected by Synopsys Synplify. However, since it can be post-processed later, I changed the report format to CSV.

[vaughnbetz]

Actually I would leave it compatible with Synplify (that is useful) but just comment that is the reason for this format.

[amin1377]

I initially thought the file would be directly consumed by Synplify, but apparently the synthesis team will be doing post-processing on it anyway, so it can be consumed by Synplify.

[amin1377]

LGTM, thanks Amin.
I recommend also adding this to the documentation (currently it is only in the help menu), but I leave it up to you how much visibility you want to give this option.

Thanks for pointing this out, Alex! I added the following to the command line usage help:

.. option:: --generate_net_timing_report {on | off}

    Generates a net timing report for each net in the design. For each net, the timing information written in the following format:

    .. code-block:: none

        netname : Fanout : 
        (bounding_box_xmin,bounding_box_ymin,bounding_box_layer_min),(bounding_box_xmax,bounding_box_ymax,bounding_box_layer_max) : 
        source_instance <slack_on source pin> : 
        <load pin name1> <slack on load pin name1> <net delay for this net> : 
        <load pin name2> <slack on load pin name2> <net delay for this net> : ...

@AlexandreSinger: Since I changed the format to CSV, I had to remove the header that included build information, etc. I could create a separate file to store metadata, but since we're not doing that for other reports, I think it's better to stay consistent and skip it here as well.

[vaughnbetz]

1. The documentation has a problem. Currently it has this:
   Fields in the report are:
   but then no detail afterward.

2. You should give some context of why this file can be useful; e.g. to process and pass to a re-synthesis tool like Synplify.

[amin1377]

1. The documentation has a problem. Currently it has this:
   Fields in the report are:
   but then no detail afterward.
2. You should give some context of why this file can be useful; e.g. to process and pass to a re-synthesis tool like Synplify.

The details in the line after that: https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/routing_path_timing/doc/src/vpr/command_line_usage.rst?plain=1#L1529-L1546

I added the following line to the documentation:

The report can later be used by other tools to enable further optimizations. For example, the Synopsys synthesis tool (Synplify) can use this information to re-synthesize the design and improve the Quality of Results (QoR).

[vaughnbetz]

There is some problem in the .rst that results in the fields not being built. See the screen shot of the built documentation below:

[amin1377]

@vaughnbetz: Thanks! It is fixed now.

[amin1377]

@vaughnbetz: This PR is ready to merge. Please let me know if you have any additional suggestions.