[PyCDE] Expanded syntax for FSMs

[teqdruid]

I was thinking something like:

@fsm.machine
class F1:
  clk = Clock()
  go = Input(types.i1)
  valid = Input(types.i1)
  data = Input(types.i4)

  @fsm.state(initial=True)
  def a(ports, next):
    with If(ports.go):
      next.b()
    EndIf()

  @fsm.state
  def b(ports, next):
    with If(ports.valid):
      with If(ports.data == 3):
        next.a()
      EndIf()
    EndIf()

[alandy]

The transition syntax state.goto_a() seems strange. I think something like below would be much cleaner

state.transition(a)

or

state.next(a)

[mortbopet]

Do we need the next variable as a parameter of the state transfer function? I was thinking that it could just be part of the underlying @fsm.machine.

  @fsm.state
  def b(ports):
    with If(ports.valid):
      with If(ports.data == 3):
        transition(F1.a) # or transition(self.a)
      EndIf()
    EndIf()

Other than that, i like the syntax. This should be able to leverage the If sugar of #3633, emitting combinational logic shared for all state transitions, and then emitting fsm.transitions with guards.

We probably have to think about how this fits into the fsm dialect. Currently, there's no way to share logic between different state transition guards, and/or state output regions - they're siblings. The least path of resistance here would probably be to emit all of the state transition combinational logic in the top-level machine scope. Works for a hardware model, but it can be discussed whether it's an anti-pattern of what we want to do with the fsm dialect.

fsm.machine(...) {
  // machine scope
  // combinational logic for _all_ state transition functions
  ...
  %b_to_a_guard = ...

  fsm.state @B output  {
    fsm.output ...
  } transitions {
    fsm.transition @B guard {
        fsm.return %b_to_a_guard
    }
  }

[teqdruid]

We probably have to think about how this fits into the fsm dialect. Currently, there's no way to share logic between different state transition guards, and/or state output regions - they're siblings. The least path of resistance here would probably be to emit all of the state transition combinational logic in the top-level machine scope. Works for a hardware model, but it can be discussed whether it's an anti-pattern of what we want to do with the fsm dialect.

Two thoughts:

1. I don't think this should be considered an anti-pattern. Seems totally reasonable to share logic in this way. The alternative is to create and drive these signals externally to the FSM, which I see as clearly inferior.
2. Does this imply something deeper about the FSM model which was defined? This syntax is the way designers generally specify and reason about FSMs.