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

Jump to bottom

Incorrect result of signed shift #828

Closed
veripoolbot opened this issue Oct 9, 2014 · 4 comments
Closed

Incorrect result of signed shift #828

veripoolbot opened this issue Oct 9, 2014 · 4 comments
Assignees
@wsnyder
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor

Author Name: Geoff Barrett
Original Redmine Issue: 828 from https://www.veripool.org
Original Date: 2014-10-09
Original Assignee: Wilson Snyder (@wsnyder)

The following code gets the wrong values.

initial begin
  $display("0x00000180==0x%h", 32'(signed'({4'b0001,5'b10000}) << 3));
  $display("0x00000380==0x%h", 32'(signed'({4'b0011,5'b10000}) << 3));
  $finish();
end

Verilator output is as follows:

0x00000180==0xffffff80
0x00000380==0xffffff80

Output from a couple of other simulators is this:

0x00000180==0x00000180
0x00000380==0x00000380

I would expect this code to create a logic[8:0], cast it to logic signed[8:0], shift it left into a logic signed[11:0] and then sign extend to a logic signed[31:0]. It looks like the result of the shift is the same width as its input, hence the sign bit is getting set and the 32-bit extension is incorrect. I suspect any values in the top 3 bits will be lost as a result of the shift as well.
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Geoff Barrett
Original Date: 2014-10-10T08:31:19Z

Studying the LRM, it looks like verilator gets this right whereas the commercial simulators do not follow the standard. I'm concerned about the difference in semantics though, especially if synthesis tools don't follow the standard either.

Is it possible to add a warning for this and similar cases? In particular, where the answer might be different if intermediate expressions are truncated. This should apply to at least '<<', '<<<', '+', '-', '*' and '**'.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Geoff Barrett
Original Date: 2014-10-13T10:19:01Z

It's more complicated than a first reading of the LRM would reveal so this is actually a bug in verilator.

The correct interpretation of the standard is that the context of the expression (in this case the 32'(...) casting) defines the width of the left hand operand of the shift. So the expression is equivalent to ``` 32'(signed'({4'b0001,5'b10000})) << 32

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-10-17T23:02:16Z

Right.

Fixed in git towards 3.866.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-11-15T13:46:29Z

In 3.866.

@veripoolbot veripoolbot added area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: fixed Closed; fixed labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@wsnyder wsnyder

Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: fixed Closed; fixed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@wsnyder @veripoolbot