UPGRADE YOUR BROWSER

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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Participant advyxlnx
Participant
13,030 Views
Registered: ‎07-26-2014

state machine is not inferred in vivado, but inferred in synplify

Jump to solution

Q: state machine is not inferred in vivado, but inferred in synplify

At first, i use a two always block FSM coding style -- (state, state_next), vivado does not infer FSM.
I think vivado does not recognize this FSM coding style.
Then i use one always block FSM coding style --(state), as xilinx recommend in the templates.
But vivado does not infer FSM again. i didn't find message like "INFO: [Synth 8-802] inferred FSM for state register ..." in the report.

Then i use synplify pro, and i find that it can infer FSM. the report are as following:
    Extracted state machine for register state
    State machine has 7 reachable states with original encodings of:
        ......

i test the FSM example code in xilinx ug901, state machine can be inferred.


i use vivado 2013.4.


My question is :
1. Why vivado doesn't infer FSM ? What's the problem with the code blow ?
2. Does it matter if FSM isn't inferred if the module input/output work correct (to other module) ??

Part of my code are as following:


module fsm(
  input wire    clk,
  input wire    rst,
 
  input wire    es,
  input wire    ds,
  input wire    full,
  input wire    hd,
  input wire    ack,
  input wire    dd,
  input wire    ec,
 
  //...
 
  //output      ...
);


localparam  IDLE    = 5'b00000;
localparam  ONE     = 5'b00001;
localparam  TWO     = 5'b00010;
localparam  THREE   = 5'b00100;
localparam  FOUR    = 5'b01000;
localparam  FIVE    = 5'b10000;

 


reg  [5:0]                  state;
//reg  [6:0]                  state_nx;   //


always @(posedge clk) begin
    if (rst) begin
        state <= IDLE;
    end else begin
      case (state)
        IDLE : begin
            if (es) begin
                state <= THREE;
            end else if (ds) begin
                state <= ONE;
            end else begin
                state <= IDLE;
            end
        end
        
        ONE : begin
            if (hd) begin
                state <= TWO;
            end else begin
                state <= ONE;
            end
        end

        TWO : begin
            if (dd) begin
              if (!full) begin
                state <= THREE;
              end else begin
                state <= FIVE;
              end
            end else if (ack) begin
                state <= ONE;
            end else begin
                state <= TWO;
            end
        end

        FIVE : begin
            if (!full) begin
                state <= THREE;
            end else begin
                state <= FIVE;
            end
        end

        THREE : begin
            if (hd) begin
                state <= FOUR;
            end else begin
                state <= THREE;
            end
        end

        FOUR : begin
            if (ec) begin
                state <= IDLE;
            end else begin
                state <= FOUR;
            end
        end

        default : begin
            state <= IDLE;
        end
      endcase
    end
end

//output logic   
//      combinational + sequential


endmodule


I'm waiting for your help.

 

 

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
20,425 Views
Registered: ‎02-14-2014

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution

Hello,

 

In order to infer the FSM by Vivado synthesis tool, you need to write your RTL according to the HDL Coding Technique for state machine in UG901, I have modified your design and tested with Vivado 2014.2 (latest release) and I am able to get the below INFO messages in log file.

INFO: [Synth 8-802] inferred FSM for state register 'state_reg' in module 'sm'

INFO: [Synth 8-3354] encoded FSM with state register 'state_reg' using encoding 'one-hot' in module 'sm'

Please find the attached modified verilog file for your reference.

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
13 Replies
Xilinx Employee
Xilinx Employee
13,004 Views
Registered: ‎05-14-2008

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution

Sometimes there is no message like "INFO: [Synth 8-802] inferred FSM for state register ..." in the report when FSM inference is happening. Do you see a message like this?

INFO: [Synth 8-3898] No Re-encoding of one hot register 'state_reg' in module 'fsm_test'

This also indicates that the FSM is inforred. Please check the following AR:

