Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FSM state transition weirdness #336

Closed
zignig opened this issue Mar 17, 2020 · 8 comments
Closed

FSM state transition weirdness #336

zignig opened this issue Mar 17, 2020 · 8 comments
Labels

Comments

@zignig
Copy link
Contributor

zignig commented Mar 17, 2020

When building an FSM I came across a weird issue where an internal state was not executed if a hanging m.next was used.

    with m.FSM() as fsm:
        with m.State("IDLE"):
            with m.If(self.counter == self.max):
                m.next = "BOUNCE"
            m.next = "NEXT"

BOUNCE never gets executed with the m.next = "NEXT" un wrapped.

    with m.FSM() as fsm:
        with m.State("IDLE"):
            with m.If(self.counter == self.max):
                m.next = "BOUNCE"
            # if there is an m.Else , the above state works
            with m.Else():
                m.next = "NEXT"

does work.

full file with simulation

https://github.com/zignig/tinybx_stuff/blob/master/weird_fsm/FSM_weird.py

@whitequark
Copy link
Member

whitequark commented Mar 17, 2020

Right, so this is working as intended. The semantics of nMigen is that later assignments to the same signal (m.next = ... is a form of assignment to a signal, the FSM state) always override earlier assignments. You would see the same behavior if you wrote code like:

            with m.If(self.counter == self.max):
                m.d.sync += state.eq(1)
            m.d.sync += state.eq(0)

i.e. state would always be 0.

@zignig
Copy link
Contributor Author

zignig commented Mar 17, 2020

Ok, I understand now. Still a bit of a gotcha, if you are used to linear programming. Thanks WQ.

@whitequark
Copy link
Member

What do you mean by "linear programming" here?

@zignig
Copy link
Contributor Author

zignig commented Mar 17, 2020

My brain expected the commands to be executed one at a time and that the m.next was a GOTO statement, so the floating m.next was never executed.

Converting my thinking across to RTL where it is compiled into logic constructs is still a work in progress.

@whitequark
Copy link
Member

Ah, yeah, I can see how that can be confusing. I'll make sure to cover that in the docs.

@whitequark
Copy link
Member

@awygle @emilazy I think this is actually an argument in favor of keeping the assign-y m.next = ... syntax as opposed to making it more like a normal function call.

@awygle
Copy link
Contributor

awygle commented Mar 17, 2020 via email

@whitequark
Copy link
Member

Ah, right, that makes a lot of sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants