Lecture 04

State Machine with High Branching and Merging

• example find borg|car|cat|bat|bot|bet|bit and output $\rm done$ flag where $\rm done$ is a registered output

• $\rm done$ flag logic cannot be coded directly based on CS and with the final states

• registered outputs in general must coded once per transistion, though the existance of one common default may save some lines of code

  always @ (posedge clk) begin
  CS<=failed; //defaults
  found<=0; done<=0; //defaults
  case (CS)
    ...
    recieved_a: if (input =='r') begin
                  CS<=recieved_r_for_car;
                  done<=1; found<=1;
                end else if (input =='t') begin
                  CS<=recieved_t;
                  done<=1; found<=1;
                end else begin
                  CS<=failed;  //covered by default
                  done<=1; found<=0;
                end
    ...
  

• output logic coded with use of next state NS

  CS<=failed; 
  found<=0; done<=0; //defaults
  case (NS)
    recieved_t:done<=1;found<=1;
    recieved_r_for_car:done<=1;found<=1;
    recieved_g:done<=1;found<=1;
    failed:done<=1;found<=0;
    default:done<=0;
  ...
  

Extended State Registers

note the explicit state register and the additional extended state registers

Implementation of Waits

Some Options:

• Add “top” level wait states to state machine in each place needed
• Use a counter
  • a) Use external counter ( implement as an external state machine) and interface to it
  • b) embed something like a counter in the coding of the state machine, thus creating substates using the counter as an extended state register.
• Create a single programmable wait state to jump to and return to from multiple states using a “jump” register extended state register

Unconditional Delay Using Extra States

Unconditional Delay Using Extended State Register Variable : Counter

Minimal Pause: Delay + Conditional Exit Using An Extra State (unconditional delay +conditional exit)

Minimum Wait: Delay + Conditional Exit Using Extended State Register Variable Counter

Programmable Wait State

• Explicit Top-Level States vs Programmable State
  • Explicit
    
  • Programmable
    

Thought Question

• Is it better to grow the state register or use a separate counter variable?
  • no simple universal answer

“For Loop” State Machine

• Extended-state registers can help implement loop behaviors
• Example: create outer loop with 10 iterations and inner loop with 5 iterations
  

Drawing Possible Hardware

Realizations of i,j registers and support hardware

• After examination of the state diagram, three required behaviors are desired: $\rm Hold$, $\rm Increment$ , $\rm Load\ 0$
• A primary FSM will generate the control signals

• Note $\rm i$ would be the output of the register, the output from the register could be called ($\rm i\_next$ , $\rm \_i$, $\rm i\_comb$, $\rm i\_int$, $\rm i\_prereg$)

class discussion: timing diagram

Combinatorial vs Sequential Pitfalls

• Wrongly using the output of a register instead of the input can be a pitfall when using single-always-block (registered outputs) and extended state registers

SA:
  i<=0; ...
SD:
   i <= i+1;
   if (i<10) CS<=SA;
    else CS<=SE;
   ….

SD:
  next_i = i+1;
  if (next_i<10) CS<=SA;
  else      CS<=SE;
  i <= next_i;
   ….

Tweaking Question ( a question asked in class)

• Could one just change i<10 to i<9?

SA:
  i<=0; ...
SD:
   i <= i+1;
   if (i<10) CS<=SA; 
   else CS<=SE;
    ….

SA:
  i<=0; ...
SD:
   i <= i+1;
   if (i<9) CS<=SA; 
   else CS<=SE;
    ….

• Perhaps yes, but the reasoning is important.
• Lets say you are working on a class HW project – if you make the wrong version, run a simulation or debug in FPGA hardware, notice that one extra loop is performed and “tweak” the code to “just make it work” without understand the options, than that would not be a good reason. You want to be cognizant of and understand the different choices, then you have the knowledge and understanding to select the most appropriate implementation. Furthermore, at some point your code will be very large and systems will be complex – expecting to make many tweaks is not a reliable approach. You want to learn to get as much right the first time as possible.
• I'd argue that the tweaked version is less readable, but I could not say it is wrong.

Detecting Signal Change in Single-Clock-Domain Synchronous Logic

