Add flat version of sync_netlists_to_routing

[duck2]

Re-opened #2691 to see if that fixes the CI.

[vaughnbetz]

Spree.v failed again in vtr_reg_strong:

regression_tests/vtr_reg_strong/strong_flat_router...[Fail]
[Fail]
k6_frac_N10_frac_chain_mem32K_40nm.xml/spree.v/common vpr_status Task value 'exited with return code 134' does not match golden 'success'
[Fail]
k6_frac_N10_frac_chain_mem32K_40nm.xml/spree.v/common routed_wirelength relative value -9.344921035417251e-05 outside of range [0.6,1.5], above absolute threshold 5.0 and not equal to golden value: 10701.0
[Fail]
k6_frac_N10_frac_chain_mem32K_40nm.xml/spree.v/common logic_block_area_total relative value -1.0868915445272294e-07 outside of range [0.8,1.3] and not equal to golden value: 9200550.0
[Fail]
k6_frac_N10_frac_chain_mem32K_40nm.xml/spree.v/common logic_block_area_used relative value -1.877042456823331e-07 outside of range [0.8,1.3] and not equal to golden value: 5327530.0
[Fail]
k6_frac_N10_frac_chain_mem32K_40nm.xml/spree.v/common min_chan_width_routing_area_total relative value -6.770893283950952e-07 outside of range [0.7,1.3] and not equal to golden value: 1476910.0
[Fail]
k6_frac_N10_frac_chain_mem32K_40nm.xml/spree.v/common min_chan_width_routing_area_per_tile relative value -0.0001327099504593755 outside of range [0.7,1.3] and not equal to golden value: 7535.23

There's also a spurious unit test failure (odd_even routing in the NoC tests): @soheilshahrouz can you disable that one?

[fkosar-ql]

This is very annoying:

1. Sometimes the valgrind tests cannot find odin_II (?)
2. The NO_GRAPHICS test acts randomly: it either passes, fails or gets stuck in a loop (??)
3. When I set up ssh access into the runner via tmate I can't reproduce the failure.
   3.1. Sometimes I can, but then if I run the test again it passes.
   3.1.1. It seems to always pass after the first time. I tried running it in a loop 50 times and there's no failure.
   3.2. There's a very interesting case where the test fails with return code 2 but when I print the test log I see return code 0
   3.3. I tried rebuilding with ASAN inside the runner and there seems to be no issue.

[vaughnbetz]

@AlexandreSinger : maybe 4 cores is running out of memory on the GitHub runners? Perhaps that is why we only used 2 until recently?

[AlexandreSinger]

@vaughnbetz I would be very surprised. Since merging the 4-core change the CI was run 7 times on the master branch and did not see any issue (asside from the known unit test randomly failing). However, I do agree that the symptoms Fahri points out would point to this. I agree to trying to set it back to 2-cores and see if that fixes it. But again, I would be very suprised if this is the problem.

[AlexandreSinger]

Looking at Fahris most recent commit, he did turn it back to 2 cores successfully; but the Tests still seem to be failing.

[fkosar-ql]

🤦🤦🤦 I accidentally included regression_tests/vtr_reg_basic/hdl_include_yosys twice in the task list. It probably goes into a race. Let me see if removing it fixes the tests

[fkosar-ql]

That seems to fix it... merging

[AlexandreSinger]

@fkosar-ql The CI is now failing on Master with the same failures as what was seen in this PR before:
https://github.com/verilog-to-routing/vtr-verilog-to-routing/actions/runs/11301269116

Something is still wrong with this code. @vaughnbetz Should I revert this PR so we can merge it again once we figure out what is causing these issues?

edit:

see below. I do not think this PR is the problem. It looks like the three PRs which were most recently merged in were not rebased onto each other and are causing some bugs to come out. Sara's changes changed the golden result, so they need to be regenerated. This basic one has been there before and must have been exposed. Sorry for the confusion.

[AlexandreSinger]

Actually, reading into these errors its different. The strong tests are just golden test not matching, and the basic test failures are the failures noted in issue #2754

Something about how this change interacted with other code being merged in may have brought it out.

[fkosar-ql]

Yeah, the failures don't look the same. This PR doesn't touch routing or STA so it would be surprising if it was causing the issue.