Global Nets Routing constraints

[kimiatkh]

This branch introduces support for designating any net as global by utilizing a VPR constraints XML file, enabling users to define the routing method for each global net.

Here is an example of routing constraints defined within vpr_constraints:

<vpr_constraints>
    <global_route_constraints>
        <set_global_signal name="clock*" network_name="clock_network" route_model="dedicated_network"/>
    </global_route_constraints>
</vpr_constraints>

In this example:

The name attribute supports wildcard patterns for flexible net matching.
The route_model attribute can be set to "ideal," "route," or "dedicated_network." Refer to the documentation here for details.
When route_model is set to "dedicated_network," the user must also specify the name of the dedicated network through the network_name attribute.

Additionally, this branch introduces support for identifying clock-related resources in the rr graph. Clock segments are now identified using the optional attribute res_type set to "gclk." To pinpoint virtual sink nodes specific to clock networks, a new optional attribute clk_res_type is introduced within the rr node tags, currently supporting "virtual_sink." The variable name is introduced to accommodate multiple clock networks, referencing the clock network's name when clk_res_type is set to "virtual_sink."

Motivation and Context:

With modern FPGAs incorporating dedicated clock networks, often spanning multiple clock regions, VPR's existing support for modeling and routing through such networks is limited. This pull request addresses this limitation by enhancing VPR's understanding of clock network resources and adding support to specify the routing methods for global nets through a constraints file.

Types of changes
[ ] Bug fix (change which fixes an issue)
[x]New feature (change which adds functionality)
[ ]Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
My change requires a change to the documentation
[x] I have updated the documentation accordingly
[x] I have added tests to cover my changes
[ ] All new and existing tests passed

[vaughnbetz]

@kimiatkh : a gentle nag to update this so we can try to land it.

[vaughnbetz]

@duck2 : Kimia has had to add some special code (a very small amount) to deal with the virtual sinks for clock routing on dedicate clock networks. For such sinks, she passes -1 as the target_net_pin_index, and does not mark it in the _is_isink_reached array (since there is no sink index to mark as the pre-routed part of the net to get to the dedicated clock network drive point does not correspond to any one connection).

Does anything else have to happen to make this work with the parallel router and/or net decomposition? E.g. should clock networks always be routed in the root partition and/or never be decomposed so we don't have to worry about them? Or should everything work without change?

@kimiatkh : I think you'll have to test with parallel routing on too, and make regtests that combine parallel routing on with dedicated_clock_network routing on.

[vaughnbetz]

kimia did a quick test on a small circuit with parallel code (a January version) and it worked with dedicated clock routing. It may not be a strong enough test though, as perhaps there are no nets that can be routed in parallel in such a small device.

[vaughnbetz]

@kimiatkh : please remove the spurious error messages that the rrgraph node count doesn't match the expected (as the comment says this will happen every time with dedicate clock networks!).

[vaughnbetz]

Looks good!

[vaughnbetz]

I'd add at the end "(i.e. regular routing)."

[vaughnbetz]

"based on the current placement" (add a "the")

[vaughnbetz]

netwrok --> typo

[vaughnbetz]

It would be good to add an example of clock network routing here. You'd give little snippets of each file that together would make sense.

[duck2]

I think clock nets don't get decomposed anyway, so this should be OK if it works with --router_algorithm parallel.

[vaughnbetz]

@kimiatkh : it would be good to land this. I have just a few comments to address, plus there is a conflict to resolve. CI passed, so once those are handled I think this can be merged.