FSM inside another FSM

Hello People,

What do you think about this code:

------------------------------------------------------------------------------
FSM: process (clk,rst) is -- Effected directly by the SPI_transceiver_rst
begin
if rst = '1' then
state <= idle;
elsif rising_edge(clk) then
case state is
when idle =>
if input = '1' then
state <= run;
end if;
when run =>
case internal_state is
when x =>
-- do something or move to state y
when y =>
-- do something or move to state x
end case;
end case;
end process;
------------------------------------------------------------------------


A far as I understand it will create a child state machine embedded inside one of the states of the main state machine.
Am I correct?
Is this a good way to write code?

Is this a good way to write code?

Click to expand...

Why not, if it serves a purpose.

In my view, the structure seems only reasonable, if internal_state is preserved outside "run". Also one could consider separate processes for each state machine as a clearer way.

I see nothing wrong with this, but you should initialize "internal_state" somewhere.

"the structure seems only reasonable, if internal_state is preserved outside run"

What do you mean by preserve?

= if you're servicing the second state machine only in state run.

I see. makes senses.

However, I didn't understand your suggestion of seperate state machines.
The idea of 2 seperate FSMs contradicts the idea of an FSM inside another FSM.

Can you explain it in code please?

The idea of 2 seperate FSMs contradicts the idea of an FSM inside another FSM.

Click to expand...

Yes, of course. Strictly spoken, the "inside" aspect is only a matter of code layout. The "inner" state machine is constituted by the state variable, and it exists independent of the "outer" one. It's rather a problem of state machine interaction.

By writing to the "inner" state variable only in state "run", you implicitely hold (or preserve) the state otherwise. As std_match mentioned, you would want to add at least an initialisation for the "inner" state machine.

You can however implement exactly the same behaviour in two separate processes. The transitions of the second state machine would be still made dependent on the state of the first one (e.g. hold outside run) as well as it's own state.

It's not a big thing in my opinion. You can evaluate the advantages and drawbacks in terms of coding effort and clarity, as well as the respective chances to hide or reveal design faults.

Thanks,
Great help