XST does not recognize FSM definition

pplaza · ‎10-26-2011

Hi all,

I’m using ISE 12.4 and I have the following problem:

When I describe a FSM (Finite State Machine) in VHDL as it is showed in the attached example (LATCH_EXAMPLE.vhd), the XST does not recognize the described FSM. And no warning is showed. Instead the warning, the following Info is provided by the tool:

INFO:Xst:2117 - HDL ADVISOR - Mux Selector <PST> of Case statement line 37 was re-encoded using one-hot encoding. The case statement will be optimized (default statement optimization), but this optimization may lead to design initialization problems. To ensure the design works safely, you can:

- add an 'INIT' attribute on signal <PST> (optimization is then done without any risk)

- use the attribute 'signal_encoding user' to avoid onehot optimization

- use the attribute 'safe_implementation yes' to force XST to perform a safe (but less efficient) optimization

And PST signal is inferred using one-hot coding.

My next test was to change “-safe_implementation” value to yes at the “Synthesis Options/HDL Options”. After that instead the Info, the tool had provided the following Warning + Info:

WARNING:Xst:737 - Found 7-bit latch for signal <NST>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.

INFO:Xst:2371 - HDL ADVISOR - Logic functions respectively driving the data and gate enable inputs of this latch share common terms. This situation will potentially lead to setup/hold violations and, as a result, to simulation problems. This situation may come from an incomplete case statement (all selector values are not covered). You should carefully review if it was in your intentions to describe such a latch.

And PST signal is not coded as a FSM again.

But now I know that my design has a 7-bit latch for signal NST. After removing this latch providing a value in the when others clause (line 67), setting ST_0 as NST value (“NST <= ST_0;”), the PST state machine is always inferred with a one-hot coding.

As final test, I changed the FSM properties to force XST to implement it again as safe state machine. And now it was coded with user encoding.

Xilinx ISE 13.4 was used to repeat the same tests and the same results were obtained.

Does anybody know what XST tool does not recognize the latch in my original FSM?

Does anybody know what XST tool does implements my FSM with different coding strategies when I modify the “-safe_implementation” attribute?

Did anybody know what I made wrong in the description of my FSM?

Thanks in advance,

Pedro.

rcingham · ‎09-09-2010

I think the problem is in the OUTPUT_REG process. What the synthesizer probably thinks you have coded is:

  OUTPUT_REG : process(nRST,CLK)
   begin  
    if(nRST='0')then
     PROCESS_RDY <= '0';
    elsif(rising_edge(CLK))then
     case PST is
      when ST_0 =>
       PROCESS_RDY <= '0';		  
      when ST_1 =>  null;
      when ST_5 =>  null;
      when ST_2 =>  null;
       PROCESS_RDY <= '0';
      when ST_WAIT =>  null;
      when ST_3 =>
       PROCESS_RDY <= '1';
      when ST_4 =>
       PROCESS_RDY <= '1';
      when others =>
       PROCESS_RDY <= '0';
     end case;
    end if;  
  end process OUTPUT_REG;

Hence the latch. Did you mean:

  OUTPUT_REG : process(nRST,CLK)
   begin  
    if(nRST='0')then
     PROCESS_RDY <= '0';
    elsif(rising_edge(CLK))then
     if ((PST = ST_0) or (PST = ST_2)) then
       PROCESS_RDY <= '0';
     elsif ((PST = ST_3) or (PST = ST_4)) then
       PROCESS_RDY <= '1';
     end if;
    end if;  
  end process OUTPUT_REG;

In that process and the 'TRANSITION_LOGIC' logic process in the case statements you have specified all the possible values of the enumerated type, and 'others', which is redundant. (NOTE: Not redundant if a 'std_logic(_vector)' is the control for the case statement).

------------------------------------------
"If it don't work in simulation, it won't work on the board."

bassman59 · ‎02-25-2008

Don't use a two-process state machine, and this won't be a problem.

----------------------------------------------------------------
Yes, I do this for a living.

eilert · ‎08-14-2007

Hi,

not sure yet what really causes the latch, just one hint:

