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

Incorrect result from shift operation #1165

Closed
Jiabao1125 opened this issue Sep 2, 2024 · 2 comments · Fixed by #1166
Closed

Incorrect result from shift operation #1165

Jiabao1125 opened this issue Sep 2, 2024 · 2 comments · Fixed by #1166
Assignees
Labels

Comments

@Jiabao1125
Copy link

module top();

reg signed [1:0] shift;
reg [31:0] y;

initial begin
    shift = 2'b10;
    y = 32'd7 << shift[1:0];
    $display("%b", y);
end

endmodule
 

When running this test code, Icarus Verilog returns:

00000000000000000000000000000000

However, when testing the same code with Jasper 2022.09, Jasper returns:

00000000000000000000000000011100

Our initial analysis suggests that the 'shift' variable was treated as signed and sign-extended, which resulted in a left shift amount that was too large, causing the final result to be zero.

According to the IEEE Standard for SystemVerilog 1800-2017:

The right operand is always treated as an unsigned number and has no effect on the signedness of the result.

Therefore, during the extension, 'shift' should be treated as unsigned, and the final shift amount should be 2'b10 (which is 2 in decimal). The correct result should be ’11100‘, not all zeros.

@larsclausen
Copy link
Collaborator

Thanks for reporting this. This seems to be a general issue when loading a vector slice into an index register (a implementation detail of the icarus runtime).

Fix is in #1166. Still need to write a few regression test cases before this is ready to be merged.

@larsclausen larsclausen added the Bug label Sep 2, 2024
@caryr
Copy link
Collaborator

caryr commented Sep 5, 2024

This should have been treated as an unsigned shift since a part select shift[1:0] is always treated as unsigned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants