Hierarchical State Machines
In the previous chapter, we made numerous improvements in the BCU, and developed an overall structure for the code. In this chapter, we re-work the finite state machine to be a hierarchical state machine (HFSM). We start with the general model for HFSMs
- PDF / 394,786 Bytes
- 8 Pages / 439.37 x 666.142 pts Page_size
- 102 Downloads / 175 Views
Hierarchical State Machines
Restructuring for a Hierarchical State Machine In the previous chapter, we made numerous improvements in the BCU, and developed an overall structure for the code. In this chapter, we re-work the finite state machine to be a hierarchical state machine (HFSM). We start with the general model for HFSMs and then move on to re-coding the BCU state machine. The finite state machine is central to the structure of the BCU: it defines how the design functions over time. It is like the main in C code: it’s where we start any analysis of the code. Making the state machine as well-structured and as easy to understand as possible is critical.
General Model for HFSMs State machines, like most aspects of design, follow the rule of seven. If there are more than about seven states in a state machine, it becomes much harder to design, to review, and to understand. The solution is to design and code it using hierarchy, and to limit the number of states at any one level of hierarchy to (at most) about seven. Figure 4-1 shows the top level of a (generic) hierarchical state machine that consists of three states. IDLE is a normal state. S1 and S2 are composite states, indicated by the concentric circles. Composite states are sub-state machines: state machines that are called by another state machine. Figure 4-2 shows the detail of the S1 sub state machine.
Because of the possibility of human or mechanical error, neither the author, Synopsys, Inc., nor any of its affiliates, including but not limited to Springer Science+Business Media, LLC guarantees the accuracy, adequacy or completeness of any information contained herein. In no event shall the authors, Synopsys, Inc. or their affiliates be liable for any damages in connection with the information provided herein. Full disclaimer available at: p. v of Frontmatter. M. Keating, The Simple Art of SoC Design: Closing the Gap between RTL and ESL, DOI 10.1007/978-1-4419-8586-6_4, © Synopsys, Inc. 2011
47
48
4 Hierarchical State Machines
Figure 4-1 Top level state diagram for a generic hierarchical finite state machine.
Figure 4-2 Sub state finite state machine for composite state S1.
Designing and coding a state machine to be a hierarchical state machine does not change the function of the state machine at all. It is largely a notational convenience, like functions, that facilitate structure in our code. We code S1 as a task that is called by the case statement in the main state machine. There is still only one state active at any one time. For instance, if the main state is in S1, then none of the states in S2 are active. If the main state is in S1 and S1 is in the S1A state, then the whole machine is in the S1A state. Example 4-1 indicates how to code a hierarchical finite state machine, using tasks. The full code for this example is in Appendix B. Figure 4-3 shows the top level of the state machine. This simple state machine reads a 32-bit packet and then sends it out as two 16-bit words.
enum {IDLE, GET_PKT, SEND_PKT} tx_state ; enum {GP_READ, G
Data Loading...
