Mixed blocking & non-blocking assignment
Articles that say "nonblocking and blocking assignments do not have any effect on the synthesis, but only regards to the simulation" are incorrect. It is true there are certain cases where choosing either assignment operator has no affect on the synthesized hardware, but there are cases where it does make a difference. 

One needs to realize that code you write executes in serial order within a begin/end block regardless of whether it represents a sequential or combinational circuit. Both simulation and synthesis tools need to implement the behavior you specify. 

You can model both sequential and combinatorial circuits with just blocking assignments (in fact, non-blocking assignments were a later addition to the Verilog language). You can determine if the code represents a particular kind of circuit by looking at the order of assignments to the LHS variables with respect when the same variables are used in the RHS. 

always @(posedge clk)begin
    ab  =  a &amp; b &amp; q0;  
    q0  =  ab; 
  end 


Because ab appears in a blocking assignment statement before appearing on the RHS, it is considered combinational (write before read). And the value of ab gets updated immediately before executing the next statement. And since q0 appears on the RHS before appearing on the LHS, it is considered sequential (read before write).

But if we add another always block that uses ab on the RHS, that usage is considered sequential. 

always @(posedge clk) begin
        c = ab;  
      end 


Now ab represents sequential logic in that block because the other block executed on a clock edge, sampling the values of a and b. But now we have a simulation race condition because although the execution order within a begin/end block is serial, there is no defined ordering between different always blocks triggered by the same clock edge - you don't know if the second always block has the updated value of ab from the first always block.

The non-blocking assignment solves this race simulation race condition by delaying the LHS assignment until after everything else that was supposed to execute at the same time step. If we change the assignment to ab in the first always block to:

always @(posedge clk)begin
    ab  &lt;=  a &amp; b &amp; q0; // NBA
    q0  =  ab; 
  end  


Now the second always block is guaranteed to have the "old" value of ab. But this also does affect the statement that follows it in the same block. It now assigned the "old" value of ab to q0. So now it does take two clock cycles to get the value through to q0.