Support for "don't care" bit in comb processes

[smunaut]

Steps to reproduce the issue

module top(
    input [3:0] i,
    output [3:0] o
);

    always @(*)
    begin
        o = 4'b0xxx;
        case (i[3:2])
            2'b00: o = 4'b10xx;
            2'b11: o = { 2'b11, i[1:0] };
        endcase
    end

endmodule

yosys -p 'synth_ice40 -top top -blif test.blif' test.v

Expected behavior

This should generate only 1 LUT4 for o[3] and a pass-through for o[2:0].

o[3] = ~(i[3] ^ i[2]);
o[2:0] = i[2:0]

Actual behavior

This actually generates 4 LUT4 and completely ignores the "don't care" bit I'm trying to convey and treating them as 0 AFAICT.

[cliffordwolf]

and completely ignores the "don't care" bit

That's not true. These are the log messages from where it optimizes those X bits:

Replacing $_MUX_ cell `$auto$simplemap.cc:277:simplemap_mux$93' (x??) in module `\top' with constant driver `$techmap$procmux$3.$ternary$/usr/local/bin/../share/yosys/techmap.v:445$67_Y [0] = $techmap$procmux$3.$reduce_or$/usr/local/bin/../share/yosys/techmap.v:441$70_Y'.
Replacing $_MUX_ cell `$auto$simplemap.cc:277:simplemap_mux$94' (x??) in module `\top' with constant driver `$techmap$procmux$3.$ternary$/usr/local/bin/../share/yosys/techmap.v:445$67_Y [1] = $techmap$procmux$3.$reduce_or$/usr/local/bin/../share/yosys/techmap.v:441$71_Y'.
Replacing $_MUX_ cell `$auto$simplemap.cc:277:simplemap_mux$95' (x??) in module `\top' with constant driver `$techmap$procmux$3.$ternary$/usr/local/bin/../share/yosys/techmap.v:445$67_Y [2] = $procmux$4_CMP'.
Replacing $_AND_ cell `$auto$simplemap.cc:85:simplemap_bitop$86' (x?) in module `\top' with constant driver `$techmap$procmux$3.$and$/usr/local/bin/../share/yosys/techmap.v:434$69_Y [1] = 1'0'.
Replacing $_AND_ cell `$auto$simplemap.cc:85:simplemap_bitop$85' (x?) in module `\top' with constant driver `$techmap$procmux$3.$and$/usr/local/bin/../share/yosys/techmap.v:434$69_Y [0] = 1'0'.

and treating them as 0

No. It just happens to produce a circuit with similar behavior.

It's not realistic to expect the tool to always find the optimal LUT implementation for a circuit. Btw, I just ran your test module through the vendor tools and they also produce a circuit with 4 LUTs.

[balanx]

code

module test (input [31:0] i, output reg x);

always @* begin
case (i)
3 : x = 1'b1;
4 : x = 1'b0;
default: x = 1'bx;
endcase
end

endmodule

step

read_verilog test.v
hierarchy -check -top test
proc; opt
show

expected behavior

x= ~i[2];

actual behavior

what's wrong with my step ? thanks

[whitequark]

It's not realistic to expect the tool to always find the optimal LUT implementation for a circuit.

I think this specific case can still be improved. At least I don't see any reason why. This seems like something the SAT based sharing pass could find, no?