-
Notifications
You must be signed in to change notification settings - Fork 895
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
celledges: support shift ops #3972
Merged
nakengelhardt
merged 8 commits into
YosysHQ:master
from
nakengelhardt:celledges_shift_ops
Mar 8, 2024
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
d0e559a
celledges: support shift ops
nakengelhardt 2d6d6a8
fix handling a_width != y_width
nakengelhardt 6c562c7
fix handling right shifts
nakengelhardt bdd74e6
celledges: Account for shift down of x-bits wrt B port
povik 4cce491
celledges: s/x_jump/zpad_jump/
povik a96c257
celledges: Add messy rules that do pass the tests
povik 134eb15
celledges: Clean up shift rules
povik cb86efa
celledges: Add test of shift cells edge data
povik File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
test_cell -s 1705659041 -n 100 -edges $shift $shiftx $shl $shr $sshl $sshr | ||
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder, should we leave the seed unspecified in order to get better test coverage? It still prints the chosen seed in the log so we can reproduce if necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the potential for confusion when a CI job starts failing for reasons unrelated to the underlying code change is much worse than the benefit of the extra coverage we would get. FWIW I let the
test_cell
command complete with a much largerN
when I was working on this.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the alternative to failing on a later CI run from a previous breaking change is to never fail, which means we don't realize that it's broken at all. I would quibble with calling that a "much better" outcome!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess where I see the value is that we can discount "this is broken due to an unlucky seed" when reasoning about CI failures, which I weight against the chance that this will help us find a bug which would otherwise stay hidden, which I think is low. (Anyone touching the shift edges code should be asked to do a long
test_cell
run anyway.)If someone down the line touches e.g. the SAT code and this prompts a failure in this test, we will know it's the SAT changes for sure, and that's valuable. At least that's how I think about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see your point but I don't think it would be that difficult to trace which part is the problem. If the test fails I think the first debugging step would be to run the same test with the code before the change, at which point it would become obvious that the failure existed earlier. I guess that does require knowing that this test uses random generation and that you need to use the same seed, which you might miss if you don't read the log backscroll far enough. (Maybe for convenience
test_cell
should print the seed again as the last line if a test fails?)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer CI runs triggered by PRs to be deterministic, but I don't see an issue with using randomized seeds for the daily CI runs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's worth adding lines in the CI configurations for this one test, let's just keep it deterministic then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I strongly disagree with any argument that describes nondeterministic CI a non-worse outcome. If your CI is nondeterministic, it reduces faith in that the CI works at all. Eventually you create a culture of simply restarting the CI run if something fails because it's known to be flaky.
It's OK to have a separate job that is clearly and expressly marked as nondeterministic (this is basically a simple fuzzer) but merging must not be gated on it unless there's strong explicit consensus that this is a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But by that argument, it would be "better" if we were never running any synth pass in CI at all, since abc is currently nondeterministically breaking CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I think not running nondeterministic tests at all is better than nondeterministically breaking CI. If we (YosysHQ) took testing seriously we would have made ABC deterministic, which I have offered workable solutions for.
I will note that I've also introduced the
-noabc
flow, which could be an interim alternative to using ABC while it's still nondeterministic.