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

Fixes sendBits()'s handling of signed numbers in svsim's simulation-driver in #4593 #4599

Merged
merged 7 commits into from
Jan 9, 2025

Conversation

AptInit
Copy link
Contributor

@AptInit AptInit commented Jan 7, 2025

Although I don't understand the reasons for not using the conversions provided by stringstream, this PR fixes one of the edge cases as mentioned in #4593 :

If bitWidth % 8 == 0, and the bits have a value of -1<<(bitWidth-1), then the most significant bit will be stripped off by mistake.

Fixes #4593

Contributor Checklist

  • Did you add Scaladoc to every public function/method?
  • Did you add at least one test demonstrating the PR?
  • Did you delete any extraneous printlns/debugging code?
  • Did you specify the type of improvement?
  • Did you add appropriate documentation in docs/src?
  • Did you request a desired merge strategy?
  • Did you add text to be included in the Release Notes for this change?

Type of Improvement

  • Bugfix

Desired Merge Strategy

  • Squash: The PR will be squashed and merged (choose this if you have no preference).

Release Notes

Reviewer Checklist (only modified by reviewer)

  • Did you add the appropriate labels? (Select the most appropriate one based on the "Type of Improvement")
  • Did you mark the proper milestone (Bug fix: 3.6.x, 5.x, or 6.x depending on impact, API modification or big change: 7.0)?
  • Did you review?
  • Did you check whether all relevant Contributor checkboxes have been checked?
  • Did you do one of the following when ready to merge:
    • Squash: You/ the contributor Enable auto-merge (squash), clean up the commit message, and label with Please Merge.
    • Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

Copy link

linux-foundation-easycla bot commented Jan 7, 2025

CLA Signed

The committers listed above are authorized under a signed CLA.

Comment on lines 267 to 269
if (mutableBytes[byteCount - 1] != 0b10000000) {
mutableBytes[byteCount - 1] &= signBitMask - 1;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

What happens if the width isn't a multiple of 8? Can we add tests for like 33 bits? And also can we add a test for 40 bits or something to make sure 32 isn't special as a power of 2?

Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry just saw your comment in #4593 (comment) explaining that this matters for multiples of 8. I still think it would be good to test a non-multiple of 8 width (e.g. 33) and a non-power-of-2 multiple of 2, (e.g. 40).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, I am still very new to the Chisel project, if we want to test other bitWidths, how should we prepare the SystemVerilog file since now we would like to have a parameterized SIntWire module? I mean I can't figure out how svsim/src/main/scala/Workspace.elaborate() works.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it's way too much work to have parameterized modules here. Can we just settle for two different bitWidths here @jackkoenig ?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's way too much work to have parameterized modules here. Can we just settle for two different bitWidths here

Yes I think that makes sense!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually both scanHexBits() and sendBits() are buggy, I think we might as well replace the home-made conversions with something provided by the C++'s standard library in the future.

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually both scanHexBits() and sendBits() are buggy, I think we might as well replace the home-made conversions with something provided by the C++'s standard library in the future.

Do you want to do that in this PR or in a separate PR? Separate is fine if this fixes issues now.

The test you wrote is a good one because it's using the lower-level APIs, but as you noted it's a lot less flexible. We could more easily write parameterized tests using the higher-level Simulator API that's built on top of SVSim, some example tests are here:

class SimulatorSpec extends AnyFunSpec with Matchers {

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you want to do that in this PR or in a separate PR? Separate is fine if this fixes issues now.

Unfortunately I don't think the current fix is nearly enough to fix sendBits().

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Both scanHexBits() and sendBits() should work now @jackkoenig .

@jackkoenig jackkoenig added the Bugfix Fixes a bug, will be included in release notes label Jan 7, 2025
@AptInit
Copy link
Contributor Author

AptInit commented Jan 8, 2025

The tl;dr is, both sendBits() and scanHexBits() are buggy in different ways when handling signed signals.

This PR should fix problems related to sendBits().
For workarounds of the unfixed bugs, use UInt instead of SInt if possible.

Beside the aforementioned stuff, svsim's use of DPI seems to be a bit strange to me. svBitVecVal is used for interfacing data regardless of the actual widths. But I am not experienced with DPI enough to draw a conclusion yet.

…ve number `-1<<(bitWidth-1)` with `bitWidth % 8 == 1` is supplied.
@jackkoenig jackkoenig added this to the 6.x milestone Jan 8, 2025
Copy link
Contributor

@jackkoenig jackkoenig left a comment

Choose a reason for hiding this comment

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

This looks great, thank you!

@jackkoenig jackkoenig enabled auto-merge (squash) January 9, 2025 01:13
jackkoenig pushed a commit to AptInit/chisel that referenced this pull request Jan 9, 2025
@jackkoenig jackkoenig merged commit 05d2622 into chipsalliance:main Jan 9, 2025
15 checks passed
@mergify mergify bot added the Backported This PR has been backported label Jan 9, 2025
@jackkoenig
Copy link
Contributor

@Mergifyio backport 6.x

Copy link
Contributor

mergify bot commented Jan 9, 2025

backport 6.x

✅ Backports have been created

  • Backport to branch 6.x not needed, change already in branch 6.x

@jackkoenig
Copy link
Contributor

I think Github screwed up and merged this PR twice. The first commit has the changes d4d3e97, the 2nd doesn't 05d2622. I think Mergify is finding the 2nd and, because it has no changes, finding nothing to backport. What a weird issue.

jackkoenig pushed a commit that referenced this pull request Jan 9, 2025
chiselbot pushed a commit that referenced this pull request Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backported This PR has been backported Bugfix Fixes a bug, will be included in release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Inconsistent type casting behavior between generated HDL and Chisel's simulation
2 participants