• When looking for a change on an signal, avoid a careless temptation to “detect” edges using edge specifiers if it is not warranted to create a new clock domain. Ex:

  always @ (posedge e)
    e_counter <= e_counter + 1;
  

• Consider saving a previous version of the signal in a register, and using both present and previous input values to detect a transition:

always @ (posedge clk) begin
  if (~e_prev & e) e_counter <= e_counter + 1; 
  e_prev<=e;
end

which is the same as

always @ (posedge clk)begin
  e_prev<=e;
  if (~e_prev & e) e_counter <= e_counter + 1; 
end

One Reaction per Transition

Transition detection for statemachines

• To alter the behavior, a slave state machine can instead look for a change in the signal in two consecutive clock cycles

• Saving the previous input value:

           always @ (posedge clk) go_prev<=go;
  

• using a fresh high as a condition

           (go==1 && go_prev==0)
  

Global Exceptions

• Now, see what happens if a single new condition, a universal exception must be added.
• A dramatic result from only one new condition. Readability and perhaps feasibility of mentally managing the FSM is severely impacted.

Global exception in software

• A single if statement can be added, taking advantage of the hierarchy of logic embedded in code.

switch(current_state){
 case A: …
 case B: …
 case C: …
 case D: …
}

if (exception){
  do this
}else{
  switch(current_state){
   case A: …
   case B:
   case C:
   case D:
}

FSM Optimizations

• As we are designing Multi-Cycle computations, we may consider two
  optimizations:
  • Rescheduling – moving internal operations to other states
  • Resource sharing – utilizing same component in multiple states
• The following examples based on or borrowed from ꭝꭝ Thomas&Moorby

Module Header

module FSM_opt( 
    output reg [7:0] f,
    input clk,
    input wire [7:0] i,
    input wire [7:0] j,
    input wire [7:0] k,
    input rst     );

reg [7:0] CS;
reg [7:0] i_int,j_int,k_int;

localparam S_0 = 8'b00000000;
localparam S_1 = 8'b00000001;
localparam S_2 = 8'b00000010;

Module Body

always @ (posedge clk) begin
  if (rst) begin
    CS<=S_0;
    f<=0;
  end else begin
    case(CS)
      S_0: begin i_int<=i; 
                 j_int<=j;
                 k_int<=k;
                 CS<=S_1;       end        
      S_1: begin CS<=S_2;       end
      S_2: begin m=i_int*j_int;
                 f<=m*k_int; 
                 CS<=S_0;       end
    endcase
  end  
end
endmodule

• Multi-cycle computation:
  Note, the single-block style here was used since the state transition sequence is straightforward. Also, the data path is combined with the controller.
  We are not worried about “code bloat” from having to code each output on every transition.
  Instead of concentrating on
  timing coincidence of state and outputs
  vs
  coding coincidence of state and outputs,
  we are focused on the
  coincidence of states and computations. In this single block style the computation performed and resources required for each each are clear, though the corresponding output of each computation is seen and can be used on the cycle following the corresponding state indicated in the state register.

RTL suggested from Code

Only datapath connections shown, control and status signals are ommitted

Alternative RTL supporting higher clk rate

Rescheduling

always @ (posedge clk) begin
  if (rst) begin
    CS<=S_0;
    f<=0;
  end else begin
    case(CS)
      S_0: begin 
        i_int<=i; j_int<=j; k_int<=k;
        CS<=S_1;  end        
      S_1: begin
        m<=i_int*j_int;   //**to here**
        CS<=S_2;  end
      S_2: begin 
        //m=i_int*j_int;  //**move from here**
        f<=m\*k_int; 
        CS<=S_0;  end
    endcase
  end  
end
endmodule

Reference Computation Module for discussion

Head

module FSM_opt( 
    output reg [7:0] f,
    output reg [7:0] g,
    input clk,
    input wire [7:0] i,
    input wire [7:0] j,
    input wire [7:0] k,
    input rst
    );
reg [7:0] CS;
reg [7:0] i_int,j_int,k_int;

localparam S_0 = 8'b00000000;
localparam S_1 = 8'b00000001;
localparam S_2 = 8'b00000010;

Body

always @ (posedge clk) begin
  if (rst) begin
    CS<=S_0;
    f<=0;
    h<=0;
  end else begin
    case(CS)
      S_0: begin 
        i_int<=i;
        j_int<=j;
        k_int<=k;
        CS<=S_1;  end        
      S_1: begin
        CS<=S_2;  end
      S_2: begin 
        f<=i_int*j_int;
        h<=j_int*k_int; 
        CS<=S_0;  end
    endcase
  end  
end
endmodule

Suggested RTL

Alternative RTL with lower gate count

always @ (posedge clk) begin
  if (rst) begin
    f<=0; g<=0;
    CS<=S_0;
  end else begin
    case(CS)
      S_0: begin 
        i_int<=i;
        j_int<=j;
        k_int<=k;
        CS<=S_1;  end        
      S_1: begin

        CS<=S_2;  end
      S_2: begin 
        f<=i_int*j_int; //**
        g<=j_int*k_int; 
        CS<=S_0;  end
    endcase
  end  
end
endmodule

Explicitly coding the rescheduling so that only one multiply is performed per cycle is simple and seen in the next code. However, this doesn’t ensure resource sharing as shown in the figure with one a single multiplier.

Alt. Module Body

always @ (posedge clk) begin
 if (rst) begin
   f<=0; g<=0;
   CS<=S_0;
 end else begin
  case(CS)
   S_0: begin
    i_int<=i;
    j_int<=j;
    k_int<=k;
    CS<=S_1;  end
   S_1: begin
    f_int<=i_int*j_int; //**moved to here**//
    CS<=S_2;  end
   S_2: begin
    f<=f_int;   //*timed output load*//
    g<=k_int*j_int;
    CS<=S_0;  end
  endcase
 end  
end
endmodule

Resource Sharing

• Suggesting Resource Sharing guides the synthesizer to reuse hardware for operations at multiple places in the code
• The coding method depends on the synthesizer tool: the following code is more likely interpreted as resource sharing since the multiplier result is always written to the same variable

• Another option is to pull the multiplier out of the edge-triggered code and write logic explicitly for the multiplier, and use the state machine to change the inputs to the multiplier

Yet Another Rescheduling Example

Code Provided to the Synthesizer

input  [7:0] i,j,k;
output [7:0] f,h;
reg    [7:0] f,g,h,q,r,s;
always @ (posedge clk)
…
  case (CS) 
  S_0:begin[ f<=i+j; g<=j*23; CS<=S_1; end
  S_1:begin[ h<=f+k;          CS<=S_2; end
  S_2:begin[ f<=f*g; q<=r*s;  CS<=S_0; end
…

• FSM Synthesizers can automatically try variations:

  • Movement of q=r*s using a temporary variable:

    S_0:begin[ f<=i+j; g<=j*23;    CS<=S_1;  end
    S_1:begin[ h<=f+k; q_int<=r*s; CS<=S_2;  end
    S_2:begin[ f<=f*g; q<=q_int;   CS<=S_0;  end
    

  • Movement of f*g:

    S_0:begin[ f<=i+j;g<=j*23; CS<=S_1;  end
    S_1:begin[ h<=f+k;g<=f*g;  CS<=S_2;  end
    S_2:begin[ f<=g; q<=r*s;   CS<=S_0;  end
    

State Encodings

• Auto: In this mode, XST tries to select the best suited encoding algorithm for each FSM.
• One-Hot: One-hot encoding is the default encoding scheme. Its principle is to associate one code bit and also one flip-flop to each state. At a given clock cycle during operation, one and only one bit of the state variable is asserted. Only two bits toggle during a transition between two states. One-hot encoding is very appropriate with most FPGA targets where a large number of flip-flops are available. It is also a good alternative when trying to optimize speed or to reduce power dissipation.

• Gray: Gray encoding guarantees that only one bit switches between two consecutive states. It is appropriate for controllers exhibiting long paths without branching. In addition, this coding technique minimizes hazards and glitches. Very good results can be obtained when implementing the state register with T flip-flops.
• Compact: Compact encoding consists of minimizing the number of bits in the state variables and flip-flops. This technique is based on hypercube immersion. Compact encoding is appropriate when trying to optimize area.
• Johnson: Like Gray, Johnson encoding shows benefits with state machines containing long paths with no branching.

• Sequential: Sequential encoding consists of identifying long paths and applying successive radix two codes to the states on these paths. Next state equations are minimized.
• Speed1: Speed1 encoding is oriented for speed optimization. The number of bits for a state register depends on the particular FSM, but generally it is greater than the number of FSM states.
• User: In this mode, XST uses original encoding, specified in the HDL file. For example, if you use enumerated types for a state register, then in addition you can use the ENUM_ENCODING constraint to assign a specific binary value to each state. Please refer to "Design Constraints" chapter for more details.

• RAM-Based Finite State Machine (FSM) Synthesis: Large Finite State Machine (FSM) components can be made more compact and faster by implementing them in the block RAM resources provided in Virtex® devices and later technologies. FSM Style (FSM_STYLE) directs XST to use block RAM resources for FSMs.

Encoding Review

• One-hot encoding is good for speed and simplicity of state decoding logic and state incrementing.
• More compact codes such as standard binary encoding generally require a smaller state state register than one-hot encoding at the possible cost of size and speed.
  • But this depends on the density of combinatorial logic vs. registers the supporting HW platform and in the design.
  • FPGAs have many registers and so the cost of additional combinatorial logic may large compared to the savings from needing less registers.

• Codes where only one or two bits change at a time in the state register may be beneficial.
  • Less transitions may lead to less power depending on overall design, e.g. if stage register output connects to a high-capacitance load (high-fanout)
  • Can minimize the chance of metastability errors (such as systems with tight timing, or radiation vulnerability).
  • These codes may also minimize logic glitches.

FSM Log File

• The XST log file reports the full information of recognized Finite State Machine (FSM) components during the Macro Recognition step. Moreover, if you allow XST to choose the best encoding algorithm for your FSMs, it reports the one it chose for each FSM. \ As soon as encoding is selected, XST reports the original and final FSM encoding. If the target is an FPGA device, XST reports this encoding at the HDL Synthesis step. If the target is a CPLD device, then XST reports this encoding at the Low Level Optimization step.

Log File Example

Synthesizing Unit <fsm_1>.
Related source file is "/state_machines_1.vhd".
Found finite state machine <FSM_0> for signal <state>. 
------------------------------------------------------
| States         | 4                 |
| Transitions    | 5                 |
| Inputs         | 1                 |
| Outputs        | 4                 |
| Clock          | clk (rising_edge) |
| Reset          | reset (positive)  |
| Reset type     | asynchronous      |
| Reset State    | s1                |
| Power Up State | s1                |
| Encoding       | automatic         |
| Implementation | LUT               |
------------------------------------------------------
Found 1-bit register for signal <outp>.
Summary:
inferred 1 Finite State Machine(s).
inferred 1 D-type flip-flop(s).
Unit <fsm_1> synthesized.
========================================================

HDL Synthesis Report
Macro Statistics
# Registers : 1
1-bit register : 1
========================================================
========================================================
* Advanced HDL Synthesis *
========================================================
Advanced Registered AddSub inference ...
Analyzing FSM <FSM_0> for best encoding.
Optimizing FSM <state/FSM_0> on signal <state[1:2]> 
with gray encoding. 
-------------------
State | Encoding
-------------------
   s1 | 00
   s2 | 01
   s3 | 11
   s4 | 10
-------------------
=======================================================
HDL Synthesis Report
Macro Statistics
# FSMs : 1
=======================================================

Constraints/Compiler Directives

• Most synthesizers support various instructions to modify synthesis behavior
  • http://www.xilinx.com/itp/xilinx8/books/data/docs/xst/xst0064_8.html#wp255324
• Many options can be applied globally or on a per module instance or even per block level.
• Some are entered in constraint files, as a command-line option or inline via special commented tags:

• The comment below is an example of a synthesizer directive / inline-constraint:

  casex select // synthesis full_case
  4'b1xxx: res = data1;
  4'bx1xx: res = data2;
  4'bxx1x: res = data3;
  4'bxxx1: res = data4;