Get VTR working on macOS again #2854
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The tests run in a different order on macOS than Linux, which happens to result in this segfault. The problem is that `test_compressed_grid` leaves some stuff behind in `mutable_device().logical_block_types`, which have `pb_type` set to `nullptr`. This then breaks `test_connection_router`'s call to `XmlReadArch`, since it assumes that all of the logical block types are ones that it created, all of which either have `pb_type` set or are empty. Making `test_compressed_grid` clear `logical_block_types` when it's done fixes that.
The problem was again that tests weren't cleaning up after themselves properly, and were then breaking subsequent tests: this time, they were correctly calling `NocStorage::clear_noc`, but that was failing to clear `router_id_conversion_table`. Since `unordered_map::emplace` is used to add entries to that table, writing to an entry that's already been filled doesn't do anything, and so subsequent reads wil retrieve the data from previous tests: the retrieved IDs are then used as indices, causing out-of-bounds array accesses and an eventual crash.
Yosys expects its plugins to be .so files, even on macOS. The Make backend already did this correctly, but CMake was still using the default of `.dylib` for macOS. This gets vtr_reg_basic working on macOS.
github-actions
bot
added
VPR
|
(off topic: I think it would be good if you contributed the nix package to https://github.com/NixOS/nixpkgs ... just this morning I was looking if |
|
Thanks! The changes look OK; launching CI. |
|
CI passed; I'm guessing the apex2 failure you saw is probably due to some different round off making us create a different clustering which doesn't match the .place file (indicating a flaw in the test really). The routability failure was probably a random one due to imperfections in the algorithms and different round off leading to a different decision. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
VTR's support for macOS has bitrotted over time; this gets it working again.
Description
The only problems that were actually related to macOS were the missing includes and Parmys using
.dylibinstead of.so; the rest were just a result of the tests being run in a different order and can be reproduced on Linux withtest_vpr --order rand.vtr_reg_strongstill has two failing tests:fix_clusters_test_arch/apex2andk6_frac_N10_frac_chain_mem32K_40nm/or1200.or1200fails on Linux too for me, so I didn't bother investigating further (it's saying that the circuit is unroutable).After some cursory investigation, it seems like
apex2might be failing because two blocks which the.placefile specifies should be in different locations are getting packed into the same cluster before the.placefile is read. I don't know enough about how VPR works to figure out what's preventing that from happening on Linux as well (or anything about it at all really, and I could have completely misunderstood the issue).Related Issue
Motivation and Context
How Has This Been Tested?
I ran the
ctestunit tests,vtr_reg_basic, andvtr_reg_strong(which had the failures mentioned above. On Linux,k6_frac_N10_40nm/ex1010.pre-vpralso failed with an error saying it was unroutable, but only when using GCC; it passed when using Clang).ctestandvtr_reg_basicwere run via. this Nix package, andvtr_reg_strongwas run in anix developshell for the same package.Types of changes
Checklist: