read_verilog: conflicting drivers for integers set in multiple processes

[widlarizer]

Version

Yosys 0.51 (git sha1 c4b5190, g++ 14.2.1 -fPIC -O3)

On which OS did this happen?

Linux

Reproduction Steps

module bug (
	clk_a,
	clk_b,
);
	input wire clk_a;
	input wire clk_b;
	integer i;
	always @(posedge clk_a) begin
		i = 1;
	end

	always @(posedge clk_b) begin
		i = 2;
	end
endmodule

read_verilog bug.v; proc; check

This is notable as it seems to be a realistic pattern to iterate over integer i from 0 to whatever in two distinct processes, like in techlibs/quicklogic/qlf_k6n10f/sram1024x18_mem.v. I intuitively expect it to be valid Verilog and can't figure out anything clearly to the contrary, even if the standard ominously says "If loops in two or more parallel processes use the same loop control variable, there is a potential of one loop modifying the variable while other loops are still using it."

Expected Behavior

No warnings

Actual Behavior

Warning: multiple conflicting drivers for bad.\i [31]:
    port Q[31] of cell $procdff$4 ($dff)
    port Q[31] of cell $procdff$3 ($dff)
Warning: multiple conflicting drivers for bad.\i [30]:

etc

[widlarizer]

Discussed at dev JF. I think this sums up how we see desired behavior:

If such an variable has multiple drivers created in proc_dff then either

• its output cone doesn't contain a module output. In this case we emit a warning, and discard all except one arbitrary driver
• its output cone contains a module output. We emit an error or keep all conflicting drivers so that check reports an error (as of check: promote some problems to errors by default, add -permissive #5058)

[povik]

@widlarizer Why doesn't it suffice to check whether i has any uses at all? Once it's been blockingly assigned, any uses of i in the same process see the assigned value, so i as an RTLIL wire won't have uses.

Let me link proc_usage: #4325 (comment)

[widlarizer]

@povik When you read_verilog techlibs/quicklogic/qlf_k6n10f/sram1024x18_mem.v; proc; dump you can see i is used by procmux cells. Good to know about proc_usage though

[povik]

I think you can have the same problem with combinational processes in which case proc_dff won't catch it