[VersalClockRouting] VDISTR tree storage map for Versal

[clavin-xlnx]

Versal has an improved feature over UltraScale/UltraScale+ clock networks for vertical clock distribution (Vertical H tree -- see slide 6 of https://www.amd.com/content/dam/amd/en/documents/products/adaptive-socs-and-fpgas/vivado/reducing-clock-skew-in-versal-devices.pdf).

In order to take advantage of this, there are certain vertical distribution path patterns that should be followed to minimize skew and balance multiple occupied clock regions in a clock domain.

This PR updates the Versal Clock Router employed by RWRoute to load a new RapidWright data file that contains a map with vertical distribution patterns pre-computed offline for all Versal devices. There are entries for every contiguous span of occupied logic (Y1->Y1, Y1->Y2, Y1->Y3, ... Y1->Y10), for each valid clock root option for the given contiguous span, with a preferred clock root being used all of the time.

Note: The Calibrated Deskew feature described in the document above is not something we intend to support at this time. If users wish to take advantage of this feature in their projects, they will need to import their designs back into Vivado.

Ultimately, this modification led to a reduction of 100's of picoseconds of skew for a multi-SLR device.

[eddieh-xlnx]

Note: The Calibrated Deskew feature described in the document above is not something we intend to support at this time. If users wish to take advantage of this feature in their projects, they will need to import their designs back into Vivado.

From your slides it seems there is "basic deskew" (sufficient for intra-SLR) and "calibrated deskew" (for multiple SLR devices). Are you saying we support the former?

[clavin-xlnx]

Note: The Calibrated Deskew feature described in the document above is not something we intend to support at this time. If users wish to take advantage of this feature in their projects, they will need to import their designs back into Vivado.

From your slides it seems there is "basic deskew" (sufficient for intra-SLR) and "calibrated deskew" (for multiple SLR devices). Are you saying we support the former?

Yes, just basic deskew using the H-trees for horizontal distribution.

[eddieh-xlnx]

Is it possible to get a quick test to ensure that the balanced H-tree does indeed get taken, as opposed to the suboptimal routing before?

[eddieh-xlnx]

Is the plan (in a future PR, prior to final 2025.2.0 release) to support more devices than just the V80 that the data file in this PR supports? If so, should this be turned into a Exception (after which any code to do suboptimal vertical routing can also be removed?)