[Clocks][RouterLookahead] Improved lookahead for clock networks

[AlexandreSinger]

These changed improve how the router lookahead is computed when clock networks exist in the FPGA fabric.

When clock networks exist, special segments are created which have the resource type GCLK. It is assumed that these clock network resources are dedicated, fast resources and should only be used by clocks. The problem is that the router lookahead was doing dijkstra floods which were using these segments. This means that the general fabric was assuming that it could use these resources, and the clock fabric was assuming that it could hop off to the general fabric.

To fix this, I added a check during the Dijkstra flood (which is used to find the lookahead costs) which ignores edges that go from/to a GENERAL routing segment to/from a GCLK segment. This bakes the following assumption into the lookahead: Signals that start on general routing will take general routing to the target, and signals that start on clock routing will take clock routing to the target.

I also found an issue with orthogonal segments with clock networks. Clock ribs and spines are only CHANX and CHANY and do not have orthogonal components. This causes an issue when the lookahead is created and these elements have zero delay, since VPR populates zero delay entries with the delays on the orthogonal segments. Fixed this by directly checking if the values are uninitialized and preventing using orthogonal data from different resources.

I also changed the segment frequency of clock segments to zero by default, since this is used in VPR to imply that the segments are not part of the general routing fabric.

I tested this on an architecture with zero delays on the clock network and verified that the lookahead did not have any delay contributions from the clock network.

[AlexandreSinger]

@vaughnbetz What do you think about this change? The change makes it so the router lookahead assumes that you are staying on your resource type.

I was originally going to make a separate lookahead for clocks and remove the clock segments from the lookahead, but I realized that I was going to populate it using the same exact code anyways. So it is much cleaner to keep these together.

For the two stage router, this will have the best affect:

• In the first stage, the routing starts in the general fabric and is using an estimate towards the driver of the clock network which assumes that it will only use general routing resources.
• In the second stage, the routing starts on a GCLK segment and is using an estimate towards the clock pins of blocks which assumes that it will only use the dedicated clock resources.

For the single stage router, this should still work the same as before; but its not perfect. It will assume that it is using general routing the entire way to the target. This is technically worse for clock signals than before since the lookahead originally included the clock resources in the path searches; however, this was at the expense of all general routing resources, so this change is much better for those resources.

The reason I am looking into this is that I want to give the best chance for RCV by giving it as good of a lookahead as I can.