http://www.xilinx.com/support/answers/59237.htm

 

If this is not the case in your project, please attach the complete .v file that can be used to reproduce the issue so that we can analyze the issue.

 

2. Does it matter if FSM isn't inferred if the module input/output work correct (to other module) ??

-As long as the function/timing/area is not a problem, it is ok not having FSM inferred.

 

-Vivian

 

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Teacher muzaffer
Teacher
12,995 Views
Registered: ‎03-31-2012

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution

a lot of conditions have a consequence whether a synthesis tool extracts a state machine from your code or not. The only reason this is important is when you want the synthesis tool to change your encoding (ie usually from binary coded to one hot). For functionality of the synthesized design whether the state machine was extracted (inferred) is immaterial/irrelevant. The synthesis tool is supposed to generate code which follows the RTL behavior and it is not important how it is done (as long as the generated logic meets timing after implementation but this is not usually problem with synthesis but the rtl code itself).

State machine inferrence is not like RAM (memory) inferrence. Not being able to infer ram may produce unimplementable logic (because it may need too many registers to fit) but state machines don't have that problem.

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
Participant advyxlnx
Participant
12,977 Views
Registered: ‎07-26-2014

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution

To viviany:

 

Thank you very much.

 

1. There are no message like "INFO: [Synth 8-3898] ...... " in the report too.

 
attach .v.

0 Kudos
Participant advyxlnx
Participant
12,976 Views
Registered: ‎07-26-2014

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution
to muzaffer:

Thank you very much.
Helpful.
0 Kudos
Xilinx Employee
Xilinx Employee
20,426 Views
Registered: ‎02-14-2014

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution

Hello,

 

In order to infer the FSM by Vivado synthesis tool, you need to write your RTL according to the HDL Coding Technique for state machine in UG901, I have modified your design and tested with Vivado 2014.2 (latest release) and I am able to get the below INFO messages in log file.

INFO: [Synth 8-802] inferred FSM for state register 'state_reg' in module 'sm'

INFO: [Synth 8-3354] encoded FSM with state register 'state_reg' using encoding 'one-hot' in module 'sm'

Please find the attached modified verilog file for your reference.

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Xilinx Employee
Xilinx Employee
12,925 Views
Registered: ‎02-14-2014

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution

Hello @advyxlnx ,

 

Are you still facing any issue with the design?

If the issue is solved, then feel free to mark the post as solution.

This is a good forum practice and will surely help others who will refer this post. 

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Visitor chiggs_pv
Visitor
12,601 Views
Registered: ‎08-25-2014

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution

Hi Ashish,

 

Your answer implies that Vivado does not support FSM inference unless the FSM is implemented as a single clocked process.

 

There is nothing in the UG901 that states this, bar the absence of any specific examples.  In fact Figure 4-4 "FSM With Three Processes Diagram" suggests that it is supported. This style is very common (see Aeroflex Gaisler) and sometimes recommended (see StackOverflow).

 

Could you file 2 CRs:

 

  1. Update the UG901 to explicitly state this deficiency in Vivado
  2. Implement support for two-process FSM in Vivado

 

Thanks,

 

Chris

0 Kudos
Historian
Historian
12,590 Views
Registered: ‎02-25-2008

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution

@chiggs_pv wrote:

 

There is nothing in the UG901 that states this, bar the absence of any specific examples.  In fact Figure 4-4 "FSM With Three Processes Diagram" suggests that it is supported. This style is very common (see Aeroflex Gaisler) and sometimes recommended (see StackOverflow).

 


The assertions about fewer lines of code, better timing and smaller area for the two-process machine are basically unsubstantiated. In fact, the comment about fewer lines of code can be shown to be **bleep**, because you have to have two processes, and you have to keep track of the current state of the state register as well as all of the signals you ultimately need to register.

 

How you get smaller area with the two-process machine is not clear.

 

