errors · sim, bitdewfpga sim and dewfpga bit, the source scan before the tools

design.sv:5: ERROR [unique-case-overlap]: the items 4'b10?? (design.sv:4) and 4'b??11 (design.sv:5) of this unique casez both match 4'b1011, and unique promises that only one item can match: the simulation takes the first item (iverilog ignores unique), and the hardware, built as parallel logic the way Vivado builds a unique case (UG901 Ch.10, parallel_case), ORs the two items' values, so the board would not do what the simulation showed. Fix: make the items disjoint (4'b10?? and 4'b0?11), write priority casez when the first match should win, or drop unique.

dewfpga sim or dewfpga bit on a design whose unique casez has two items that overlap:

design.sv:5: ERROR [unique-case-overlap]: the items 4'b10?? (design.sv:4) and 4'b??11 (design.sv:5) of this unique casez both match 4'b1011, and unique promises that only one item can match: the simulation takes the first item (iverilog ignores unique), and the hardware, built as parallel logic the way Vivado builds a unique case (UG901 Ch.10, parallel_case), ORs the two items' values, so the board would not do what the simulation showed. Fix: make the items disjoint (4'b10?? and 4'b0?11), write priority casez when the first match should win, or drop unique. https://nosey-dewdrop.github.io/dewfpga/errors/unique-case-overlap/

The design that printed it:

module top(input logic [15:0] sw, output logic [15:0] led);
  always_comb begin
    led = '0;
    unique casez (sw[3:0])
      4'b10??: led[1:0] = 2'd1;
      4'b??11: led[1:0] = 2'd2;
      default: led[1:0] = 2'd0;
    endcase
  end
endmodule

Why does it happen?

unique is a promise, not a priority: it asserts that no two items match at once (IEEE 1800-2017 12.5.3), and every tool is free to build on that promise. The tools disagree on what to do when it is broken. iverilog ignores unique and takes the first matching item, so dewfpga sim shows led = 1 for sw[3:0] = 4'b1011. yosys, yosys-slang and Vivado (UG901 v2023.2 Ch.10 p.279: a unique case is treated as parallel_case and full_case) build the items as parallel logic with no priority chain, and when two match, their values are ORed: the board shows led = 3. Measured on seed 6 of test/fuzz: rtl 0000000000000001, netlist 0000000000000011. The same unique case with disjoint items, as the course's 18_unique_priority probe writes it (unique case (sw[1:0]) with the four constants 2'd0 to 2'd3), builds the same on every tool.

Because this is a disagreement between the simulator and the hardware that no simulation can show, the source scan stops both commands before the tools run.

The scan reads the patterns, not the values they assign, so it also stops a design whose overlapping items happen to agree: seed 27 of test/fuzz has 4'b??11: s2 = {4{2'd1}} over 4'b?0?1: s2 = (&btnL), whose OR is the first item's value, and its netlist matched its RTL for all 300 cycles before the scan existed. In test/fuzz/run.sh 1 500, 24 of the 500 random designs carry such an overlap; 22 of them built equal, 1 (seed 6) built wrong, 1 (seed 345) was refused by yosys-slang before it could build. The 22 are refused the same way, because the agreement is an accident of the values on that line, not something the design promised.

What is the fix?

Make the items disjoint, so that only one can ever match:

    unique casez (sw[3:0])
      4'b10??: led[1:0] = 2'd1;
      4'b0?11: led[1:0] = 2'd2;
      default: led[1:0] = 2'd0;
    endcase

If the first match should win, say so: priority casez builds the if/else chain the simulation shows. If neither matters, drop unique: a plain casez is a priority chain in every tool.

Which command prints it?

Which probes in test/sv print this code?

Every probe, with what Vivado does and what each stage does here: the probes, stage by stage.