XST corrupts my state machine. Only disabling FSM encoding helps

Hi,

i have a state machine like this

always @( * ) case(state) IDLE: casex(SOME_STATEMENTS) {inputs}: next = NEXT_STATE1; {inputs}: next = NEXT_STATE3; default: next = IDLE; STATE1; casex(SOME_STATEMENTS) {inputs}: next = STATE2; {inputs}: next = STATE4; default: next = STATE1; default: next = IDLE;

In functional simulation everything is fine. After XST synthesis magical things happen. THe FSM just doesn't work correctly anymore logically. Some inputs are misinterpreted causing the FSM to jump into wrong states. It's ridiculous. The output signals for the specific states however are correct.

FSM encoding USER did not help however disabling FSM encoding by setting it to NONE in the XST properties helped. Now the design runs fine after XST. It is however 3 MHz slower. Worse is that you cannot trust the XST anymore at all.

Is this a known problem? Maybe its just the coding style which confuses the XST.

Reply to
heinerlitz
Loading thread data ...

[snip]

[snip]

How about that old classic: Are your inputs synchronized to the state machine clock?

--
Joe Samson
Pixel Velocity
Reply to
Joseph Samson

Hi yes all inputs are synchornized to the FSM clock. I can further add that I am doing a non timing anotated simulation.

Reply to
heinerlitz

You have simplified your example code to the point that you do not even show the clock. The sample code describes an asynchronous state machine, which I doubt is what you want based on other messages.

Instead of:

always @( * )

Do you have:

always @( posedge clk)

If not, that is a problem. If you do, I would suggest posting a more complete example.

Regards,

John McCaskill

formatting link

Reply to
John McCaskill

Don't use casex or casez at all.

When I coded an FSM using casez, XST's optimizer simply removed the entire FSM (and any downstream logic driven by the FSM.) In your case, I see you have nested case+casex statements, so XST's output was a bit better (but ultimately, incorrect.)

Anyway, I had this problem in XST (Webpack) 9.1.03 -- I'm guessing it still hasn't been fixed as of XST 9.2.03?

...

Reply to
Helpme

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.