FSM state changes in Verilog

I have seen the following used to make state changes in Verilog modules:

state <= 开发者_如何转开发2'b10;

state <= #1 IDLE;

Why is <= used and not just =? What is the purpose of using #1? Does it make a difference?

Here is some Verilog code for a FSM that shows the first one being used. Would it work the same if it was replaced with the second?

module fsm( clk, rst, inp, outp);

   input clk, rst, inp;
   output outp;

   reg [1:0] state;
   reg outp;

   always @( posedge clk, posedge rst )
   begin
   if( rst )
       state <= 2'b00;
   else
   begin
       case( state )
       2'b00:
       begin
            if( inp ) state <= 2'b01;
            else state <= 2'b10;
       end

       2'b01:
       begin
            if( inp ) state <= 2'b11;
            else state <= 2'b10;
       end

       2'b10:
       begin
            if( inp ) state <= 2'b01;
            else state <= 2'b11;
       end

       2'b11:
       begin
            if( inp ) state <= 2'b01;
            else state <= 2'b10;
       end
       endcase
   end
end

---

In a sequential logic always block like yours, it is better to use non-blocking assignments (<=) instead of blocking assignments (=). Simulations will be better representative of the actual resulting logic.

In pure RTL Verilog code, if you are using non-blocking assignments for all sequential logic, there should be no reason to use #1 delays.

I have also seen others use # delays like this. Sometimes it is due to mixing RTL and gate netlists in the same simulation. Other times it is done to compensate for poor modeling. You should avoid using delays in RTL code if you can.

See also: Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!

Also, it is better to use a parameter to name each of your states. It is much more meaningful if a state is named IDLE instead of 2'b10.

---

Verilog is inherently non-deterministic. This means that in general, there are multiple possible outcomes of a simulation, which are all different, but valid according to the standard.

To avoid non-deterministic behavior from clocked always blocks, you have to use non-blocking assignments for those variables that are used in other blocks (non-local variables). For a more detailed analysis, see my blog post on the subject:

http://www.sigasi.com/content/verilogs-major-flaw

Synthesis tools typically accept blocking assignments for non-local variables in clocked always blocks, but this is really an error as there is no way they can guarantee that the synthesized logic will behave like the model (as such a model is non-deterministic).

In contrast to what you will hear from many others, such a Cliff Cummings' popular papers, there is no need to only use non-blocking assignments for local variables. Blocking assignments are perfectly acceptable for local variables. This is relevant, because it permits to use pure "variable" semantics (as in programming languages) for internal modeling.

In pure RTL style modeling, #1 delays are just overhead.