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
Scholar mistercoffee
Scholar
12,730 Views
Registered: ‎04-04-2014

Rules for inferring FSM in Vivado

Hi,

 

I am porting over an ISE project to Vivado and have found that some of the FSMs that were inferred withe ISE are not inferred in vivado. I am trying to determine why and I am struggling to find information on what the rules are that determine whether vivado will infer an FSM.

 

Some of the code is mine, some from a former employee. Either way, I am trying to spot reasons why some are inferred and some not by comparing code. Some possible reasons may be:

- Using if-else rather than a case statement in the state process

- Not using enumerated states

- Having the FSM spread over two processes with a next state reg and acurrent state reg. One process is for assigning to a next state reg and one for assigning the next state to the current state (or a default state if in reset). I'm not that keen on this method, I prefer a single current state reg.

 

Before I plough on and rewrite FSM code that already worked can anyone give me a heads up as to which of these approaches might be the reason?

 

Thanks

Tags (3)
0 Kudos
21 Replies
Xilinx Employee
Xilinx Employee
12,728 Views
Registered: ‎02-14-2014

Re: Rules for inferring FSM in Vivado

Hello,

Please check UG901 page no136 for FSM Coding Examples
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_4/ug901-vivado-synthesis.pdf
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
Scholar mistercoffee
Scholar
12,721 Views
Registered: ‎04-04-2014

Re: Rules for inferring FSM in Vivado

Yes, I had meant to say I had read that part of UG901. It does give an example, which I would use as a basis for future designs, but it doesn't say what the rules are for determining whether an FSM is inferred, or why mine aren't. If I only need to change something simple to make it work I would prefer that to rewriting the whole state machine to match the example exactly.

 

Thanks

0 Kudos
Scholar mistercoffee
Scholar
12,371 Views
Registered: ‎04-04-2014

Re: Rules for inferring FSM in Vivado

I have some useful information.

 

I had an FSM not inferred. The state register was an integer, as follows, with the state names enumerated.

 

constant STATE_0  integer := 0;

constant STATE_1: integer := 1;

constant STATE_2: integer := 2;

constant STATE_3: integer := 3;

 

signal state: integer := STATE_0;

 

I then changed the state to a user defined type:

 

type state_type is(

STATE_0,

STATE_1,

STATE_2,

STATE_3

)

 

signal state: state_type := STATE_0;

 

Making this change allowed the FSM to be inferred by Vivado. Both versions worked in Planahead. 

 

