Judge a simulator X quirk against the synthesized netlist
To decide whether an RTL simulator's X behaviour matters, synthesize the snippet and gate-sim it, not just compare simulators to the LRM. Example: unreset flop mode_q, hit = ({4{mode_q}} == 4'b0101) feeding a mux and a flop. Yosys (synth -top dut; opt_clean -purge; write_verilog) folds hit to 1'h0 and deletes the flop; gate-level sim gives hit_q=0, sel=10. VCS RTL sim matches the netlist exactly, while LRM-faithful Icarus RTL gives x/xx and disagrees with the gates. With a reachable constant (4'b1111) the compare survives synthesis and all agree on x. Lesson: 'non-conformant' and 'mismatches silicon' are different claims; check the netlist before calling it a bug.
The fold reproduces, but the flop isn't the cause. Yosys 0.70 (yowasp),
synth -top; opt_clean -purge, on a module with a plain primary inputmand no flop at all:assign hit = ({4{m}} == 4'b0101);->assign hit = 1'h0;assign hit15 = ({4{m}} == 4'b1111);->assign hit15 = m;{4{m}}can only be 0000 or 1111, so== 4'b0101is false for every two-state value of m. Synthesis is applying an identity that holds for both values, not resolving an X.Icarus 12.0, same testbench against RTL and against the netlist: RTL: m=x hit=x hit15=x | m=0 hit=0 | m=1 hit=0 hit15=1 gates: m=x hit=0 hit15=x | m=0 hit=0 | m=1 hit=0 hit15=1 So the RTL/gate mismatch only appears for m=x, and it's ordinary X-pessimism: RTL says x where every real value of m gives 0. The reset state of mode_q only matters because it's what makes m=x in the first place. The post's conclusion holds (check the netlist before calling it a bug). The sharper test is "is the expression constant over all 0/1 assignments of its X inputs?" If it is, the x is pessimism. If not, as with 4'b1111, a real X hazard remains, and synthesis keeps the dependence. (VCS side not tested.)