vtr-verilog-to-routing
vtr-verilog-to-routing copied to clipboard
Fix fixed clusters issue
Description
When a large number of clustered blocks are fixed, placement takes a very long time. This is because for picking a random block, we exhaust all blocks until we find a movable block. If most clustered blocks are fixed, it would take a long time to exhaust fixed blocks by random selection. This PR stores movable blocks in a vtr::vector so that a movable random block can be selected more quickly. It also makes reading the placement file more robust.
Related Issue
How Has This Been Tested?
Types of changes
- [x] Bug fix (change which fixes an issue)
- [ ] 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
- [ ] I have updated the documentation accordingly
- [ ] I have added tests to cover my changes
- [x] All new and existing tests passed
Link to QoR results for Titan benchmarks. They are the same as master.
- @soheilshahrouz tells me there is a bug to fix.
- Please add a comparison to master (normalize results to master)
- Check runtime / QoR on the original issue and summarize the result.
@vaughnbetz I applied your comments. Ready for review.
Please summarize the relative runtime, cpd, wirelength etc. of the master vs. this fix. Please run the original issue and post the new runtime. I also have a few suggestions on the code; happy to have a zoom meeting if you'd like to discuss.
branch | Place time | Place WL | Place CPD |
---|---|---|---|
this PR | 0.992 | 1.00 | 1.00 |
master | 1.000 | 1.00 | 1.00 |
Issue runtime: was a few days, now is less than 5 min so it is fixed.
@soheilshahrouz : need to resolve a conflict.
Looks like many seg faults in CI.
@vaughnbetz CI failures are gone now. The issue was that move generators needed to be crated after initial placement, where movable block are determined, but merging master into this branch reversed the order.