TRANSITION_LOGIC : process(nRST, START_OP_1, START_OP_2, ABORT, PST)
begin
if(nRST = '0')then
NST <= ST_0;
else
case PST is

The red part is useless. This process is combinatorical, you can't reset it.

For PST you have a reset in the stateregister. That is sufficient.

NST is calculated from that and properly ready at the next rising clock edge.

Have a nice synthesis

Eilert

pplaza · ‎10-26-2011

Hi,

thanks for your solutions Rcingham, Bassman59 and Eilert.

I tried all solutions provided by you.

@ Rcingham:

I tried the two options but the result is the same, the FSM is not detected by the XST parser and a bit latch is not found for PST signal.

As I understand in a case statement the variable evaluated depends on, for FSM design, the codification used, it’s possible that the FSM enters an invalid state not defined by user, ie. my FSM is formed by 7 states defined by me, but if this FSM is codified using One-Hot, there are 7 states defined by me and 121 states not defined by me. In this case when others clause is not redundant.

@ Bassman59:

Following your indications I rewrite my HW description from two process to one process, but the result is the same, the FSM is not detected by the XST parser and a bit latch is not found for PST signal (present state of the FSM). The only one difference is that XST shows the following warning regarding to a 1-bit latch for the output signal PROCESS_RDY:

WARNING:Xst:737 - Found 1-bit latch for signal <PROCESS_RDY>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.

@ Eilert:

I tried your solution but I’m afraid that the result is the same, the FSM is not detected by the XST parser and a bit latch is not found for PST signal.

I have attached my file modified according your comments to verify my understanding about your solutions.

The attached file in my last post (04-23-2012 03:58 AM) is the solution that allow XST to detect the FSM. The original version of my file is attached too in the current post.

Thanks again for your time and regards.

Pedro.

bassman59 · ‎02-25-2008

pplaza wrote:

Hi,

@ Bassman59:

Following your indications I rewrite my HW description from two process to one process, but the result is the same, the FSM is not detected by the XST parser and a bit latch is not found for PST signal (present state of the FSM). The only one difference is that XST shows the following warning regarding to a 1-bit latch for the output signal PROCESS_RDY:

WARNING:Xst:737 - Found 1-bit latch for signal <PROCESS_RDY>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.

The source called LATCH_EXAMPLE_Bassman59.vhd in your archive is a two-process state machine.

In a single-process machine, the process is synchronous (clk and async reset ONLY on the sensitivity list) and you don't need the whole "next state" logic nonsense.

----------------------------------------------------------------
Yes, I do this for a living.

pplaza · ‎10-26-2011

OK, I'm sorry for the misunderstanding.

My question is to know why XST does not recognize the FSM neither detects the unassigned values for NST signal in the all possible options that can take PST signal. This is to avoid it generates extra and unpredictible logic which can make that functionality does not work as expected.

Your solution is completely right, but I was looking for other alternative.

Thanks again for your time and your efforts.

Pedro.

eilert · ‎08-14-2007

Hi Pedro,

I have checked your code and the one with _eilert

Both were not recogniuzing a FSM but also there was no sign of a latch in the synthesis report.

Out of curiosity I commented out the "when others => null;" in the transition logic, and whoops:

The same holds for your source:

This worked with and with out the reset condition in the transition logic (while it really is unneccessary and meaningless).

You see some differences in the above synthesis reports snippets.

These are caused by using different target devices. The first one was synthesized for a spartan6 the second one for a spartan3e. Due to the different LUT sizes the chosen state encoding changes.

Astonishing that something so seemingly unimportant can make such a difference.

If you want t o keep the when others claus you also can change it like this:

when others => NST <= ST_0;

Now, if something unexpected happens, your FSM always jumps back to the initial state. (Whatever this might be good for.)

Have a nice synthesis

Eilert

annand · ‎01-09-2012

I tried the code with ISE13.1.

And it synthesized the fsm succesfully.

Anand

pplaza · ‎10-26-2011

Thanks for your feedback.

It looks that XST doesn't like the reset condition in a combinatorial process. As I read in your comments the best way is to use synchronous process in the design.