State machine question in Arria X device

Hi,
syn_encoding attribute works well for me, however I didn't check in this specfic Quartus version.
Sure your code follows Quartus state machine encoding template?

The only dedicated syn_encoding that I'm using in some cases is "safe". "Sequential" saves registers but uses more logic cells for internal decoding, an example with 31 states needs 39 extra logic elements for sequential compared to default one-hot encoding.

Regards
Frank

Yes, you should first try adding a Safe State Machine assignment in the Assignment Editor.  That will ensure your SM can't get into one of the many illegal states possible with one-hot encoding.  But you also should be coding your next state logic properly.  Can you show in your code how you're defining states and the next-state logic?

HI, 

Thank you for replies!!

In my case, i just only change sys_encoding attribute, the state machine work correctly.

In the begining, i didn't declare sys_encoding attribute (quartus default is one-hot), the stat machine will fail in some state.

After founding fail case, I add sys_encoding attribute(* syn_encoding = "gray" *) or (* syn_encoding = "sequential" *), the state machine works well.
(RTL code are fixed, didn't change)

Attachment is my RTL code, that define states and next-state logic.

In my fail case, spi_mode_sel ==2'b11, qspi_header_type == 1'b1,qspi_ddr_mode_en == 1'b0 , color_format == 3'b000, and all above signal are constant.

In should be "SPI_IDLE->SPI_RESET_STATE->CHK_FIFO->4W_HEADER1(33 clk)-> 4W_RGB888". 

But if using one-hot coding, the state machine will be ""SPI_IDLE->SPI_RESET_STATE->CHK_FIFO->4W_HEADER1(1 clk)-> 4W_RGB888"

How can i prevent this problem? 

And What will cause this porblem?

Thank you all.

Not sure what you mean by "4W_HEADER1(33 clk)" vs. "4W_HEADER1(1 clk)".  I see a state "4W_HEADER1" but that's it.

Other than that, I'd try using parameter instead of localparam.  I don't know if that affects the way Quartus "detects" state machines, but it's worth a try.

You should also break up those super deep else/if statements.  Pull that logic out of the main next state logic and use case statements and intermediate signal(s) instead in separate processes.  Are you having timing issues?

Hi,
your code doesn't show how FSM condition variables, e.g. 4W_32header_cmd_sclk_cnt are set. The reported problem suggests that condition variables are read inconsistently in FSM clock domain. Is the design fully constrained, does it pass timing analysis?

There are no indications that the problem is primarily related to FSM encoding, however if timing requirements aren't met, different encoding can create different behaviour.

Your code has invalid variable and parameter identifiers (starting with a digit), not sure how it's generated.

Regards
Frank