Anyways, the two-process machine IS harder to maintain, and it IS much more likely to result in unintended latches, ESPECIALLY for a large machine. I don't understand at all about the "unintended flip-flop" point, because with a synchronous machine your outputs are ALWAYS registered.

 

The line about "See the next value of the flop before the clock in a waveform or display statement. With one always block you need to calculate the values" just tells people that you're a newbie and that you don't understand the delta delay concept.

----------------------------Yes, I do this for a living.
0 Kudos
Teacher muzaffer
Teacher
12,583 Views
Registered: ‎03-31-2012

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution
>> The line about "See the next value of the flop before the clock in a waveform or display statement. With one always block you need to calculate the values" just tells people that you're a newbie and that you don't understand the delta delay concept.


Actually there is something to this claim. In the schematic version of a design there are two different nets one connected to the Q output of the flop and one connected to D input of the flop. In single process, the latter is not named but in two process version it is.
- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Historian
Historian
7,365 Views
Registered: ‎02-25-2008

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution

@muzaffer wrote:
>> The line about "See the next value of the flop before the clock in a waveform or display statement. With one always block you need to calculate the values" just tells people that you're a newbie and that you don't understand the delta delay concept.


Actually there is something to this claim. In the schematic version of a design there are two different nets one connected to the Q output of the flop and one connected to D input of the flop. In single process, the latter is not named but in two process version it is.

Well, that's true, but who does state machines in a schematic format? And if you have a large machine, can you really understand what's going on by looking at the tools-generated schematic?

----------------------------Yes, I do this for a living.
0 Kudos
Teacher muzaffer
Teacher
7,360 Views
Registered: ‎03-31-2012

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution
It's just that with two process you know where you are AND where you will be when the clock hits. Sometimes it's useful to see it on a waveform (not very often, actually; these days I find myself writing code with a lot of monitors and assertions and looking at waveforms less; ie printf rules :-)
- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Visitor chiggs_pv
Visitor
7,349 Views
Registered: ‎08-25-2014

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution

@bassman69

 

The line about "See the next value of the flop before the clock in a waveform or display statement. With one always block you need to calculate the values" just tells people that you're a newbie and that you don't understand the delta delay concept.

 

I have no connection and do not know the person who wrote the post on StackOverflow, but I wouldn't accuse him of being a "newbie". Please avoid being rude here; if you're determined to argue then comment on directly to the author on that thread. This discussion isn't about the merits of single vs. two process state machines, which always evokes a religious argument (as you have so aptly demonstrated).  You'll also notice that I've not endorsed one or other style.

 

This thread is about Xilinx support for common synthesis constructs.  Regardless of whether you're a fan of the 2-process style or not there's plenty of code in the wild for which Xilinx will not correctly infer state machines encodings.  This is not made at all clear in the documentation.

 

Thanks,

 

Chris

0 Kudos
Explorer
Explorer
3,596 Views
Registered: ‎11-23-2009

Re: state machine is not inferred in vivado, but inferred in synplify

Jump to solution

@muzaffer

 

I'd like to comment on two statements

 

- The only reason this is important is when you want the synthesis tool to change your encoding (ie usually from binary coded to one hot)

This might be true for Verilog, but it is not for VHDL. In VHDL one very often uses an enumeration type for the state variable. So there is no apriori encoding, so the synthesis tool doesn't change an encoding, it has always to create an encoding. From observation I see that Vivado simply uses binary numbers in definition order, but I'm not sure whether that is always this way.

 

- For functionality of the synthesized design whether the state machine was extracted (inferred) is immaterial/irrelevant.

True, from a functional point of view this is true.

But from a performance point of view it clearly is not !

A larger fsm which is not inferred leads to sub-optimal timing. Simply because one gets a very complicated state transition logic, yielding high logic depth and thus bad timing. If such a fsm is properly inferred and one-hot encoding is used one gets instead for each state flop a small logic which is fast. That's why one-hot is used when performance is the goal.

0 Kudos