Documente Academic
Documente Profesional
Documente Cultură
Swapnajit Mitra
ABSTRACT This paper proposes an object oriented methodology for hardware implementation of finite state machines using SystemVerilog. The paper has two broad parts. In the first part, using already existing SystemVerilog syntax, the paper proposes a coding methodology for finite state machines that is portable across designs and is in tune with rest of the object oriented nature of SystemVerilog language. In the second part, it proposes new extensions for class datatype that will even further streamline the hardware centric object oriented nature of SystemVerilog. The paper concludes with an appeal to the EDA vendors for their support of these extensions.
Table of Contents
1.0 Finite State Machine ........................................................................................................... 3 2.0 Coding FSM in Verilog ...................................................................................................... 3 3.0 An Object Oriented Approach for Hardware...................................................................... 5 4.0 A Class Template for FSM Design..................................................................................... 5 4.1 The Base Class for any FSM .............................................................................................. 6 4.2 The Sub Class for a Specific FSM...................................................................................... 7 4.3 The Main Body of the Module ........................................................................................... 8 5.0 Implementation Issues and Reducing Redundancy ............................................................ 9 6.0 A Proposal for Syntax Extension of SystemVerilog Class Datatype to Allow Automated, Temporal and Conditional Execution of Methods........................................................................ 10 7.0 A Complete Example........................................................................................................ 10 8.0 Conclusions....................................................................................................................... 12 9.0 Acknowledgements........................................................................................................... 13 10.0 References......................................................................................................................... 13 11.0 Author Biography ............................................................................................................. 13
Table of Figures
Figure 1 State Diagram of an example FSM ............................................................................... 3 Figure 2 - Verilog code for the state machine of Figure 1.............................................................. 4 Figure 3 - A base class for any FSM .............................................................................................. 7 Figure 4 - A sub class example for the FSM of Figure 2................................................................ 8 Figure 5 The main body of the FSM module............................................................................... 9 Figure 6 Alteration of task syntax.............................................................................................. 10 Figure 7 Alteration of function syntax....................................................................................... 10 Figure 8 The complete code for the FSM module using the extended syntax........................... 12
SNUG San Jose 2006 2 A SystemVerilog Class Template for Finite State Machine Design
00 1 11 0
01 0 10
module fsm ( input clk , input reset , input x ); // variable declaration reg [1:0] current_state; reg [1:0] next_state; // parameter declaration parameter ONE = 4b1; parameter STATE_00_BIT = parameter STATE_00 = ONE parameter STATE_01_BIT = parameter STATE_01 = ONE parameter STATE_10_BIT = parameter STATE_10 = ONE parameter STATE_11_BIT = parameter STATE_11 = ONE
// combinatorial assignment of next_state always @* begin next_state = current_state; case (1b1) // synthesis full_case parallel_case current_state[STATE_00_BIT]: if (x) next_state = STATE_01; current_state[STATE_01_BIT]: if (~x) next_state = STATE_10; current_state[STATE_10_BIT]: if (x) next_state = STATE_11; current_state[STATE_11_BIT]: if (x) next_state = STATE_00; endcase end // sequential assignment of current_state always @(posedge clk) if (reset) current_state <= STATE_00; else current_state <= next_state; endmodule
Figure 2 - Verilog code for the state machine of Figure 1
There are few salient points to note in the above implementation that will help analysis of the later parts of this paper. Observation-1: There are two always blocks in the module that clearly separates the generation of the variables next_state and current_state. Observation-2: The variable next_state is generated through an all-combinatorial block. Anytime any of the signals (in this case, x and current_state) changes, next_state is re-evaluated through a combinatorial logic using Verilog blocking assignment (=).
SNUG San Jose 2006 4 A SystemVerilog Class Template for Finite State Machine Design
Observation-3: The evaluation of current_state is always done at an edge of a clock (in the example of Figure 2, at the positive edge of the clock). Thus, the value of next_state may change any number of times in between two clock edges, but current_state is evaluated only at the edge using Verilog non-blocking assignment (<=) that mimics the behavior of a flip-flop. Observation-4: A critical part of the previous observation is that the logic corresponding to the assignment of current_state does not change regardless of what the FSM does (as long as the logic works at the positive edge of the clock and the reset is synchronous and active high). We will further explore the implication of this observation on our discussion in Section 4. Although this particular example does not have any, an output produced by an FSM will be generated by a sequential or combinatorial combination of the current_state or next_state variables and other inputs. Thus, their generation is not related to the main body of the FSM.
generic properties (i.e., data inside that class) and methods (i.e., task and functions inside the class that work on those data) for the class that will be applicable for any FSM. The other part will have to be customized for a specific FSM. Also, the first part can be described in a base class and the other part can be a sub class of this base class. 4.1 The Base Class for any FSM To define the base class for an FSM, we must define its properties and methods. Since current_state and next_state are the only two variables that the code in Figure 2 generates, the base class for an FSM should have those variables as its properties1. The methods of this base class, by definition, must be those which modify the above properties. The only external variable that the assignment of current_state depends on is reset. The task `current_state_transition performs this. It is important to note here that the task itself does not specify when the assignment takes place (i.e. the positive edge of the clock). The assignment of next_state depends on a specific FSM, but again separating the events that change next_state from the change itself, the task next_state_transition performs this operation. From these, here is the code for the base class named genericFSM in Figure 3. The width of the state bits here is made parameterized to make it generic for any FSM.
class genericFsm #(int FSM_WIDTH = 7); // properties bit [FSM_WIDTH:0] current_state; bit [FSM_WIDTH:0] next_state; // methods task next_state_transition ( input int state_to_bit ); // combinatorial begin // { next_state = 0; next_state [state_to_bit] = 1'b1; end // } endtask task current_state_transition ( input logic reset ); // flopped begin // { if (reset) current_state <= IDLE; else current_state <= next_state; end // } endtask endclass
1
Moreover, no other part of the code needs to modify or read these variables, except perhaps some sub classes. So, these variables can be marked as protected, if the designer so wishes. 6 A SystemVerilog Class Template for Finite State Machine Design
4.2 The Sub Class for a Specific FSM The next state transition rules are always specific to a particular FSM. Thus, they need a sub class of genericFSM that particularly caters to that FSM. The sub class specificFSM in Figure 4 below shows how to do this for the example of Figure 2. There are few things to notice in this implementation. First, the sub class specificFSM alters the width of the state bits of the base class (from 8 to 4) for this particular example. It then defines a separate task for each of the state transitions without specifying, once again, when the state transition occurs. Each of these tasks calls the task next_state_transition of the base class, either to move to a new state or simply to stay in the current state. Needless to say, though the basic structure of the sub class (parameter declarations, method definitions for the next state and the combinatorial logic) remains the same, their implementation will change from one FSM to another.
class specificFSM extends genericFSM #(3); // parameter declaration localparam ONE = 4b1; localparam STATE_00_BIT = localparam STATE_00 = ONE localparam STATE_01_BIT = localparam STATE_01 = ONE localparam STATE_10_BIT = localparam STATE_10 = ONE localparam STATE_11_BIT = localparam STATE_11 = ONE // methods task from_state_00; begin // { if (x) next_state_transition (STATE_01_BIT); else next_state_transition (STATE_00_BIT); end // } endtask task from_state_01; begin // { if (~x) next_state_transition (STATE_10_BIT); else next_state_transition (STATE_01_BIT); end // } endtask task from_state_10; begin // {
SNUG San Jose 2006 7 A SystemVerilog Class Template for Finite State Machine Design
if (x) next_state_transition (STATE_11_BIT); else next_state_transition (STATE_10_BIT); end // } endtask task from_state_11; begin // { if (x) next_state_transition (STATE_00_BIT); else next_state_transition (STATE_11_BIT); end // } endtask task main_comb; begin // { case (1'b1) current_state[STATE_00_BIT]: current_state[STATE_01_BIT]: current_state[STATE_10_BIT]: current_state[STATE_11_BIT]: endcase end // } endtask endclass
4.3 The Main Body of the Module Once the base and the sub class are defined, the main body of the module for an FSM just needs to instantiate the corresponding objects. This is shown in Figure 5 below.
module fsm_class ( input clk , input reset , input x ); class genericFsm #(int FSM_WIDTH = 7); ... // contents of Figure 3 goes here endclass class specificFSM extends genericFSM #(3); ... // contents of Figure 4 goes here endclass specificFSM #(3) P; always @(posedge clk) P.current_state_transition(); always @*
SNUG San Jose 2006 8 A SystemVerilog Class Template for Finite State Machine Design
P.main_comb; endmodule
Figure 5 The main body of the FSM module
The main body of the module contains an object instance P of the sub class specificFSM. The main body also contains two blocks, one sequential and another combinatorial similar to the traditional FSM of Figure 2, that triggers events for generating the current and the next state respectively. For generating current_state, the module calls the task current_state_transition (that P has inherited from genericFSM). For generating next_state, the module calls the main combinatorial logic task main_comb.
In the next section, this paper proposes an extension of the syntax of SystemVerilog to allow such features.
6.0 A Proposal for Syntax Extension of SystemVerilog Class Datatype to Allow Automated, Temporal and Conditional Execution of Methods
This proposal introduces no new keyword, and extends the SystemVerilog grammar in two places of the language, namely the syntaxes of tasks and functions (i.e., the methods) within a class. Outside the scope of a class (excluding out of block extern methods), these extensions have no meaning2. A parser may generate an implementation dependent error message or simply ignore these extensions if they are encountered outside the scope of a class. A triggering of a method only occurs when an object instance is available for the class. The EBNF for these extensions are shown in Figure 6 and 7 below [3] [4].
task_declaration ::= task [lifetime] [task_sensitivity_list] task_body_declaration // Section 10.2, SV3.1A task_sensitivity_list ::= ([procedural_timing_control_statement]) // Annex A.6, IEEE 1364-2001
Figure 6 Alteration of task syntax
function_declaration ::= function [lifetime] [function_sensitivity_list] function_body_declaration // Section 10.3, SV3.1A function_sensitivity_list ::= ([procedural_timing_control_statement]) // Annex A.6, IEEE 1364-2001
Figure 7 Alteration of function syntax
The main change in the existing syntax is the introduction of optional task_sensitivity_list (or, function_sensitivity_list in case of function. All of the following discussion is valid for functions as well). This is a parenthesized, optional list that describes the sensitivity list for triggering the task. An empty list is permitted and will imply unconditional triggering of the task. The use of the wildcard * is allowed. For an out of block extern method declaration, the variables declared in the task_sensitivity_list will follow the same SystemVerilog scoping rules that apply to variables used inside the method.
, input );
class genericFsm #(int FSM_WIDTH = 7); // properties bit [FSM_WIDTH:0] current_state; bit [FSM_WIDTH:0] next_state; // methods task next_state_transition ( input int state_to_bit ); // combinatorial begin // { next_state = 0; next_state [state_to_bit] = 1'b1; end // } endtask task (@(posedge clk)) current_state_transition ( input logic reset ); // flopped begin // { if (reset) current_state <= IDLE; else current_state <= next_state; end // } endtask endclass class specificFSM extends genericFSM #(3); // parameter declaration localparam ONE = 4b1; localparam STATE_00_BIT = localparam STATE_00 = ONE localparam STATE_01_BIT = localparam STATE_01 = ONE localparam STATE_10_BIT = localparam STATE_10 = ONE localparam STATE_11_BIT = localparam STATE_11 = ONE // methods task from_state_00; begin // { if (x) next_state_transition (STATE_01_BIT); else next_state_transition (STATE_00_BIT); end // }
SNUG San Jose 2006 11 A SystemVerilog Class Template for Finite State Machine Design
endtask task from_state_01; begin // { if (~x) next_state_transition (STATE_10_BIT); else next_state_transition (STATE_01_BIT); end // } endtask task from_state_10; begin // { if (x) next_state_transition (STATE_11_BIT); else next_state_transition (STATE_10_BIT); end // } endtask task from_state_11; begin // { if (x) next_state_transition (STATE_00_BIT); else next_state_transition (STATE_11_BIT); end // } endtask task (@*) main_comb; begin case (1'b1) current_state[STATE_00_BIT]: current_state[STATE_01_BIT]: current_state[STATE_10_BIT]: current_state[STATE_11_BIT]: endcase end endtask endclass specificFSM #(3) P; // The module body is pretty much empty endmodule
Figure 8 The complete code for the FSM module using the extended syntax
8.0 Conclusions
This paper proposes an object oriented structure for an FSM, one of the most widely used hardware elements in a digital design, using standard SystemVerilog constructs. It further
12
proposes extensions in the current SystemVerilog syntax to implement a finite state machine even more concisely by Allowing class type variables as synthesizable component inside a module. Allowing extended syntax for task and function definition that automates their execution. At the time of writing this paper, the current trend of increasing support for the newer SystemVerilog datatypes, including class type, in simulation, synthesis and other EDA tools is indeed encouraging. This provides a good opportunity for the EDA vendors to support the new constructs proposed in this paper, and also for the standard committees, such as IEEE P1800 and Accellera, to consider these new extensions for inclusion in a future revision of the language.
9.0 Acknowledgements
The author would like to thank SNUG reviewers of this paper for their feedback. The author is also indebted to Haihui Chen of Synopsys Inc. for his meticulous comments and suggestions on this paper.
10.0 References
[1] M Morris Mano. Digital Logic and Computer Design. Englewood Cliffs, NJ: Prentice Hall Inc., 1987. [2] Zvi Kohavi. Switching and Finite Automata Theory. New Jersey, NJ: McGraw Hill, 1978. [3] SystemVerilog 3.1a Language Reference Manual . Napa, CA: Accellera Organization, 2004. [4] IEEE Std.1364-2001 Verilog Hardware Description Language. Piscataway, NJ: IEEE Press, 2001. [5] SCO Group, Using Simple Finite State Machines. http://ou800doc.caldera.com/en/SDK_c++/_Using_Simple_Finite_State_Machi.html, July, 2005 [6] Project VeriPage, SystemVerilog Class Datatype. http://www.projectveripage.com/sv_class_1.php, July 2005.
13