We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Visitor davidbart
Registered: ‎02-21-2015

FSM extraction

I noticed Vivado wasnt recognizing my FSMs. So I setup a test by using the Vivado Language Template for the Moore State Machine.The only changes I made were global replacements of anything in the template with <> and to remove comment lines. 


However, I do not believe Vivado is recognizining this langauage template as an FSM either. I have tried setting the synthesis settings for fsm_extraction to both auto and one hot but neither seems to impact the recognition. Even if one hot is chosen there are two state registers generated not three as I would expect for onehot encoding with 3 states. Also, there is no message in the log about encoding, fsm, extraction ,etc. except for the one message that I believe confirms the setting is being applied:


# synth_design -top SimpleTest -part xc7z010clg400-1 -fsm_extraction one_hot
Command: synth_design -top SimpleTest -part xc7z010clg400-1 -fsm_extraction one_hot




I pasted the code below. I would really appreciate if anyone can suggets something I am missing here. Feel like I must be overlooking something simple. I am using Vivado 2014.4





library IEEE;


entity SimpleTest is
Port ( clk : in STD_LOGIC;
     rst : in std_logic;
     input_1 : in std_logic;
     input_2 : in std_logic;
     output : out std_logic);
end SimpleTest;


architecture behavioral of SimpleTest is

type state_type is (st1_stateOne, st2_stateTwo,st3_stateThree);
signal state, next_state : state_type;

--Declare internal signals for all outputs of the state-machine
signal output_i : std_logic; -- example output signal


SYNC_PROC: process (clk)
     if (clk'event and clk = '1') then
          if (rst = '1') then
               state <= st1_stateOne;
               output <= '0';
               state <= next_state;
               output <= output_i;
          end if;
     end if;
end process;

--MOORE State-Machine - Outputs based on state only
OUTPUT_DECODE: process (state)
     if state = st3_stateThree then
          output_i <= '1';
          output_i <= '0';
     end if;
end process;


NEXT_STATE_DECODE: process (state, input_1, input_2)
next_state <= state; --default is to stay in current state
case (state) is
     when st1_stateOne=>
          if input_1 = '1' then
               next_state <= st2_stateTwo;
          end if;
     when st2_stateTwo =>
          if input_2 = '1' then
               next_state <= st3_stateThree;
          end if;
     when st3_stateThree =>
          next_state <= st1_stateOne;
     when others =>
          next_state <= st1_stateOne;
     end case;
end process;


end behavioral;

Tags (3)
0 Kudos
4 Replies
Registered: ‎11-23-2009

Re: FSM extraction

Hi @davidbart,


There are two traps for FSM inference known to me:

  1. don't initialize the 'next_state' signal (see posting)

  2. be carefull with 'next_state <= current_state' as default (see posting)


The example fsm of the second issue has 3 states. When one of the fixup statements is un-commented and the logic is properly created no "INFO: [Synth 8-802] inferred FSM for state register" is generated.


From this and other cases I get the impression that Vivado doesn't bother about FSMs with three or less states. So your example might simply be too small. Add two states and you should see a "INFO: [Synth 8-802]".




0 Kudos
Xilinx Employee
Xilinx Employee
Registered: ‎07-21-2014

Re: FSM extraction

Hi @davidbart


By default FSM extration threshold is set to 5. From your design, it seems that you have only three states.

You need to change this default value using the param discussed in following AR.




Try to search answer for your issue in forums or xilinx user guides before you post a new thread.

Kindly note- Please mark the Answer as "Accept as solution" if information provided solves your query.
Give Kudos (star provided in right) to a post which you think is helpful and reply oriented.
Registered: ‎07-15-2015

Re: FSM extraction

Yep, that's mostly it:


set_param synth.elaboration.rodinMoreOptions {rt::set_parameter minFsmStates 3}


I figure since an FSM with two states only requires one flip-flop and is borderline trivial, setting the parameter to 3 is a good balance for automatically finding FSMs.


However, if you have an FSM with only two states but really complex logic for transitioning between them, you still might want the tool to flag it, in case you need to do further verification on its implementation.


By the way, I've been looking for something like a report_fsm command to facilitate reporting of state registers, state encoding values, and "safe" attributes, but haven't found anything useful yet. Is there such a command?


I have noticed that when an FSM is detected and extracted, the state register names in the implemented netlist will be different than the original names; i.e., they get prepended with a string like FSM_hamming2 (or the name of whatever encoding is used), so you can search for cells with that string using get_cells -hier *FSM* ...


And that safe encodings may generate additional flip-flops in your state register.


These obviously add robustness, but I wonder if the additional flop(s) and names changes will be problematic in gate-level simulations and formal (LEC) comparisons...


0 Kudos
Registered: ‎11-23-2009

Re: FSM extraction

Hi @aher


thanks for the very helpful answer !!


Two remarks at this point:

  • However, there must be more than a simple 'number of states' cut. An interesting case is the example in the posting on spurious iSTATE generation. The example FSM has only three states. Easy to figure out when an enumerated type is used. Nevertheless vivado infers this FSM, and even adds a spurious state. How comes when FSMs with 4 or less states aren't touched and synthesized 'as is logic' ?
  • on the other end of the spectrum I've a large FSM with is inferred, but not re-coded (see posting).

So there are small FSM which by default shouldn't be inferred, but are (even in a questionable manner).

And there are large FSMs which are inferred, but not re-coded, which defies the purpose of FSM extraction.


Any deeper insight on this is highly welcome.

With best regards, Walter


0 Kudos