Flat router test

[amin1377]

In this PR, the following tests have been added:

• vtr_reg_nightly_test_2: ~ 4.2 hours

  • vpr_verify_router_lookahead_flat_router: This write the router lookahead, while flat routing is enabled, in a file. Then, VPR is run this time reading from that file and writing the lookahead in another file. The output file are compared to make sure that they are the same. For some reason, I couldn't figure out why this test is failing. It is removed from the task list and remained as a future work.
  • vpr_verify_rr_graph_flat_router: This test checks the reading and writing of the RR graph on three different architectures.
  • titan_other_flat_router: This test includes all circuits of the titan_other benchmarks suite except for the three largest circuits. It's a normal run with flat-routing enabled.

• vtr_reg_nightly_test_3: ~2.3 hours

  • vtr_reg_qor_chain_depop_flat_router: This test contains 5 of the largest circuits from the VTR benchmark suite running on the depop VTR flagship architecture. It is used to verify the code handling choke points, with max_router_iterations set to 300 for both finding minimum channel width and relaxed channel width.

• vtr_reg_strong: Overall, took about 12 minutes

  • strong_flat_router: This test runs a small circuit (spree.v) on the VTR flagship architecture.

[vaughnbetz]

Should also add a 7-series architecture on some circuit(s).

[vaughnbetz]

A too long python line to fix:
************* Module run_vtr_flow
vtr_flow/scripts/run_vtr_flow.py:429:0: C0301: Line too long (114/100) (line-too-long)

styr.blif failed critical path (and related timing) tests for Odin II strong on the push, but not the pull (odd!). Looks like it's OK to change, and if it doesn't recur it's OK to ignore anyway.

[duck2]

sry, thought that button would show the diff before creating a commit

[amin1377]

@vaughnbetz : Regarding the edge_remapped_ vector that we talked about before, I just checked the code, and it is already stored in a separate vector, and it is not in any hot data structure.

[vaughnbetz]

Ah, that's good. We should move it to the RRGraphBuilder class so its lifetime is more limited though; best to minimize the long-lived state.

[amin1377]

@vaughnbetz: CIs are green, except for the documentation build failure. I'm not sure why it's failing.

[vaughnbetz]

Some conflicts need to be resolved.
Also, I think you said the remap vector is now deleted or cleared once you don't need it anymore (after rr_graph building). Can you confirm that's the case?

[vaughnbetz]

Conflicts, nag, nag

[amin1377]

Conflicts, nag, nag

Done...I am now waiting for the CI tests and also running the QoR tests(VTR and Titan) just to be sure.

[vaughnbetz]

Some QoR failures, although the one I looked in vtr_nightly3 seems to be OK (all due to a channel width increase of 31% on a small bgm design):
k6_frac_N10_frac_chain_depop50_mem32K_40nm.xml/bgm.v/common crit_path_routing_area_total relative value 1.3105520880172603 outside of range [0.7,1.3] and not equal to golden value: 24240700.0

[amin1377]

@vaughnbetz : I guess there is something wrong with vtr_reg_nightly_test_2. I also looked at other CI test(1, 2, 3) and non of them can run this test in the allocated run-time (they don't fail, but it seems that the test gets aborted)

[amin1377]

@vaughnbetz I guess this PR is finally ready to land!