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

Misoptimization of case with string compares #1536

Closed
veripoolbot opened this issue Oct 4, 2019 · 3 comments
Closed

Misoptimization of case with string compares #1536

veripoolbot opened this issue Oct 4, 2019 · 3 comments
Assignees
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: Philipp Wagner
Original Redmine Issue: 1536 from https://www.veripool.org

Original Assignee: Wilson Snyder (@wsnyder)


I have (simplified) code like this:


  logic [2:0] counter;

  function void with_case();
     string      mystr;
     case (counter)
       3'b000: mystr = "case-0";
       3'b001: mystr = "case-1";
       3'b010: mystr = "case-2";
       3'b100: mystr = "case-4";
       3'b101: mystr = "case-5";
`ifdef WITH_DEFAULT
       default: mystr = "bad-default";
`endif
     endcase

     $display("with_case: %d = %s", counter, mystr);
     return;
  endfunction

  always_ff @(posedge clk_i) begin
     counter <= counter + 1;

     if (counter == 3'b111) begin
       $finish;
     end
  end

  always_comb begin
     with_case();
  end
</code>

When I compile without WITH_DEFAULT being set, everything works as expected, and I get output like this:

with_case: 0 = case-0
with_case: 1 = case-1
with_case: 2 = case-2
with_case: 3 = case-2
with_case: 4 = case-4
with_case: 5 = case-5
with_case: 6 = case-5
with_case: 7 = case-5
with_case: 0 = case-0

But if I compile with WITH_DEFAULT set, I get this output; effectively, the default label is always taken.

with_case: 0 = case-default
with_case: 1 = case-default
with_case: 2 = case-default
...

The same behavior can be observed if I switch from case to if statements.
I put together a full testcase at https://github.com/imphil/verilator-case, it can be run by typing make.
The full code where we observed this behavior is at https://github.com/lowRISC/ibex/blob/2acb497d22a5da877a9c4350ef5693d0c767cc61/rtl/ibex_tracer.sv#L584

Looking at the generated C code, it looks like somehow the if/case statements get optimized out when compiling with default/else branches.
I'd appreciate any pointers on how to debug this further.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-10-04T23:14:21Z


Thanks for the good test case. What's going on is when the case statement is getting optimized it treated the different result strings as matching when they shouldn't.

Also added a boat-load of assertions to check for similar missing string cases, but nothing turned up in existing regressions.

Fixed in git towards eventual 4.020 release.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Philipp Wagner
Original Date: 2019-10-05T17:40:07Z


Confirmed fixed. Thanks Wilson for the quick fix!

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-10-06T14:08:20Z


In 4.020. Thanks for reporting this; if there are additional related problems, please open a new issue.

@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
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: fixed Closed; fixed
Projects
None yet
Development

No branches or pull requests

2 participants