Illegal Verilog output after 'proc_prune'; assigns 'reg' from a constant

[strobo5]

Steps to reproduce the issue

The following procedure generates illegal Verilog (at least XST fails and quick research tells me it cannot be blamed).
assign a_pc[1:0] = 2'h0; (outside an always block)
When the ilang code is changed so that the default case is named explicitly (case -> case 1'1) then the Verilog code is as expected.

$ yosys -p "read_ilang bug.il; proc_prune; write_verilog bug.v"
[..]
2. Executing PROC_PRUNE pass (remove redundant assignments in processes).
Removed 0 redundant assignments.
Promoted 1 assignment to connection.
[..]

module\top
  wire width 1 input 0 \sel
  wire width 8 output 1 \a_pc
  process $group_1
    assign \a_pc 8'00000000
    switch \sel
      case 1'0
        assign \a_pc [7:2] 6'101010
      case
        assign \a_pc [7:2] 6'111111
    end
    sync init
  end
end

Expected behavior

/* Generated by Yosys 0.9+2406 (git sha1 584780d7, gcc 9.2.0-r2 -O2 -march=bdver2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -maes -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mtbm -mavx -msse4.2 -msse4.1 -mlzcnt -mf16c -mprfchw -mfxsr -mxsave -mtune=bdver2 -fPIC -Os) */

module top(a_pc, sel);
  output [7:0] a_pc;
  reg [7:0] a_pc;
  input sel;
  always @* begin
    a_pc = 8'h00;
    casez (sel)
      1'h0:
          a_pc[7:2] = 6'h2a;
      1'h1:
          a_pc[7:2] = 6'h3f;
    endcase
  end
  initial begin
  end
endmodule

Actual behavior

/* Generated by Yosys 0.9+2406 (git sha1 584780d7, gcc 9.2.0-r2 -O2 -march=bdver2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -maes -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mtbm -mavx -msse4.2 -msse4.1 -mlzcnt -mf16c -mprfchw -mfxsr -mxsave -mtune=bdver2 -fPIC -Os) */

module top(a_pc, sel);
  output [7:0] a_pc;
  reg [7:0] a_pc;
  input sel;
  always @* begin
    casez (sel)
      1'h0:
          a_pc[7:2] = 6'h2a;
      default:
          a_pc[7:2] = 6'h3f;
    endcase
  end
  initial begin
  end
  assign a_pc[1:0] = 2'h0;
endmodule

[whitequark]

So, write_verilog tells you that the input contains processes and it doesn't guarantee that the result will be correct, right? Looks like one of those cases.

What are you trying to do exactly?

[strobo5]

So, write_verilog tells you that the input contains processes and it doesn't guarantee that the result will be correct, right? Looks like one of those cases.

Mh well it says "Unintended changes in simulation behavior are possible!"

What are you trying to do exactly?

I have a small nMigen design around minerva which fails during synthesis in ISE after a recent change minerva-cpu/minerva@890975e . This is the troublesome part of the Verilog code from nMigen (python mydesign.py generate mydesign.v):

  always @* begin
    (* src = "/foo/minerva/minerva/units/fetch.py:49" *)
    casez ({ \$21 , \$19 , \$17  })
      /* src = "/foo/minerva/minerva/units/fetch.py:49" */
      3'b??1:
          a_pc[31:2] = m_a_pc[31:2];
      /* src = "/foo/minerva/minerva/units/fetch.py:51" */
      3'b?1?:
          a_pc[31:2] = d_pc[31:2];
      /* src = "/foo/minerva/minerva/units/fetch.py:53" */
      3'b1??:
          a_pc[31:2] = d_branch_target[31:2];
      /* src = "/foo/minerva/minerva/units/fetch.py:55" */
      default:
          a_pc[31:2] = \$23 [29:0];
    endcase
  end
  assign \$23  = \$24 ;
  assign a_pc[1:0] = 2'h0;

[whitequark]

Hm, you're right, and my initial assessment was incorrect--this has nothing to do with processes.

Rather this is an interesting corner case and a bug in write_verilog. There is no problem in proc_prune though, since it produces perfectly valid RTLIL.

[whitequark]

As a workaround I suggest you use the complete proc command before handing off the results to ISE.

[whitequark]

I've looked closer at this and I'm afraid it'll require some fairly significant re-engineering of the Verilog backend to properly fix.

[whitequark]

Will be fixed by #4314.