Is it better to combine logic for two flip flops in a single always block?

Question

I have always used separate always block for infering different flip flops when they dont have much in common.

always_ff@(posedge clk) begin
    if(rst) q1<='0;
    else if(en1) begin
    ......
    end
end

always_ff@(posedge clk) begin
    if(rst) q2<='0;
    else begin
        case(sel)
        ......
        endcase
    end
end

I find it easier to add/modify logic if they are coded in separate always blocks.

I recently read a paper that said :

Each inferred flip-flop should not be independently modeled in its own procedural block/process. As a matter of style, all inferred flip-flops of a given function or even groups of functions should be described using a single procedural block/process. Multiple procedural blocks/processes should be used to model larger partitioned blocks within a given module/architecture. The exception to this guideline is that of follower flip-flops as discussed in section 3.1 where multiple procedural blocks/processes are required to efficiently model the function itself.

Is there a benefit for using single always block or a hazard if we use separate blocks? The only reason I could think of for not using multiple always blocks is(that I have read elsewhere) is it degrades simulator performance.

Answer 1

Using multiple always blocks will make your code modular, and hence easier to maintain and debug, which is essential when the design gets bigger and complex.

However, it is observed that the increase in number of always blocks slows down the simulation compared to the same logic written in a single always block (See the Source). Otherwise, I dont see any reason why you have to opt out from using multiple always blocks.

Answer 2

Any decent simulator ought to be able to merge sequential always blocks having common clock and reset inputs, so as to amortize scheduling overhead. At least one EDA vendor does this, and I would not be surprised if they all do.

Write your code for maximum clarity, and let the simulator vendors worry about performance.