Specifying the Sequential vs. Combinational driving of logic in `FiniteStateMachine`

[chykon]

Motivation

It might be worth adding a clarification to the documentation that actions in State (state StateMachine) contains combinational, not sequential logic. Personally, I thought that sequential logic is used for state actions, since the StateMachine interface contains clk, reset inputs.

Desired solution

Add to the documentation a clarification that actions in State (state StateMachine) contains combinational, not sequential logic.

Alternatives considered

No response

Additional details

No response

[mkorbel1]

Good point, thanks for the suggestion!

[mkorbel1]

This came up again, and upon discussion it seems like it might make sense to add the ability to provide either/both on the FSM. For example, we could add something like updates as an additional List<Conditional> argument which updates sequentially instead of driving combinationally.

[soneryaldiz]

actions and updates do not appear very intuitive yet I don't have a better suggestion yet. Is it possible to keep actions as-is and determine combinational versus sequential updates based on the operator such as = vs <= (motivated by blocking vs non-blocking assignments).

[mkorbel1]

ROHD always uses blocking-like behavior in Combinational and non-blocking-like behavior in Sequential, and the same Combinational types (e.g. ConditionalAssignment, <) for either block, so there's no hint available from that.

An alternative could be a single switch at the creation of the FiniteStateMachine (in the constructor) that controls whether actions are combinational or sequential in nature for all?

[soneryaldiz]

No, let's allow combinational and/or sequential actions.