issues handling unsized literals with x/z extending
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
#1 Updated by Wilson Snyder over 1 year ago
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.
#2 Updated by Iztok Jeras over 1 year ago
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.
- FAILED -- luv = 'b0000000000000000 != 'x
- FAILED -- luv = 'b0000000000000000 != 'z
- FAILED -- luv = 'b0000000000000000 != 'bx
- 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
#3 Updated by Wilson Snyder over 1 year ago
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.