vtr-verilog-to-routing
vtr-verilog-to-routing copied to clipboard
verilog-to-routing
Global Nets Routing constraints
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
There's a bug with Clang compilation (need to pass a c-string instead of C++):
3%] Building CXX object vpr/CMakeFiles/libvpr.dir/src/base/user_route_constraints.cpp.o
clang: warning: -lz: 'linker' input unused [-Wunused-command-line-argument]
/home/runner/work/vtr-verilog-to-routing/vtr-verilog-to-routing/vpr/src/base/user_route_constraints.cpp:49:19: error: cannot pass object of non-trivial type 'std::string' (aka 'basic_string
Also, don't forget to update the documentation with the new constriants.
@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.
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.
@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!).
I think clock nets don't get decomposed anyway, so this should be OK if it works with --router_algorithm parallel.
@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.
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 : 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.
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.
The code and documentation look great; I'll merge as soon as CI is green. Thanks for landing this!
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
I fixed the enum in https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/2576 . As soon as that successfully builds I'll pull the changes in here.
Alex beat to fixing the enum; merged his changes in and pulled them into this PR.
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.
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.
Thanks @AlexandreSinger ! I am not going to merge anything until this one goes in (hopefully CI finishes soon!).