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 : 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]

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.

[kimiatkh]

I have added an example at the end of the Dedicated Clock Networks section. It contains snapshots of an RR graph related to the clock network along with some explanation. Could you please take a look and let me know if you have any comments?

[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.

[vaughnbetz]

Thanks @kimiatkh . 2 of the failing regtests are the vtr_strong ones, and they are QoR (run time) improvements with dedicated clock networks so they're fine to update the golden results for and proceed.

regression_tests/vtr_reg_strong/strong_routing_constraints...[Fail]
[Fail]
timing/k6_frac_N10_frac_chain_mem32K_htree0short_40nm.xml/verilog/and_latch.v/common_--target_utilization_0.01_--two_stage_clock_routing_-read_vpr_constraints_tasks/regression_tests/vtr_reg_strong/strong_routing_constraints/multi_clock_routing_constraints.xml_--clock_modeling_dedicated_network min_chan_width_route_time relative value 0.012082853855005755 outside of range [0.1,15.0], above absolute threshold 2.0 and not equal to golden value: 17.38
[Fail]
timing/k6_frac_N10_frac_chain_mem32K_htree0short_40nm.xml/verilog/and_latch.v/common_--target_utilization_0.01_--two_stage_clock_routing_-read_vpr_constraints_tasks/regression_tests/vtr_reg_strong/strong_routing_constraints/multi_clock_routing_constraints.xml_--clock_modeling_dedicated_network crit_path_route_time relative value 0.047058823529411764 outside of range [0.1,10.0], above absolute threshold 2.0 and not equal to golden value: 2.55

Same thing for vtr_reg_strong with -DVTR_ASSERT_LEVEL 3: it's a QoR (runtime) improvements with dedicated clock routing tests, so it just needs a golden result update.

2024-06-03T02:18:01.0902402Z �[32;1m02:18:01�[0m | regression_tests/vtr_reg_strong/strong_routing_constraints...[Fail]
2024-06-03T02:18:01.0903267Z �[32;1m02:18:01�[0m | [Fail]
2024-06-03T02:18:01.0907108Z �[32;1m02:18:01�[0m | timing/k6_frac_N10_frac_chain_mem32K_htree0_40nm.xml/verilog/multiclock_output_and_latch.v/common_--target_utilization_0.01_--two_stage_clock_routing_-read_vpr_constraints_tasks/regression_tests/vtr_reg_strong/strong_routing_constraints/multi_clock_routing_constraints.xml_--clock_modeling_dedicated_network min_chan_width_route_time relative value 0.019155941334929663 outside of range [0.1,15.0], above absolute threshold 2.0 and not equal to golden value: 33.41
2024-06-03T02:18:01.0910292Z �[32;1m02:18:01�[0m | [Fail]
2024-06-03T02:18:01.0913599Z �[32;1m02:18:01�[0m | timing/k6_frac_N10_frac_chain_mem32K_htree0_40nm.xml/verilog/multiclock_output_and_latch.v/common_--target_utilization_0.01_--two_stage_clock_routing_-read_vpr_constraints_tasks/regression_tests/vtr_reg_strong/strong_routing_constraints/multi_clock_routing_constraints.xml_--clock_modeling_dedicated_network crit_path_route_time relative value 0.07113821138211382 outside of range [0.1,10.0], above absolute threshold 2.0 and not equal to golden value: 4.92

[kimiatkh]

@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!).

For this error message, I first tried to fix the expected node count when having a dedicated network. However, I ended up falling down a rabbit hole, and making the change seemed to require a deeper understanding of how the rr_node indices are being assigned, which would take more time. So, to get this branch merged faster, I temporarily only perform the node count check when we don’t have the dedicated clock network; otherwise, we skip it. I commented on this and mentioned that as future work, this should get fixed.

[vaughnbetz]

Thanks Kimia. I think not matching the rr_node count is fine ... it's just a double check for defensive coding, and if the double check becomes hard to compute it isn't worth it.

[vaughnbetz]

The code and documentation look great; I'll merge as soon as CI is green. Thanks for landing this!

[vaughnbetz]

CI is failing because I think I merged some code that uses an out of date enum -- should be an enum class now.

e_block_pack_status::BLK_FAILED_FEASIBLE

[vaughnbetz]

I fixed the enum in #2576 . As soon as that successfully builds I'll pull the changes in here.

[vaughnbetz]

Alex beat to fixing the enum; merged his changes in and pulled them into this PR.

[AlexandreSinger]

The branch conflict you are seeing regarding libcatch2 is caused by the submodule being updated in Master, but this PR is using the old version of libcatch2. This shouldn't cause an issue if this were merged, but GitHub is covering itself by saying that there is a conflict. Usually GitHub can automatically merge / rebase when issues like this happen; however, it seems like it struggles with submodules.

I think all you need to do is merge / rebase onto origin/master the push again. CI will have to pass yet again.

[AlexandreSinger]

I have merged the most recent version of master in and pushed the code. Git was having a bad time understanding how we upgraded the submodule, but I have verified that this branch now uses the same version of libcatch2 as master. CI is running now.

[vaughnbetz]

Thanks @AlexandreSinger ! I am not going to merge anything until this one goes in (hopefully CI finishes soon!).