FSM state transition weirdness

[zignig]

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]

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]

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

[whitequark]

What do you mean by "linear programming" here?

[zignig]

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]

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

[whitequark]

@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]

I have no issue with the assign (although maybe it should be an `.eq`?). I just think it should be `fsm.next` instead of `m.next`.

…

On Mon, Mar 16, 2020, 10:10 PM whitequark ***@***.***> wrote: @awygle <https://github.com/awygle> @emilazy <https://github.com/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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#336 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB35VVSXJ6PNNWKIKSLN2W3RH4A5DANCNFSM4LM5ZYDA> .

[whitequark]

Ah, right, that makes a lot of sense.