[Report Timing] intersite_delay_terms

[coherent17]

Hi RapidWright Experts,

I'm running the ReportTimingExample with the ultrascale device, and I'd roughly go through the lightweight timing-model that RapidWright using and get really great coorelation between Vivado. However, since the method is similar to curve fitting, some parameters need to pre-config for different device. I'm wondering if these intersite_delay_terms file can also be on-demand downloading instead of open Vivado and dump out again?

Thanks,
Coherent

[clavin-xlnx]

Hi Coherent,

The lightweight timing model in RapidWright currently only supports UltraScale+. In theory, it could be extended to support the Versal family of devices, but a new set of files (intrasite_delay_terms.txt and intersite_delay_terms.txt) would need to be created in a timing/versal directory. We have not made these files to be included in the download-on-demand set because they are text-based and can be edited for particular scenarios.

There has not been an effort yet to create an approximate timing model for Versal. Not sure if this answers your question, but if you can share more about your ultimate goals/desired outcomes, perhaps we can explore some options.

[coherent17]

Hi Coherent,

The lightweight timing model in RapidWright currently only supports UltraScale+. In theory, it could be extended to support the Versal family of devices, but a new set of files (intrasite_delay_terms.txt and intersite_delay_terms.txt) would need to be created in a timing/versal directory. We have not made these files to be included in the download-on-demand set because they are text-based and can be edited for particular scenarios.

There has not been an effort yet to create an approximate timing model for Versal. Not sure if this answers your question, but if you can share more about your ultimate goals/desired outcomes, perhaps we can explore some options.

Hi Chris,

I want to get those timing critical nets. To be more specific, those nets with negative slack on device (xcvu440, xcvu19p, xcvp1902).

Given these information, I can make further analysis on the Vivado PnR quality and determine how to further fix the design netlist or other strategy!

Thanks,
Coherent

[clavin-xlnx]

Hi Coherent,

Unfortunately, augmenting RapidWright to precisely calculate the critical paths of a design is quite a bit of work and it would take a long time without additional resources.

One idea is that we could build a parser for Vivado's timing reports. Presumably, once a design has been placed and routed, the timing report could be written to a file by Vivado. Then, in RapidWright we could load the DCP and parse that report into timing path objects that would allow us to traverse and analyze the critical paths of the design. Does this idea seem feasible to you?

[coherent17]

Hi Chris,

Yes, I think the idea you mentioned is worth to try. If I understand correctly, the dcp file will not contain the timing information. Given a placed and routed/partial routed design into Vivado through dcp, does Vivado need to rebuild the timer to get the timing information?

I'd noticed that there's a file named *.sta when I unzip the dcp file. Does RapidWright able to process that *.sta file?

[clavin-xlnx]

I would recommend parsing the timing report file to extract the critical paths for analysis in RapidWright. That would be the fastest path to what you would like to do.

There is some timing information stored in some DCPs, but we currently don't process it. Perhaps in the future that might be possible.