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

issues handling unsized literals with x/z extending #484

Closed
veripoolbot opened this issue Apr 15, 2012 · 5 comments
Closed

issues handling unsized literals with x/z extending #484

veripoolbot opened this issue Apr 15, 2012 · 5 comments
Labels
resolution: no fix needed Closed; no fix required (not a bug)

Comments

@veripoolbot
Copy link
Contributor


Author Name: Iztok Jeras (@jeras)
Original Redmine Issue: 484 from https://www.veripool.org
Original Date: 2012-04-15


Hi,

One of the issues is Verilator handles 'x as a 32bit value, so WIDTH errors had to be silenced.
The other issue is not clear to me, but could have the same cause.

The next example can be used to test the issue, it was verified using ncsim:
test_regress/t/t_literals.pl
the test can be found at (branch test_sv) https://github.com/jeras/verilator

The testcase is not yet finished, so there might be more related issues, for example signed literals. I will probably update the test toward the end of the week.

Regards,
Iztok Jeras

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-04-16T00:18:38Z


Verilator is correct. It correctly does not warn on 'x, which expands to an arbitrary width. It does warn on 'hx, 'hx is 32 bits according to the spec, it is NOT arbitrary width like 'x.

As for the failure, Verilator is not a 4 state simulator, therefore you cannot store an X and compare to an X and expect it to match. Ditto Z's. Commenting out all lines with 'x and 'z makes it pass.

If you want to `ifdef out the appropriate non-verilator supported lines I'll still be glad to merge in the test.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Iztok Jeras (@jeras)
Original Date: 2012-04-16T06:51:39Z


Hi Wilson,

My expectation was that all x/z bits from variables and literals would be converted to zeros. This would mean that although x and z values are not supported in Verilator, the comparison should be true. Below are the offending operations from the example 1. assignment (seems to work as expected placing all 0 into the variable), 2. comparison (here the literal should be converted to a 2-state 16'b0000_0000_0000_0000 before the comparison).

  1. luv <= 'x;
  2. luv !== 16'bxxxx_xxxx_xxxx_xxxx
  3. $display("luv = 'b%b != 'x", luv);

But this is just my reasoning. If on the other hand I make an assumption: "Verilator just converts all 4-state variables into 2-state variables", this example should behave like a reference simulator with bit variables instead of logic. I tried to run a similar example (intended for Icarus) in ModelSim and I get failures. So if the assumption is correct, then Verilator behaves as expected.

  1. FAILED -- luv = 'b0000000000000000 != 'x
  2. FAILED -- luv = 'b0000000000000000 != 'z
  3. FAILED -- luv = 'b0000000000000000 != 'bx
  4. FAILED -- luv = 'b0000000000000000 != 'bz
    ...

I am not sure haw useful are x/z literals in RTL, the priority of the bug can at least be reduced to low. X is sometimes used in RTL as do-not-care in case statements, Z is sometimes used for bidirectional buses. A somehow more practical example should be found to see if this could be an issue.

I will check the Verilator documentation again to see which of my assumptions is correct.

Regards,
Iztok Jeras

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-04-16T11:29:35Z


The comparison inv !== 1'bx will always be true, because people do x comparisons to check for uninitialized state in RTL. So logic doesn't just become bit. I this last new sentence to the docs:

 Identity comparisons (=== or !==) are converted to standard === when
 neither side is a constant.  This may make the expression result differ
 from a four state simulator.  An === comparison to X will always be false,
 so that Verilog code which checks for uninitialized logic will not fire.

Tristates are another matter, and there are several bugs open related to enhancing them.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-04-26T23:15:31Z


If you want to update the test to match behavior as described above let me know.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-11-03T12:05:14Z


Inactive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: no fix needed Closed; no fix required (not a bug)
Projects
None yet
Development

No branches or pull requests

1 participant