But, I have another FSM which I cannot get to be inferred. I have stripped it back (to the point where it doesn't work as intended, but this is a test...) to a single clocked process, with a reset, with the state defined as above, and it will not infer. 

 

I am confused by P134-135 in UG901 too. Should I ensure a single clocked process, or can I have 3 process, as per Figure 3-3?

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

Re: Rules for inferring FSM in Vivado


@mistercoffee wrote:

I have some useful information.

 

I had an FSM not inferred. The state register was an integer, as follows, with the state names enumerated.

 

constant STATE_0  integer := 0;

constant STATE_1: integer := 1;

constant STATE_2: integer := 2;

constant STATE_3: integer := 3;

 

signal state: integer := STATE_0;

 

I then changed the state to a user defined type:

 

type state_type is(

STATE_0,

STATE_1,

STATE_2,

STATE_3

)

 

signal state: state_type := STATE_0;

 

Making this change allowed the FSM to be inferred by Vivado. Both versions worked in Planahead. 


it is the standard idiom to use a defined type enumeration for your states rather than explicitly defining the states with constants and declaring the state register as an integer. (And especially as a non-ranged integer, which is 32 bits!)


But, I have another FSM which I cannot get to be inferred. I have stripped it back (to the point where it doesn't work as intended, but this is a test...) to a single clocked process, with a reset, with the state defined as above, and it will not infer. 


Without seeing the code, who can guess?


I am confused by P134-135 in UG901 too. Should I ensure a single clocked process, or can I have 3 process, as per Figure 3-3?


Never do a three-process state machine. That's just a stupid way to do things.

----------------------------Yes, I do this for a living.
0 Kudos
Scholar mistercoffee
Scholar
12,313 Views
Registered: ‎04-04-2014

Re: Rules for inferring FSM in Vivado

Agreed, I wouldn't have a 3 process state machine either, hence my confusion with the document figure which is called "FSM with Three Process Diagram", which no explanation to go with it. You can see why people might be led astray, no? If it is not recommended why the diagram is there at all?

 

I would also use type enumerated states but was again confused as ISE managed to infer an FSM from the older version with integer constants defined. 

 

What I am really looking for is a set of design rules for FSMs in Vivado. Yes, I know there is an example, but that isn't the same thing. It doesn't say "this is the only way you can do an FSM in Vivado", it is an example and you could imagine slight variations on this which may or may not work. If you are going to be stricter on rules compared to ISE then please say what has changed!

 

Thanks

 

0 Kudos
Scholar mistercoffee
Scholar
12,307 Views
Registered: ‎04-04-2014

Re: Rules for inferring FSM in Vivado

Without seeing the code, who can guess?

 

Guess what? Did I ask a question? The quote you refer to is a statement, not a question. I know that if I wanted to know why that specific test wasn't working I would need to provide the code, but I wasn't asking that. I am asking for a more generic set of rules for Vivado FSM inference, not for you to fix one example for me.

 

 

 

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

Re: Rules for inferring FSM in Vivado


@mistercoffee wrote:

Without seeing the code, who can guess?

 

Guess what? Did I ask a question? The quote you refer to is a statement, not a question. I know that if I wanted to know why that specific test wasn't working I would need to provide the code, but I wasn't asking that. I am asking for a more generic set of rules for Vivado FSM inference, not for you to fix one example for me.


For the record, you said in the post to which I replied, "But, I have another FSM which I cannot get to be inferred. I have stripped it back (to the point where it doesn't work as intended, but this is a test...) to a single clocked process, with a reset, with the state defined as above, and it will not infer."

 

And it was that code which I asked to see. 

 

Now, to be honest, I have not had the tools refuse to infer an FSM in quite a long time. I have not used Vivado, so there might be some pernicious bug in that tool.

 

I always use the standard idiom of the single clocked process and an enumerated type for the state register. All inputs to the machine are synchronous with it (although that's to prevent machine failures, and not really about getting the tools to infer it). Now, it sounds like you are doing the right thing, but something else may be going on.

 

 

----------------------------Yes, I do this for a living.
0 Kudos
Scholar mistercoffee
Scholar
12,257 Views
Registered: ‎04-04-2014

Re: Rules for inferring FSM in Vivado

It could be a bug but it could also easily be something in my code. I'm a little tied up with something else but when I can I will isolate a simple example that I can't get to infer I will post it.

 

I wouldn't write the FSMs in question now in this way but I also don't want to rip it up and start again as we are only trying to port a semmingly stable design. So far, the simple changes I have made ahven't allowed it to infer.

 

I will keep you posted when I have something.

0 Kudos
Visitor chiggs_pv
Visitor
12,041 Views
Registered: ‎08-25-2014

Re: Rules for inferring FSM in Vivado


@mistercoffee wrote:

- Having the FSM spread over two processes with a next state reg and acurrent state reg. <snip>

 

Before I plough on and rewrite FSM code that already worked can anyone give me a heads up as to which of these approaches might be the reason?


 

 

A two process state machine won't be recognised as an FSM in Vivado, although this isn't documented anywhere.

 

See this thread: http://forums.xilinx.com/t5/Synthesis/state-machine-is-not-inferred-in-vivado-but-inferred-in-synplify/m-p/495820

0 Kudos
Scholar markcurry
Scholar
11,028 Views
Registered: ‎09-16-2009

Re: Rules for inferring FSM in Vivado


@chiggs_pv wrote:

 

A two process state machine won't be recognised as an FSM in Vivado, although this isn't documented anywhere.

 

See this thread: http://forums.xilinx.com/t5/Synthesis/state-machine-is-not-inferred-in-vivado-but-inferred-in-synplify/m-p/495820


 

That's not true, and I don't think that's what's indicated in that thread.  All my FSMs are two process.  Vivado recognizes them just fine.  Not that I really care if it does or doesn't infer a FSM and/or re-encode my states.  My FSMs don't look quite like the examples in the above thread (My state_encodings are done in the combinational process), but it works.

 

Regards,

 

Mark

 

 

 

 

0 Kudos
Scholar mistercoffee
Scholar
11,022 Views
Registered: ‎04-04-2014

Re: Rules for inferring FSM in Vivado

I agree. During my findings over the last few weeks I have seen several FSMs over two processes recognized in Vivado (one combinatorial next state process and one clocked current state register process).

 

One key thing that seems necessary is using an enumerated type for the states. Some of my FSMs weren't recognised until I did that. I would always have used enumerated types, these FSMs weren't written by me....

 

This is my main complaint though. I want a list of whats allowed and whats not. You can't just say "there's an example FSM follow that". The example in the synthesis guide is a single process FSM and clearly Vivado will recognise two process FSMs. If I had just tried to follow the example I would have had to rip up a working FSM in my design to port it to Vivado and that's a risk I didn't need to take.

 

A list of do's and don'ts is needed.

0 Kudos
Scholar markcurry
Scholar
11,017 Views
Registered: ‎09-16-2009

Re: Rules for inferring FSM in Vivado

Enumerated types for states aren't required - at least in verilog.  I've never used them yet.  (Probably will try moving forward with SystemVerilog...)
 
But you're main point still is true. Just what is required for Vivado to recognise a FSM?
 
Regards,
 
Mark
0 Kudos
Scholar mistercoffee
Scholar
11,013 Views
Registered: ‎04-04-2014

Re: Rules for inferring FSM in Vivado

That's interesting. At least in the FSMs I have (VHDL) changing to enumerated states made vivado recognise it. However, that doesn't mean enumerated states is the only way, just that my other way wasn't correct..

0 Kudos
Scholar dwisehart
Scholar
11,005 Views
Registered: ‎06-23-2013

Re: Rules for inferring FSM in Vivado

OK, I have to ask the question: if the synthesizer finds a more optimal way to code your logic than an FSM, why do you want to force the design back into a less optimal form?

Better yet, can you provide a test case where synthesis does not use an FSM and the design is less optimal because of it?

My opinion is: make your design look and work like a one-hot FSM, but then let the synthesis tools decide how to optimize it.

Daniel
0 Kudos
Scholar markcurry
Scholar
11,001 Views
Registered: ‎09-16-2009

Re: Rules for inferring FSM in Vivado

Daniel,

 

I'm not the OP, but I agree with you.  I really don't care all that much if a synthesizer recognizes the FSM and does FSM recoding or not.  It's an optimization.  Either case, my design should work.

 

FSM recoding can perhaps achieve a smaller, and/or faster design.  If there's a small tweak that I can do my coding style to always allow the tool to do the analysis, then great, I'll do it.  So, my interest here is just educational on how the tool works...

 

My 2cents.

 

--Mark

0 Kudos
Scholar mistercoffee
Scholar
11,000 Views
Registered: ‎04-04-2014

Re: Rules for inferring FSM in Vivado

"if the synthesizer finds a more optimal way to code your logic than an FSM" 

 

This is the big if. The idea is that the synthesis tool bothers to infer FSMs in the first place because it produces more efficient logic. If an FSM is not inferred when it should be then maybe it hasn't produced something as efficient. It has produced the most efficient way of synthesising the code if it didn't contain an FSM, but that isn't the case.

 

If you are suggesting that either way it has produc ed the most optimal solution then when should the tool bother looking for an FSM in the first place?

 

I'm not saying all that is true, but that's my understanding. i.e. it is done for a reason and I should try to make the tool infer the FSM.

 

 

0 Kudos
Scholar mistercoffee
Scholar
10,997 Views
Registered: ‎04-04-2014

Re: Rules for inferring FSM in Vivado

I should add that the whole reason I started this thread was because a design that passed timing in ISE failed timing in vivado. After looking at the failed paths and the modules that contained them I found that FSMs that were inferred in ISE were not inferred in vivado. The comment I got (from another thread) was that it could be a potential cause and I should investigate further and try to infer the FSM.

 

That doesn't mean it did cause the timing failure alone, there were other issues so now it is hard to be 100% sure. 

0 Kudos
Scholar dwisehart
Scholar
10,984 Views
Registered: ‎06-23-2013

Re: Rules for inferring FSM in Vivado

A test case that shows this: FSM not inferred but should have been because a better optimization (FSM based) is available, would be most helpful.

I would guess that most of my FSM-like code does not end up as an FSM because the code is simple and maps straight into a single LUT.

Daniel
0 Kudos
Explorer
Explorer
8,091 Views
Registered: ‎11-23-2009

Re: Rules for inferring FSM in Vivado

One simple but surprising reason why a 2 process fsm is not inferred in vivado is described in this post. That was the prime reason why all my fsm's which ISE happily detected where not detected by vivado (see post).

 

0 Kudos
Scholar mistercoffee
Scholar
6,451 Views
Registered: ‎04-04-2014

Re: Rules for inferring FSM in Vivado


@wfjmueller wrote:

One simple but surprising reason why a 2 process fsm is not inferred in vivado is described in this post. That was the prime reason why all my fsm's which ISE happily detected where not detected by vivado (see post).

 


That is very interesting! This might allow some of my FSMs to now infer (though I use a single process rather than two like yourself). It seems silly though, it's good practise to initiliase signals like this.

0 Kudos
Explorer
Explorer
6,386 Views
Registered: ‎11-23-2009

Re: Rules for inferring FSM in Vivado

The mechanism described in the "not inferred when 'next state' signal initialized" posting is specific for 2 process FSMs. There are a few other recent posts of interest on FSM extraction:

  • creation of a spurious iSTATE (see posting), again only in 2 process FSMs
  • number of states limit for FSM inference (see posting)
  • FSM detected, but not re-encoded even though one_hot requested (see posting)
0 Kudos