Finite state machine is widely used in digital design. However its behavior such as state transition and output driving is hard coded which is not convenient or even acceptable in many scenarios. Here we briefly introduce a memory based programmable state machine. The behavior of the state machine is NOT hard coded and can be programmed on the fly by software.
Let’s take a look of a simple hard-coded FSM example at first. We have three state, ST0, ST1, and ST2. State transition condition is as shown: if in0 is high ST0 moves to ST1, and so on. At each state some output is asserted: out0 is 1 when state is ST0, out1 is 1 when state is ST1, and so on.
Verilog implementation of the state machine are as below.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
parameter ST0 = 3'b0, ST1 = 3'b1, ST2 = 3'b10; reg [2:0] state; reg [2:0] next_state; always @(state or in0 or in1) begin next_state = 3'b0; case (state) ST0: if (in0 == 1'b1) next_state = ST1; else next_state = ST0; ST1: if (in1 == 1'b1) next_state = ST2; else next_state = ST1; ST2: if (in2 == 1'b1) next_state = ST0; else next_state = ST2; default: next_state = ST0; endcase end always @(posedge clk) begin if(rst_n == 1'b0) begin state <= ST0; else begin state <= next_state; end assign out0 = (state == ST0); assign out1 = (state == ST1); assign out2 = (state == ST2); |
As can be seen, state transition and output driving at each state is hard-coded. So what if later we want to drive both out1 and out2 to be high during ST1? Or instead of waiting for in0 to be high we want ST0 transit to ST1 after some fixed clock cycles?
In general, here are some scenarios we may want to use programmable state machine:
1. The state machine is used to control a third-party IP. But at the time of design, the sequence of how to control IP is not fully determined or not fully understood. Or it could be the first time to use an IP, some abnormality is expected and to be safe designer likes to have some programmability to change state machine behavior.
2. Processor is not available. Normally we can use SOC processor to do this kind of programmable control. A typical way is to connect input condition signals such as in1, in2, and in3 to a status register. Processor can poll/read this register to know input condition. Or input condition signals can be connected as one of processor interrupt sources. Based on the input condition (via either polling or irq), processor writes another control register which in turn drives out0, out1, and out2. All good. But processor may not be available in some use cases:
2.1 We want to save processor power. We can lower processor clock rate so processor is still up and running and is able to check status register and write control register. But we can not further gate off processor clock.
2.2 To further lower power, we may want to shut down processor power domain and even the power source. Programmable state machine can be in a small and always on domain to monitor inputs and control outputs.
3. Response latency issue. Even processor is available but if the response latency requirement is high, using processor is not a suitable solution. This is due to processor polling or IRQ latency. Instead if programmable state machine is hardware based its response latency can be better managed. For our memory based programmable state machine, it is pretty much determined by clock rate and memory speed.
4. Properly partitioned hardware and software are always needed. Software should be used for low date rate and irregular data and hardware should be used for high data rate and regular data which is also the scenario we want to use programmable state machine. Related in today’s ASIC design, we try to squeeze many functions into software and the benefit is clear – time to market, flexibility, and so on. But we have seen many cases subtle issue happens due to software control timing. Designers are spending much more time to debug software issue.
So we know we would like to have programmable state machine for certain scenarios in our design. Next if you google “programmable state machine”, you can see some articles pop up and the following two are good examples out of them:
http://www.research.ibm.com/people/g/gdittma/publications/HeaderParser_Dittmann.pdf
http://www.dc.uba.ar/materias/disfpga/2010/c2/descargas/TechXclusive%20Creating%20Embedded%20Microcontrollers.pdf
The design described in these two articles works as a simplified processor. It has a simplified instruction set and an ALU unit to do AND/OR/ADD/Shift/etc operation. The programmable state machine we are going to introduce is even simpler than this.
To gain access you can subscribe to this author's posts at Subscription of SD-RTL-DGN Posts. Subscription is valid for three months.
Thanks for sharing. Nice work.