Skip to content
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

[MultiCycleDivider] Bug Fixes for Large Operands and Ready Indication Polarity #129

Merged
merged 1 commit into from
Nov 15, 2024

Conversation

kimmeljo
Copy link
Contributor

@kimmeljo kimmeljo commented Nov 6, 2024

Description & Motivation

The MultiCycleDivider has the following bugs:
(1) Polarity of the readyIn output is flipped relative to what it should be.
(2) Unsigned cases of division involving very large operands (MSB=1) do not produce correct results and can even deadlock the unit.

This PR fixes these and adds tests for the exceptional cases moving forward.

Related Issue(s)

N/A

Testing

Added a new sequence for "evil" cases of division stressing large operands in both signed and unsigned. Fixed a bug in the testbench preventing testing of readyIn signal.

Backwards-compatibility

Is this a breaking change that will not be backwards-compatible? If yes, how so?

This change is backward compatible as the interface to the divider has not changed at all. Only the outputs for a given set of inputs have changed in certain cases.

Documentation

Does the change require any updates to documentation? If so, where? Are they included?

Documentation updated to address the case of signed division overflow which was also added as a test case and needs explicitly clarification on unit behavior.

@@ -249,13 +252,7 @@ class MultiCycleDivider extends Module {
~bBuf.getRange(0, dataWidth - 2).or() &
(signOut ^ signNum),
then: [
// special logic for when a is also most negative #
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you are in an If block, would you want to stay with If/Else and not insert a mux?
If you have the unit tests to exercise all paths through this logic, this is a quick refactor.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fine with me. Since it's quick and non-functional here, I can add it to this PR.

@@ -297,11 +300,11 @@ class MultiCycleDivider extends Module {
// conditionally convert negative inputs to positive
// and compute the output sign
aBuf <
mux(intf.dividend[dataWidth - 1] & intf.isSigned,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optimization: these computations are using bit inversion and then adding 1 (e.g. 2s complement conversion).
First idea is: is there a way to stay in 1s complement as that +1 is very costly (full carry).
Second idea is: should we factor out a 2s complement converter so that this operation can be optimized and is very visible -- you don't have to use it, but it does make explicit this operation is not cheap.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be a good one to discuss further and split out of this PR? Also note that given the way things are flopped, the 2's complement inversions shouldn't really cause timing problems (the longest path delays are pretty short by design). That being said, I'm all for optimization - just might make more sense to break it out as it's pretty unrelated to the change set here.

@desmonddak desmonddak merged commit 3530022 into intel:main Nov 15, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants