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

Expression evaluates to 1'bx instead of expected 1'b0 #283

Closed
ymherklotz opened this issue Nov 12, 2019 · 3 comments
Closed

Expression evaluates to 1'bx instead of expected 1'b0 #283

ymherklotz opened this issue Nov 12, 2019 · 3 comments
Labels
Bug

Comments

@ymherklotz
Copy link

@ymherklotz ymherklotz commented Nov 12, 2019

The following code outputs and assigns y to 1'bx instead of 1'b0. This happens in iverilog version 10.3 and also happens in version 10.0 (11/23/14) on edaplayground. However, this seems to execute fine in version 9.6 and 9.7 on edaplayground.

I have a link to the design loaded in edaplayground.

module testbench;
   wire y;
   reg  clk;
   reg [15:0] wire0; // Reducing the size of wire0 to 15 bits seems to fix the output.
   reg        reg1 = 1'h0;
   assign y = reg1;
   initial
     begin
        clk = 1'h0;
        wire0 = 1'h0;
        #10 $finish;
     end
   always #5 clk = ~clk;
   always @(posedge clk) $strobe("%b", y);
   // Problematic line, should assign 1'b0 but assigns 1'bx.
   always @(posedge clk) reg1 <= (wire0 >> {wire0 ~^ 1'b1, wire0});
endmodule

After running

iverilog testbench.v -o im && ./im

the output is x instead of 0.

If the always block is not used, and the expression is assigned to y directly, the result is the expected 1'b0. Any changes to the expression seems to fix the result as well.

@ymherklotz ymherklotz changed the title Expression evaluating to 1'bx instead of expected 1'b0 Expression evaluates to 1'bx instead of expected 1'b0 Nov 12, 2019
@martinwhitaker

This comment has been minimized.

Copy link
Collaborator

@martinwhitaker martinwhitaker commented Nov 13, 2019

I assume this is an artificial stress test, as the expression should evaluate to zero for any unambiguous value of wire0.

The problem is that the shift distance evaluates to a large 32-bit value (32'hfffe0000). The vvp %shiftr instruction casts the value to an int before performing the shift operation, thus converting it to a left shift.

@martinwhitaker martinwhitaker added the Bug label Nov 13, 2019
@ymherklotz

This comment has been minimized.

Copy link
Author

@ymherklotz ymherklotz commented Nov 13, 2019

Ah OK thanks for explaining the reasoning for that. I was testing Quartus using randomly generated designs and was surprised that an undefined value was present in the output.

martinwhitaker added a commit that referenced this issue Nov 16, 2019
1364-2005 section 5.1.12 says "The right operand is always treated
as an unsigned number".

This fixes GitHub issue #283.
martinwhitaker added a commit that referenced this issue Nov 16, 2019
1364-2005 section 5.1.12 says "The right operand is always treated
as an unsigned number".

This fixes GitHub issue #283.

(cherry picked from commit 0a4cae2)
@martinwhitaker

This comment has been minimized.

Copy link
Collaborator

@martinwhitaker martinwhitaker commented Nov 16, 2019

Fixed in both master and v10 branches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.