That's a Yosys bug, since Yosys is what writes the Verilog in the first place.

You're 100% right, sorry. This is the ilang nMigen generates:

module \top
  wire width 1 input 0 $signal
  wire width 1 output 1 \a
  wire width 1 $next\a
  wire width 1 $1
  cell $reduce_bool $2
    parameter \A_SIGNED 0
    parameter \A_WIDTH 0
    parameter \Y_WIDTH 1
    connect \A {}
    connect \Y $1
  end
  process $group_0
    assign $next\a 1'0
    assign $next\a $1
    sync init
    sync always
      update \a $next\a
  end
end

And this is syntactically valid as it's deliberately special-cased in ilang_parser.y in Yosys, although the Yosys manual is less clear on it (4.2.4):

A “signal” is everything that can be applied to a cell port. I.e.
...
• Concatenations of the above
For example: {16’d1337, mywire[15:8]}

However the sequence read_ilang; write_verilog; delete; read_verilog fails, whilst read_ilang; synth; write_verilog; delete; read_verilog succeeds. I'll open an upstream issue after a bit more digging.

By the way this wasn't deliberate troublemaking, I had some code that looked like this:

def smear_lx(sig):
	return Cat(sig[:i].bool() for i in range(sig.nbits))

def priority_select(req):
	return req & ~smear_lx(req)

def round_robin(req, prev_grant):
	req_unwrap = Cat(req & smear_lx(prev_grant), req)
	grant_unwrap = priority_select(req_unwrap)
	return grant_unwrap[:req.nbits] | grant_unwrap[req.nbits:]

and I guess there's a secondary question on this issue, namely, is this intended to be valid in nMigen?

I think zero width values are perfectly reasonable. We currently don't support zero width signals, mostly for historic reasons; I'm less certain about those but it probably makes sense to support those too.

We currently don't support zero width signals, mostly for historic reasons

Actually, we do support them, which is good.

Clifford's reponse on Yosys issue:

You should never use write_verilog with an RTLIL design with processes. It even gives you the following warning:

Warning: Module top contains unmapped RTLIL processes. RTLIL processes
can't always be mapped directly to Verilog always blocks. Unintended
changes in simulation behavior are possible! Use "proc" to convert
processes to logic networks and registers.

I think I've fixed it in #953. But generating Verilog with zero-width expressions is really asking for troubles imho. I think it's better to get rid of them by running something like opt_expr before writing the Verilog output.

The Yosys patch just generates an empty Verilog string literal when a zero-width expression is encountered. The resulting Verilog synthesises fine with Yosys, so I think this issue can be closed.

However as Clifford said, this is a dingy corner of the standard, so perhaps:

• If RTLIL has a strong opinion about how zero-width signals should work, it should enforce that internally
• OR if nMigen has a strong opinion on how zero-width signals should work, it should enforce that before generating RTLIIL
• OR option 3, "shut up Luke"

I also note that that same warning ^^^ is produced for the full nMigen pipeline of

read_ilang <<rtlil
{}
rtlil
proc_init
proc_arst
proc_dff
proc_clean
memory_collect
write_verilog -norename

Ugh, that's annoying. I think if Yosys doesn't want to support zero-width signals in RTLIL or write_verilog it should enforce that. Otherwise the current situation is fine.

Thanks for investigating.