This template, also based on fi gures 7.1 and 7.2 , is presented below. The only differ-ence with respect to the Moore template just presented is in the always_comb block for the combinational logic because the output is specifi ed differently now. Recall that in a Mealy machine the output depends not only on the FSM ’ s state but also on its input, so if statements are expected for the output in one or more states because the output values might not be unique. This is achieved by including the output within the conditional statements for nx_state . For example, observe in lines 15 – 33, relative to state A, that the output values are now conditional. Compare these lines against lines 27 – 34 in the previous template.
Please read all comments made for the Moore template in section 7.3 because, except for the difference mentioned above, they all apply to the Mealy template below
134 Chapter 7
as well. Particular attention should be paid to the recommendations in comment 8, which can be easily adapted from the Moore case to the Mealy case.
1 //Part 1: Module header:---
SystemVerilog Design of Regular (Category 1) State Machines 135
53 C: ...
54 ...
55 endcase
56
57 //Optional output register:
58 (same as for category 1 Moore, section 7.3) 59
60 endmodule
61 //---
7.5 Design of a Small Counter
This section presents a SystemVerilog-based design for the 1-to-5 counter with enable and up-down controls introduced in section 5.4.1 (fi gure 5.3).
Because counters are inherently synchronous, the Moore approach is the natural choice for their implementation, so the SystemVerilog template of section 7.3 is used.
Because possible glitches at (positive) clock transitions are generally not a problem in counters, the optional output register shown in the fi nal portion of the template is not employed.
The fi rst part of the code ( module header ) is in lines 1 – 4. The module ’ s name is counter . Note that all ports are of type logic , with one bit for each input and three bits for the output.
The second part of the code ( declarations ) is in lines 6 – 9. The enumerated type state is created in it to represent the machine ’ s present and next states.
The third and fi nal part of the code ( statements ) is in lines 11 – 57. It contains two always blocks, described next.
The fi rst always block (lines 13 – 15) is an always_ff , which implements the machine ’ s state register. This is a standard code, similar to the template.
The second always block (lines 18 – 55) is an always_comb , which implements the entire combinational logic section. It is just a list of all states, each containing the output value and the next state. Note that in each state the output value is unique because in a Moore machine the output depends only on the state in which the machine is.
Finally, and very importantly, observe the correct use of registers and the complete-ness of the code, as described in comment 8 of section 7.3. Observe in particular the following: 1) all states are included; 2) the list of outputs (only outp in this case) is exactly the same in all states, and the corresponding values are always included; 3) the specifi cations for nx_state are always fi nalized with an else statement, so no condi-tion is left unchecked.
1 //Module header:--- 2 module counter (
3 input logic up, ena, clk, rst,
136 Chapter 7
13 always_ff @(posedge clk, posedge rst) 14 if (rst) pr_state < = one;
SystemVerilog Design of Regular (Category 1) State Machines 137
Simulation results from the code above are exhibited in fi gure 7.3 . Note that the output changes only at positive clock transitions, counting up when up = ‘ 1 ’ , down when up = ‘ 0 ’ , and stopping if ena = ‘ 0 ’ .
The number of fl ip-fl ops inferred by the compiler was three for sequential, Gray, or Johnson encoding and fi ve for one-hot, matching the predictions made in section 5.4.1.
7.6 Design of a Garage Door Controller
This section presents a SystemVerilog-based design for the garage door controller introduced in section 5.4.5. The Moore template of section 7.3 is employed to imple-ment the FSM of fi gure 5.9c.
The fi rst part of the code ( module header ) is in lines 1 – 4. The module ’ s name is garage_door_controller . Note that all ports are of type logic .
The second part of the code ( declarations ) is in lines 6 – 10. The enumerated type state is created in it to represent the machine ’ s present and next states.
The third and fi nal part of the code ( statements ) is in lines 12 – 65. It contains two always blocks, described next.
The fi rst always block (lines 14 – 16) is an always_ff , which implements the machine ’ s state register. This is a standard code, similar to the template.
The second always block (lines 19 – 63) is an always_comb , which implements the entire combinational logic section. It is just a list of all states, each containing the output value and the next state. Note that in each state the output value is unique because in a Moore machine the output depends only on the state in which the machine is.
Finally, and very importantly, observe the correct use of registers and the complete-ness of the code, as described in comment 8 of section 7.3. Observe in particular the Figure 7.3
Simulation results from the SystemVerilog code for the 1-to-5 counter with enable and up-down controls of fi gure 5.3.
138 Chapter 7
following: 1) all states are included; 2) the list of outputs (only ctr in this case) is exactly the same in all states, and the corresponding values are always included; 3) the specifi cations for nx_state are always fi nalized with an else statement, so no condi-tion is left unchecked.
1 //Module header:--- 2 module garage_door_controller (
3 input logic remt, sen1, sen2, clk, rst, 9 opening2, open1, open2, closing1, closing2} state;
10 state pr_state, nx_state;
11
12 //Statements:--- 13 //FSM state register:
14 always_ff @(posedge clk, posedge rst) 15 if (rst) pr_state < = closed1;
SystemVerilog Design of Regular (Category 1) State Machines 139
50 else nx_state < = open2;
51 end
52 closing1: begin
53 ctr < = 2'b11;
54 if (sen2) nx_state < = closed1;
55 else if (~remt) nx_state < = closing2;
56 else nx_state < = closing1;
57 end
58 closing2: begin
59 ctr < = 2'b11;
60 if (remt | sen2) nx_state < = closed1;
61 else nx_state < = closing2;
62 end
63 endcase
64
65 endmodule
66 //---
The number of fl ip-fl ops inferred by the compiler after synthesizing the code above was three for sequential or Gray encoding, four for Johnson, and eight for one-hot, matching the predictions made in section 5.4.5.
Simulation results are depicted in fi gure 7.4 . The encoding chosen for the states was sequential (section 3.7). The states are enumerated from 0 to 7 (there are eight states) in the order in which they were declared in lines 8 – 9. Be aware, however, that some compilers reserve the value zero for the reset state; because the reset (initial) state in the present example is closed1 (see line 15), which is the fi rst state in the declaration list, that is not a concern here.
In this simulation the sequence closed1 — closed2 — opening1 — opening2 — open1 — open2 — closing1 — closed1 (see state names in the lower part of fi gure 7.4 ) was tested.
Note that pulses of various widths were used to illustrate the fact that their width has no effect beyond the fi rst positive clock edge.
Figure 7.4
Simulation results from the SystemVerilog code for the garage door controller of fi gure 5.9c.
140 Chapter 7
7.7 Design of a Datapath Controller for a Greatest Common Divisor Calculator
This section presents a SystemVerilog-based design for the control unit introduced in section 5.4.8, which controls a datapath to produce a greatest common divisor (GCD) calculator. The Moore template of section 7.3 is employed to implement the FSM of fi gure 5.13e.
The fi rst part of the code ( module header ) is in lines 1 – 6. The module ’ s name is control_unit_for_GCD . Note that all ports are of type logic .
The second part of the code ( declarations ) is in lines 8 – 11. The enumerated type state is created in it to represent the machine ’ s present and next states.
The third and fi nal part of the code ( statements ) is in lines 13 – 67. It contains two always blocks, described next.
The fi rst always block (lines 15 – 17) is an always_ff , which implements the machine ’ s state register. This is a standard code, similar to the template.
The second always block (lines 20 – 65) is an always_comb , which implements the entire combinational logic section. It is just a list of all states, each containing the output values and the next state. Note that in each state the output values are unique because in a Moore machine the outputs depend only on the state in which the machine is.
Finally, and very importantly, observe the correct use of registers and the complete-ness of the code, as described in comment 8 of section 7.3. Observe in particular the following: 1) all states are included; 2) the list of outputs is exactly the same in all states, and the corresponding values are always included; 3) the conditional specifi ca-tions for nx_state are always fi nalized with an else statement, so no condition is left unchecked.
1 //Module header:--- 2 module control_unit_for_GCD (
3 input logic dv, clk, rst,
10 typedef enum logic [2:0] {idle, load, waitt, writeA, writeB} state;
11 state pr_state, nx_state;
12
13 //Statements:--- 14 //FSM state register:
15 always_ff @(posedge clk, posedge rst) 16 if (rst) pr_state < = idle;
17 else pr_state < = nx_state;
18
19 //FSM combinational logic:
SystemVerilog Design of Regular (Category 1) State Machines 141
Solve exercise 6.1 using SystemVerilog instead of VHDL.
142 Chapter 7
Exercise 7.2: One-Shot Circuits
Solve exercise 6.2 using SystemVerilog instead of VHDL.
Exercise 7.3: Manchester Encoder
Solve exercise 6.3 using SystemVerilog instead of VHDL.
Exercise 7.4: Differential Manchester Encoder
Solve exercise 6.4 using SystemVerilog instead of VHDL.
Exercise 7.5: String Detector
Solve exercise 6.5 using SystemVerilog instead of VHDL.
Exercise 7.6: Generic String Detector
Solve exercise 6.6 using SystemVerilog instead of VHDL.
Exercise 7.7: Keypad Encoder
Solve exercise 6.7 using SystemVerilog instead of VHDL.
Exercise 7.8: Datapath Controller for a Largest-Value Detector