Lecture 08 – FSMD

• \(\dagger\) A Practical Introduction to Hardware Software Codesign Patrick Shaumont
• \(\dagger\)\(\dagger\) The Verilog® Hardware Description Language, Donald E. Thomas (Author), Philip R. Moorby (Author) ISBN:9781402070891 Amazon Link
  • Examples for rescheduling

• All Finite State Machines can be partitioned into a combinatorial and sequential parts
• Often these two pieces are coded in separate code blocks, but they may also be combined sometimes
• Note: some simple register-specific operations such a synchronous reset are coded in either the combination or the sequential blocks, but are often coded in the sequential block to indicate selection of register configuration. An asynchronous clear should be part of the sequential block.

module FSM (clk, clear, x,y);

input logic clk, clear;
input logic [2:0] x;
output logic [1:0] y;

// States
typedef enum int {S0,S1,S2} state_t;


// Declare current state and next state variables
state_t CS,NS;


always_ff @ (posedge CLOCK or posedge clear) begin
  if (clear == 1'b1) CS <= S1;
  else CS <= NS;
end

always_comb begin //always @ (CS, x)
  case (CS)
    S1 : begin
         y = {x[2] , ~x[1] && x[0]};
         if (x[2] && ~x[1] && x[0])
           NS = S2;
         else if (x[2] && x[1] && ~x[0])
           NS = S4;
         else
           NS = S1;
    end
    S2 : begin
         y = 2'b10;

    ...

• every output bit must be well-defined for every case and input to avoid latches
• for NS, every output bit is set in every case to avoid latches

reg [7:0] CS,NS; //reg!=register
localparam S_init    = 8'b00000000;
localparam S_start0 = 8'b00000001;
localparam S_start1 = 8'b00000010;

replaced by

enum int {S_init, S_start0,S_start1} state_t;
state_t CS,NS;

• meaningful enum symbols displayed in waveform viewers and loggers

• Symbol accessed as string through member function:

  $strobe("State %s %0d",CS.name(),CS);
  

• use of enum int and avoiding explicit encodings avoid confusion of automatic encoding which would replace values provided with localparam

🛰️ Registered Output FSM

• Good for describing common synchronous digital logic building blocks like counters with an output that is updated once per cycle
• Predictable System Timing
  • Consistent Design and Build Unit with combinatorial delay and terminated with registers that output once per cycle
  • consistent with design stages of pipeline/RTL
  • Standardizes delay constraints for blocks (avoid creating long combinatorial paths through multiple blocks)
• Avoid Glitches
  • critical for generating edge-sensitive control signals
  • may achieve lower-power operation by avoiding charge/discharge cycles especially when driving off-chip loads
• Mitigate Metastability
  • unfortunate timing downstream, causing invalid voltage levels or late transitions
• Adds clk cycle delay to outputs

• Additionally, code can reuse previous outputs for future output and state updates, meaning the new registers are part of the state of the system
• In code, you can update outputs as needed in a given state and retain values by default if not assigned

• ✏️ Note Formal Size of State Considering any output logic register to be part of the state (serving as "extended state register"), a "Registered Output Mealy" machine is technically a Moore Machine

always_ff @ (posedge CLOCK or posedge CLEAR) begin: FSM
  logic _temp;

  if (CLEAR == 1'b1) begin
    CS <= S1;
  end else begin 
    case (CS) 
      S1 : begin 
        _temp = ~x[1];                     //intermediate logic (blocking assignment)
        y  <= {x[2] , _temp & x[0]};       //register intent (non-blocking assignment)
        if (x[2] && _temp && x[0])  
          CS <= S2;                        //register intent (non-blocking assignment)
        else if (x[2] && x[1] && ~x[0]) 
          CS <= S4; 
        else 
          CS <= S1;
      end
      S2 : begin 
          y  <= {x[1] && ~x[1] , x[0]};   
         . 
         . 
         . 

• Embedded combination circuit signal assignments ended with blocking assignment and thus encode "immediate" effect. All consumers of blocking assignment results should be within this code block. Even within the block, no consumer should rely on a value assigned from a blocking statement in a previous trigger event.
• Remember, any variable written to inside an edge-triggered block can become a register regardless of the use of blocking or non-blocking…consider every output variable, combinational and sequential, in every case and branch of decision tree and make sure assignments are always made to avoid latches

🛰️ Registered Output and Three-Always Block

• Registered output can cause “cycle delays” so some output transitions need to be coded along with the state transition into a state rather than with the state they are supposed to coincide with (discuss output on prev. slide)
• Sometimes this feels like you’re coding outputs in the “previous state” or coding output ahead of time to account for register delay. I refer to it as coding the output along with the state transition it coincides with. This leads to additional lines of code as you need to code each output logic possibly for every transition to a state rather than once per state
• To avoid this “code bloat”, yet another approach is to code the registered outputs in a separate block. This leads to three blocks:
  • Combinatorial Next State Logic along with any combinatorial outputs
  • Sequential State Register
  • Sequential Registered Outputs according to the destination (next) state from the combinatorial Block.
• Good contrasting examples can be found here: http://www.sunburst-design.com/papers/CummingsSNUG2003SJ_SystemVerilogFSM.pdf

Avoids delays while allowing registered outputs to be coded with the state they are intended to coincided with, by coding Next State and Output for Next state together.

• Primary State Register

  always(posedge clk) begin
     if reset …
     else CS<=NS;
  end
  

• Next State Logic and Any combinatorial outputs

  always_comb begin
   NS=CS;   /*NS is result of combinatorial logic */   
   case(CS)
     S_init: begin 
       if (go==1 && selAB==0) NS=S_startA;
       ...
     end;
     S_startA: begin
       NS=S_init; 
     end;
  …
  

• Next State Registered Output Logic Coded Once Per State Rather than once per transition

  • May optionally include Transition-specific output rules based on both CS and NS

    always(posedge clk) begin
       case(NS)
       S_init: begin 
         goA<=0;
       end;
       S_startA: begin
         goA<=1;
       end;
    …
    end
    

• Assume slave need a start signal for two clock cycles
• Using more states simplifies output logic

• Using fewer states requires more output logic and, in the code shown effectively embeds extended state information in additional registers

Place holder for in-class timing diagram. Key concepts: * Identification of implied combinatorial signals including register inputs (outputs and state (NS)) * Arrival of input changes versus response timing * Coincidence of Code and Output Timing

module control_with_state_machine2(
   input logic clk,
   input logic rst,
   output logic startA, //start signal to slave A
   output logic startB, //start signal to slave B
   input logic busyA_n,     //busy signal from slave A
   input logic busyB_n,     //busy signal from slave B
   output logic ready,      //ready signal to master
   input logic selAnB       //go signal from master
   input logic start        //go signal from master
);

enum int {S_init, S_start0,S_start1} state_t
state_t CS,NS;

assign ready = ~(selAnB?busyB_n:busyA_n); // extra combinational logic outside state machine

  always_ff @ (posedge clk) begin
    if (rst == 1)
      CS<=S_init;
    else
      CS<=NS;
  end

  always_comb begin
     NS = CS;
     case (CS)
    S_init: begin
       if (go) begin
          NS = S_start0;
       end
    end
    S_start0:
      NS = S_start1;
    S_start1:
      NS = S_init;
      endcase
  end

  always_ff @ (posedge clk) begin
     case (NS)
       S_init:
         startA <= 0;   
         startB <= 0;   
       S_start0:
         startA <= ~selAnB;
         startB <= selAnB;
       S_start1:
         startA <= startA;  
         startB <= startB;  
      endcase
  end


endmodule

• also need to consider appropriate resets and defaults logic

• Characterized by
  • A set of states
  • A set of inputs and outputs
  • A state transition function
  • An output function
• Hardware Implementation
  • Current State held in a register
  • Any additional status information held in status register
  • Next-State and State Control Logic Determines next state and control signals based on registers
  • Datapath implements operations on data under control of sate control logic

• A very common framework being described and implemented is a Finite State Machine with a Datapath: a data path controlled by signals from a FSM

• If available customizable hardware is fast, and control logic is difficult to describe, a good mix can be software for control and hardware for calculations. We will see later approaches that use a general purpose processor for control.

• Datapath operations can be encoded within the same procedural code as the state machine description or can be built separately.
• First consider partitioning.
  • Datapath: Identify elements in the datapath from experience with traditional digital systems (e.g. communications modules, arithmetic modules, multiplexer's and demultiplexers, registers and multi-word buffers, FIFOs, IP Cores etc…).
    
  • Control: Identify the control signals required and the status/condition information required to make decisions on the control.
• Datapath operations can be encoded in the state machine description or can be build separately.
  • If pre-built modules are used, as is common, the datapath is necessarily a separate description.
  • Often the datapath represents the algorithm calculations, separating the datapath code makes the code more readable
  • Coding datapath separately can allow more explicit influence over and insight into the resources used for computation while separating details of control code
  • Can sometimes think of datapath as implementing instructions for the controller to invoke/call
  • Separating the datapath code can allow better reuse under a different scheduling of operations (implementing a different algorithm)
  • In general, designing the datapath first and then the control is a good strategy

• 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 in each final state case
• registered outputs in general must coded once per transition, though the existence of one common default may save some lines of code

always @ (posedge clk) begin

//defaults
CS<=failed;
found<=0; done<=0;

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
  ...

• Alternative "3-block style" with output logic coded with use of next state NS

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

case(CS)
  S0: begin
     dx <= x1-x0;
     busy<= 1;
  end
  S1: begin
     dx <= y1-y0;
  end
  S2: begin
     dxSq <= dx*dx;
  end
  S3: begin
     dySq <= dy*dy;
  end
  S4: begin
     dsq <= dxSq+dySq;
     busy<= 0;
  end
endcase

• Encoding datapath operations WITHIN in the statemachine description, along with the controller rather than in a separate code block, is common
• It is common to see "algorithmic" statemachines described with control and computation embedded in the same procedural block. These can be modules which perform complex computations over multiple cycles and require internal working registers/memory
• We'll first focus on control state machines first, with an emphasis on timing and external status and control signals then discuss computational statemachines

• Data-Flow Graphs represents dependencies among operations in the process of an arithmetic algorithm (more compact than a full state diagram).
• A algorithmic state machine performs one or more operations in a state (i.e. clock cycle) while satisfying the required order dependencies from the graph

• Exercise: Draw the Datapath and Identify Status and Control as well as Pre-Register data names

case(CS)
  S0: begin
     dx <= x1-x0;
     busy<= 1;
  end
  S1: begin
     dx <= y1-y0;
  end
  S2: begin
     dxSq <= dx*dx;
  end
  S3: begin
     dySq <= dy*dy;
  end
  S4: begin
     dsq <= dxSq+dySq;
     busy<= 0;
  end
endcase

• At times we'll want to include an extra register to store information that we don't want to code as part of our primary state register.
  • Examples:
    • partial results in the process of a multi-cycle computation
    • saved results to provide at the output ports at a later time
    • status flags for events that should be remembered and used in later processing and state decisions
    • event counters
    • timing counters, to control timing without creating additional states
• These extended state registers are not necessarily represented by the number of drawn states state transition diagram or the primary coded state register, but formally they ARE part of the state of the system
• Note the explicit state register and the additional extended state registers
  • Note that the output and status can be based one or more of the input, NS, and other state registers.

• Logic based on only the current state groups updates based on the current/source state, e.g. describes all output independently of transition away from the current state

case (CS)
  S0: begin flag=0; end //unconditional, combinational output in S0
  S1: begin flag=1; end

• Including the input signals makes the output/update also input-dependant

case (CS)
  S0: begin 
    if (in==0) 
      flag=0;   //conditional, combinational output while in S0,
                //  updates immediately with input change
    else
      flag=1;   //conditional, combinational output while in S0,
                //  updates immediately with input change
    end 
  S1: begin flag=1; end

• Including NS as a dependency selects edges based on the destination state. Note that NS itself may depend on the input. This is useful if complex parts of the output logic have already been capture in the NS logic description.

case (CS)
  S0: begin 
    if (NS==S3) 
      flag=0;   //conditional, combinational output while in S0,
                //  updates immediately with input change through immediate NS change
    else
      flag=1;   //conditional, combinational output while in S0,
                //  updates immediately with input change through immediate NS change
    end 
  S1: begin flag=1; end

• Using a root case statement based on NS tends to organize updates based on the destination state (transitions into state). This is useful for registered output logic.

case (NS)
  S0: begin flag=0; end // combinational output, update seen immediately
                        // with input update that selects destination state S0
  S1: begin flag=1; end 

case (NS)
  S0: begin 
    if (CS==S3)   
      flag=0;          // combinational output, update applied immediately
                       // with input update that selects destination state S0
                       // applies only if current state is S3  
    else
      flag=1;
    end 
  S1: begin flag=1; end

• Using NS useful for registered output logic.

  always @ (posedge clk) begin
    case (NS)
      S0: begin flag<=0; end //glitch-free update when CS becomes S0
      S1: begin flag<=1; end //glitch-free update when CS becomes S1
  

One of the advantages of registered output design is in design partitioning and addressing the timing of a design within each partition.

Registered Ouput Modules:

Assembled Registered Ouput Modules: * Length of Combinatorial Paths are matched to those in the partitions

Irregular Modules:

Assembled Irregular Modules:

• Length of paths is determined by factors across partitions
• Logic Optimizer and designer therefore have different perspectives of the design
• Output path has under-specified timing constraint that may need to account for delays of output
  

• Improper assembly with combinational outputs can create combinational loops, whereas having all module output be registers avoids this.

  

• counter:
• counter time unraveled:
• counter with reset, used to count 0-17:
  
• controller used to implement counting 0-17:
• incorrect implementation and integration of controller with registered outputs:
  
• hack using prediction:
  • hack changing 17 to 16 implies that in the control FSM there is some predictive model of system 1's transition to the actionable state
  • not all systems interfaced and controlled are so easilty predictable
    
• use of combinatorial interface to provide in-cycle control decision
• integration as one fsm with registered outputs

• Control FSM are commonly required to implement timing based on cycles, reading of status signals in particular cycles, and generating control signals at the appropriate time

Many issues will arise in using systems that operate at different speeds, or don't operate in a predetermined fixed timing

Most generally

• the master may assert a request until it is acknowledged
• commonly, if a request and an ack are asserted in the same cycle, then it is assume that the data is consumed

• for reading (e.g. results) the master may wait until a result is ready to read a response
  • a separate flag like done or data valid (presented for consumption) is common for this

• It is common to require one or both of
  • conditional waiting (wait for condition)
  • unconditional waiting
• These can be used to implement
  • Fixed waiting
    • wait a predetermined number of cycles
    • no condition
  • Minimum wait (Fixed+Conditional)
    • wait for some fix time and
    • then wait for a condition based on external input to be satisfied. This is useful when interfacing with external "slow" entities that need time after being signaled to send back a response.

Explicit Top-Level States vs Programmable State

• Explicit

  

• Programmable using embedded state registers

  

• Is it better to grow the state register or use a separate counter variable?
  • no simple universal answer
• Specific Example Delay/Pause/Waiting:
  • Think about the delay examples given earlier using a counter. The counter was implementing one form of hierarchical states.
  • Consider waiting for an acknowledgment signal for \(2^{20}\) clock cycles. This would require ~1 Millon states with the condition to move to the next state or proceed to end state if acknowledge was received.

• Extended-state registers can help implement loop behaviors

• Example: create outer loop with 10 iterations and inner loop with 5 iterations

  

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\))

• 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;
   ….

• 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 and better presentation of coder's intent should be considered. This may produce the correct hardware, but it is an improper presentation of coder's design intent.
• 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 such tweaks is not a reasonable approach. You want to aim for as much to be correct as possible the first time.

• 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

• A slave state machine can use multiple states to analyze signals and examine changes

(on-board)

• FSM typically lack any hierarchy. There is no way to connect details of state-machines leading to state explosion. Otherwise, a hierarchy of states is quite useful for organizing an algorithm.
• No run-time reconfiguration: The rigid implementation of hardware and the limited representation of FSMs do not make it very flexible model, especially if one considers run-time flexibility (state diagram is fixed and doesn't change based on MODE, etc…)

<!--https://www.xilinx.com/content/dam/xilinx/support/documents/university/Vivado-Teaching/HDL-Design/2015x/Verilog/docs-pdf/lab11.pdf–>

An introduction to informal ASM Diagrams ** ASM Chart Elements

• State Box
  • State Name (required)
  • State Encoding (optional)
  • Register Updates (denoted with <=)
  • Moore Machine Output Updates (combinational logic)
• Conditional Rounded Box
  • Register Updates (optional, denoted with <=)
  • Mealy Machine Output Updates (optional, combinational logic)
• Decision Diamond
  • Test Condition
  • Exit Paths
    • Two for if
    • two or more for case

• General Notes:
  • Well-defined initial state, such as single entry point with actionless path to one initial state
  • Multiple exit paths may exist
  • Note that registers may only be updated once per clock cycle,
    • Improper to represent multiple updates in one cycle
  • Commonly outputs are written just by name (rather than out=1), and it is assumed the unspecified outputs default to 0

Example Euclid GCD:

function gcd(a, b)
    while (a != b) 
        if a > b
            a = a − b
        else
            b = b − a
    return a

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

• 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

module fsm(f,g,i,j,k,rst,clk);
input [7:0] i,j,k;
output reg [7:0] f,g;
input rst,clk;
reg [3:0] CS;
localparam S_0=0,S_1=1,S_2=2;

always @ (posedge clk) begin:named
 reg [7:0] i_int,j_int,k_int,f_int;
 reg [7:0] mult_out;
 mult_out = 8'bx;
 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
    mult_out = i_int*j_int;
    f_int <= mult_out;
    CS<=S_2;
   end
   S_2: begin
    f <= f_int;
    mult_out = k_int*j_int;
    g    <= mult_out;
    CS<=S_0;
   end
  endcase
 end  
end
endmodule

Multiplier input controlled using an explicit mux in the datapath:

module fsm(f,g,i,j,k,rst,clk);
input [7:0] i,j,k;
output reg [7:0] f,g;
input rst,clk;
reg [3:0] CS;
localparam S_0=0,S_1=1,S_2=2;

wire mult_a_sel;
wire [7:0] mult_out,mult_a,mult_b;
assign mult_out=mult_a * mult_b;
assign mult_a=mult_a_sel?k_int:i_int;
assign mult_b=j_int;


always @ (posedge clk) begin:named1
  i_int<=_i_int;
  j_int<=_j_int;
  f_int<=_k_int;
  f_int<=_f_int;
  g<=_g;
  f<=_f;
  CS<=NS;
end

always_comb begin:named2
 reg [7:0] i_int,j_int,k_int,f_int;
 if (rst) begin
  _i_int=8'bx;
  _j_int=8'bx;
  _k_int=8'bx;
  _f_int=8'bx;
  _g=0;
  _f=0;
  NS=S_0;
  mult_a_sel=1'bx;
 end else begin
  _i_int=i_int; 
  _j_int=j_int;
  _k_int=i_int;
  _f_int=f_int;
  _g=g;
  _f=f;
  mult_a_sel=1'bx;
  case(CS)
   S_0: begin
    _i_int=i;
    _j_int=j;
    _k_int=k;
    NS=S_1;
   end
   S_1: begin
    mult_a_sel=0;
    _f_int=mult_out;
    NS=S_2;
   end
   S_2: begin
    _f=f_int;   
    mult_a_sel=1;
    _g=mult_out;
    NS=S_0;
   end
  endcase
 end  
end
endmodule

• Another variation with the mux logic embedded within the state machine

Multiplier input controlled using an implied mux in the datapath, requires that data to be passed through the statemachine description block:

module fsm(f,g,i,j,k,rst,clk);
input [7:0] i,j,k;
output reg [7:0] f,g;
input rst,clk;
reg [3:0] CS;
localparam S_0=0,S_1=1,S_2=2;

reg mult_a_sel; //** now reg instead of wire
wire [7:0] mult_out,mult_a,mult_b;
assign mult_out=mult_a * mult_b;
assign mult_b=j_int;


always @ (posedge clk) begin:named1
  i_int<=_i_int;
  j_int<=_j_int;
  f_int<=_k_int;
  f_int<=_f_int;
  g<=_g;
  f<=_f;
  CS<=NS;
end

always_comb begin:named2
 reg [7:0] i_int,j_int,k_int,f_int;
 if (rst) begin
  _i_int=8'bx;
  _j_int=8'bx;
  _k_int=8'bx;
  _f_int=8'bx;
  _g=0;
  _f=0;
  NS=S_0;
  mult_a=1'bx;
 end else begin
  _i_int=i_int; 
  _j_int=j_int;
  _k_int=i_int;
  _f_int=f_int;
  _g=g;
  _f=f;
  mult_a_sel=1'bx;
  case(CS)
   S_0: begin
    _i_int=i;
    _j_int=j;
    _k_int=k;
    NS=S_1;
   end
   S_1: begin
    mult_a=i_int;
    _f_int=mult_out;
    NS=S_2;
   end
   S_2: begin
    _f=f_int;   
    mult_a=k_int;
    _g=mult_out;
    NS=S_0;
   end
  endcase
 end  
end
endmodule