Floorplanning during place moves

[sfkhalid]

Description

Adding floorplanning constraints checks to the placement move generators. When a move is being proposed, the blocks affected by the move are checked to see if they are moved out of their respective floorplan regions. If a move would cause a block to be moved out of its legal floorplan region, the move is aborted.

Related Issue

Changes related to issue #932

[vaughnbetz]

1. Comment the new cluster_atoms_lookup class and its data/functions.
2. Need to add a testing summary. Minimum testing to put this back: ensure nothing that used to work is broken.

• QoR before and after this change (attach a spreadsheet and summary on the VTR benchmarks), with no floorplan constraints. Everything should be identical, except CPU time, which should be extremely close.
• Run the sanitizers on the new code (1) with no floorplan constraints, (2) when generating a floorplan file (3) when running with an (easy/big) floorplan file to confirm memory is clean.

3. Additional testing, that can be done after this is merged if it holds things up, but can be done now if it doesn't hold things up:

• Run VTR benchmarks with a big floorplan region on each atom (shouldn't change anything significantly)

---

_4. After that, QoR testing can proceed post-merge

• Run VTR benchmarks with each atom constrained to a specific x,y,sub_tile. Should work, but more chance something goes wrong and needs algorithm updates.
• Moderate size floorplan regions_

[vaughnbetz]

@sfkhalid : can you add the testing summary above so we can get this merged? Also, close any comments that you've addressed in the code review.

[sfkhalid]

@sfkhalid : can you add the testing summary above so we can get this merged? Also, close any comments that you've addressed in the code review.

I have a testing summary prepared but I have noticed an increase in the place time for LU32 and mcml, (5% and 7% respectively) so I was trying to investigate that first. The results are in the attached file:
place_moves_qor_comparison_final.xlsx

[vaughnbetz]

It does seem like there is an increase in place time.

Worth running on a controlled machine (e.g. wintermute) to confirm the results are consistent.
After that I suggest:

1. Commenting out some code to see where the problem is. It's probably in the move generators, so I'd comment out the code there and see if it goes away.
2. Profile to see if you can determine which routines have an impact.
3. Then optimize as much as you can ...

[sfkhalid]

Yes, I'm currently re-running on wintermute to see if the results are consistent. So far mcml had a shorter place time than the last run. I am waiting for the run to finish to see if this is the same across the circuits. I ran on wintermute the first time as well, for the master branch and this branch. If there is a difference in results, where could that be coming from?

Yes, I think if there is an issue it is with the move generators because from the log files the initial placement time didn't change but the overall place time did for mcml.v, (in the run where the place time increased).

[vaughnbetz]

machine load can impact time. Marius killed a bunch of stale processes, so the load may be lower. It's best to run the baseline and the new run under as similar conditions as you can (either run them at the same time, or run one after the other in rapid sucession, and watch the machine load some).

[sfkhalid]

As suggested, I ran the QoR tests again on both branches, master and place_moves, in succession and monitored the machine load. It looked very similar through both runs, so I think I have a better comparison now.

The results show that the differences in place time and total runtime are very small (less than 1% difference) across the vtr benchmarks. Other values stayed the same.
place_moves_QoR_comparison.xlsx

[sfkhalid]

Testing with sanitizers:

I ran vpr on some test constraint cases, and some cases with no constraints on this branch and the master branch.
There were some memory leaks that occurred, however, the same memory leaks occurred on both the master and place_moves branch, and they did not occur during the placement stage. Given this, I don't think the memory leaks are caused by the code on this pull request.

[sfkhalid]

@vaughnbetz Given the new QoR comparison and the sanitizer results, do you think this pull request is okay to merge once the CI finishes?

[vaughnbetz]

Looks good. I agree the sanitizer errors aren't related to your code. I believe we suppress those ones in CI (we can't make them go away as they're in libraries). QoR looks OK.
I'll merge once CI goes fully green.
@sfkhalid: it's not in this PR, but did you also make the change to only check the the constraint on one block of a macro (could be head or just the block passed in) when you try to move a place macro? Probably cleanest to just have the floorplan_legal check only check the one block passed in, and comment why that works for place_macros (and make sure you have constriant propagation fully done!).

[sfkhalid]

@vaughnbetz Can we re-start the tests on this PR? The CI had gone completely green before but I've had to restart it a couple of times because by the time it finishes it needs to be updated with the new master branch. Some of the clang tests are failing now, I think they will pass if we run it again though.

[sfkhalid]

Actually, looking at the log files on the clang tests, it seems there is an error coming up. I am not sure where it is coming from, this PR passed those tests twice in the past few days, so it may be from something that was updated recently in the master branch.

[vaughnbetz]

Strange errors: looks like clang can't find basic things like size_t? I set kokoro:force_rerun to try restarting CI, but looks like that only re-runs the big cpu tests, not clang tests. I'm confident this is unrelated so I'm merging anyway; hopefully this was a transient clang install issue.