Randomize high-impedance ('Z) signals with --x-assign (or --z-assign)

[dr-mora]

While Verilator doesn't support handling of 'X values directly, it allows setting them to unique random values rather than zeroing them, via the --x-assign and --x-initial flags. I have found this feature useful for detecting some errors in my code. However, these flags don't seem to handle 'Z (high-impedance) values, which are always treated as 0.

Is there a way to randomize 'Z values as well?

The following code demonstrates some errors/defects I've encountered:

`timescale 1ns/1ps

module uut (
    input  logic  [2:0] sel,
    output logic [15:0] out
);

logic [5:0][15:0] mux;

generate
    for (genvar i = 0; i < 5; i++) begin //FIXME(1): should be <= 5
        assign mux[i] = {4{4'(i+1)}};
    end
endgenerate

assign out = mux[sel]; //FIXME(2): not handling cases 6 and 7

endmodule



module tb;

logic  [2:0] sel;
logic [15:0] out;

initial begin
    for (int i=0; i<8; i++) begin
        sel = 3'(i);
        #1;
        $display("sel = %h | out = %h", sel, out);
    end
    $finish;
end

uut uut_inst (.*);

endmodule

In FIXME(2), the developer hasn't considered sel being 6 or 7, in which case it tries to read from a non-existent element of an array, resulting in out=xxxx. In those cases, the desired behavior in my use case was to output 0, so I was very happy to see that "it worked" in simulation without showing any discrepancies, until I realized that it was actually generating 'X, which might result in synthesis tools generating other values.
Then I was pleased to learn about Verilator's --x-assign unique --x-initial unique flags, which randomize the value of 'X variables. Randomizing is not a perfect solution, but it is good enough to detect this type of mistake.

However, in FIXME(1), the error results in that not all elements of the array are assigned, so element [5] is left as 'Z. Here, Verilator leaves it as all zeros even if you use the --x-assign flag. Since Verilator doesn't seem to handle 'Z values at all, it would be nice if --x-assign also randomized 'Z values and not just 'X values, or if separate --z-assign/--z-initial flags were provided.

As a note of interest, I found that the plusarg +verilator+rand+reset+2 will sometimes work like this, and randomize the content of 'Z values as well, but not always (I haven't figured out the conditions for it to work/fail yet).

---

verilator --version = Verilator 5.039 devel rev v5.038-164-g60cbbf0ec (freshly cloned and compiled today)

Note that this version already includes the fix provided in PR #5214, which makes the runtime plusarg +verilator+rand+reset+2 unnecessary.
However, the behavior with and without this runtime option seems to differ, since (as I pointed out) with this option sometimes 'Z is randomized as well.

[wsnyder]

Something that is not initialized should be an 'x' not 'z' but your point still is correct.

As you noted using --x-initial unique does require separate use of +verilator+rand_reset+2 - I'll look at either making 2 the default, or documenting, or something, and take that as what is needed to close this issue unless hear otherwise. The case you provide seems to do what you want with that. If you have a case it "not always" works please drop an example, thanks.

[dr-mora]

Rather than "not initialized" I see it as "not connected", but it is true that mux was technically not declared as a net but as a variable (even though elements [0] to [4] are assigned with a continuous assignment).
However, if you add wire to the declaration to make it a net you still get the same behavior, and in that case I understand that mux[5] is not "not initialized" but rather not connected.

Here are some examples of what works and what doesn't (all of them with the +verilator+rand+reset+2 flag). Specifically, I noticed that if you assign 'Z to some elements of the array then the random assignment stops working. But using 'X doesn't cause this issue. Note that I added wire to the declaration so now mux[5] should be 'Z rather than 'X.

module uut (
    input  logic  [2:0] sel,
    output logic [15:0] out
);

wire logic [5:0][15:0] mux;

generate
    for (genvar i = 0; i < 5; i++) begin //FIXME(1): should be <= 5
        //assign mux[i] = {4{4'(i+1)}}; //--> works
        //assign mux[i] = 16'h1234; //--> works
        //assign mux[i] = 16'h123X; //--> works
        assign mux[i] = 16'h123Z; //--> causes sel=5 to output 0000 rather than random!
    end
endgenerate

assign out = mux[sel]; //FIXME(2): not handling cases 6 and 7

endmodule

It is still not clear to me if the --x-* flags are supposed to affect 'Z values as well, or if they are only meant to touch 'X values and the fact that they're affecting 'Z was actually a bug. (Personally I would like them to apply to 'Z values as well, in order to find coding errors.)

[wsnyder]

z's were intended to be handled differently as they potentially need tristate resolution (though not in your example). It would make sense that they should respect x-rand-reset, as basically after any tristate resolution if the value is still "z" since Verilator can't represent that it should be x-randomized.

Not sure how easy that will be but will look into it.