Expanding on tggzzz's comment, let's think about FSMs. They are exactly like the child's game of "Simon Says". You can't change state until Simon says. In C, it is a simple switch/case statement
state = 1; // initial state
switch(state) { // state is a variable, we use the value to select a case
case 1 : <do something in case/state 1>
state = 2;
break;
case 2 : <wait for something to happen>
if (it happened)
state = 3;
else
state = 2; // redundant, we're already in state 2 but I like to do it anyway. It's required in FPGA code
break;
case 3 : <we did something (case 1), we got acknowledgement (case 2), now do something else>
state = 4;
break;
default: state = 1; // we're in serious trouble if this ever executes!
}
[/font]
As discussed in your previous threads, you need to know what transitions cause the FSM to leave each state for which inputs. What happens if an unexpected input occurs? You need to account for all possible inputs in every state. You also need to define all possible outputs in each state.
It's pretty simple for FSMs with a dozen or so states. It gets a little harder when there are over 100 states and a couple of dozen inputs. Fortunately for FPGA designers, the languages give us the ability to define 'default' outputs that will be applied if a specific output signal isn't generated in a state.
You will see a lot of FSMs where the designer doesn't account for every input and every output in every state. That may be because they know that certain events just can't physically happen. That's ok too!
Google for Finite State Machine - there are hundreds of sites talking about them. They are the fundamental building block of all sequential machines - like computers and machine controls.
Home
Help
Search
Login
Register
