Flip-flop issue in iVerilog synthesis.

[Butylochnik]

Hello,
Let’s suppose we have simple schematic which captures data bus after certain amount of clock pulses. The code of this schematic can be as follows:

module capturer #(parameter CTIME = 8)
    (
    input clk,
    input reset,
    input [7 : 0] datain,
    output [7 : 0] capted);  

    reg [7 : 0] capted;
    reg [5 : 0] counter;

    always @(posedge clk, posedge reset)
        if (reset) begin
            counter <= 0;
            capted <= 0;    //Error happens if this string is commented
        end
        else
            if (counter == CTIME) begin
                capted <= datain;
                counter <= 0;
            end
            else
                counter <= counter + 1;

endmodule // capturer

I use iVerilog 12 and it performs synthesis (using -S key) of this schematic well, but if I comment line 14 (comment), synthesis fails with errors:

capturer1.v:12: sorry: Not all bits of 'capted' are asynchronously set or reset. This is not currently supported in synthesis.
capturer1.v:11: error: Unable to synthesize synchronous process.

It looks like always flock forms a kind of «clock domain» and it is forbidden to have different flip-flops (with asynchronous reset and without) in it. In the output net-list I see 2 flip-flop arrays:

L_0xd734a0 .dff/p/aclr 6 L_0xd73310, o0x7fb5392cd228, L_0xd62cb0, o0x7fb5392cd2b8;
L_0xd735e0 .dff/p/aclr 8 o0x7fb5392cd288, o0x7fb5392cd228, L_0xd72f90, o0x7fb5392cd2b8;

Really I don’t need the asynchronous reset for capture register, but I should connect it due to this restriction.
From the other hand if I describe the schematic by another way – put counter and capture register in different always blocks – there is no need to provide asynchronous reset to capture register and synthesis is performed well:

module capturer #(parameter CTIME = 8)
    (
    input clk,
    input reset,
    input [7 : 0] datain,
    output [7 : 0] capted);  

    reg [7 : 0] capted;
    reg [5 : 0] counter;

    always @(posedge clk, posedge reset)
        if (reset) counter <= 0;
        else
            if (counter == CTIME + 1) counter <= 1;
            else counter <= counter + 1;

    always @(posedge clk)
        if (counter == CTIME) capted <= datain;
                
endmodule // capturer

In the output net-list I see 2 flip-flop arrays – one with reset and other without:

L_0x1b94f80 .dff/p 8 o0x7f50b7a25348, o0x7f50b7a252e8, L_0x1b94e10;
L_0x1b95700 .dff/p/aclr 6 L_0x1b95570, o0x7f50b7a252e8, L_0x1b84b30, o0x7f50b7a25378;

Actually, it is no problem to use 2-nd version instead of first. But 2-nd version requires more HW – at least 2 comparators instead of 1!

Could anyone explain me the reason of such behavior of synthesis tool?
Why always block can’t contain flip-flops with and without synchronous reset?
Is it only restriction of iVerilog synthesis or real FPGA devices as well?

[logicmonkey]

This is an issue with all synthesis tools that I have used over the years - and it isn't restricted to Verilog/SV - it's VHDL as well.

I can't remember the exact reason, but it's actually a latch inference problem. If you don't reset EVERYTHING in a "sequential process"/always_ff you will have a latch. So I agree with iVerilog's behaviour here.

I have seen in-house tools developed to detect such code, but I would expect the issue to be handled by most modern linting tools.

Based on experience - don't write code like this. If you really don't want to reset something, put it in another always_ff WITHOUT a reset and use another signal to assign at the clock edge.

[Butylochnik]

Thank you for your explanation. I understood the general idea.
I looked on this subject in the Internet and found mentioning about some tools, which allows resetable and non-resetable ffs in the same always block. But I understood that it is bad practice. Moreover, using asynchronous reset for purposes different from initialization at startup or global Reset is bad practice as well. But in some cases it is necessary. For instance, in salve SPI device CSn can be used as the initialization of the SPI state machine.