The Digilent Keypad PMOD is a simple grid of buttons:
The keypad’s physical circuit consists of a switch matrix organized into four rows and four columns:
The row signals are the keypad’s outputs. A set of pull-up resistors is used to hold all the row signals HIGH when no button is pressed.
The col signals are the keypad’s inputs. At any time, a single col is pulled LOW, so that it can overpower the pull-up resistors on the row signals. Suppose col[0] is pulled LOW, and a key is pressed in that column:
The keypad’s interface module sets col[0] LOW and detects that row[1] is HIGH, so that the keypress is uniquely detected at position (1,0).
You may have noticed that col[1], col[2] and col[3] are all indicated as Z, which is not a logic value. Verilog supports four-value logic where any wire or reg can have one of these values:
1 – logic TRUE, electrical HIGH0 – logic FALSE, electrical LOWX – logic “invalid”, electrical unkownZ – logic “undefined”, electrical high-impedance, i.e. disconnectedIn most situations, X and Z indicate design mistakes. But there are special gates called tri-state buffers that support Z outputs, allowing us to temporarily connect and disconnect wires within a circuit. The Xilinx FPGA uses tri-state buffers for its top-level outputs, so we can write Z values when needed to control PMOD devices.
In order to detect a single keypress, we can pull down one col signal at a time. The other col signals need to be Z so that a single column is isolated. We scan rapidly across all the columns following this sequence:
col = 0ZZZcol = Z0ZZcol = ZZ0Zcol = ZZZ0After scanning through each column, we repeat the sequence indefinitely to refresh the key detection. This loop can be modeled as a simple Finite State Machine (FSM). A Finite State Machine is visually represented using a state transition diagram like the one below. In this diagram style, each circle is a state, and the label within the circle is the state’s identifier (usually a name or integer value). The edges in the graph are transitions, and each transition is labeled with two parts: a condition, then a /, and then an assignment. The condition is the logical test that must be TRUE in order for the transition to occur. The assignment is the change in output signals due to the transition. For clarity, conditions are indicated in blue color.
In this diagram, the process is initialized in state 0 (indicated by the init condition). A state transition occurs whenever the scan signal is high. The frequency of scan dictates the speed for the keypad refresh process.
Notice that the state diagram indicates !rst_l as a condition to enter state 0. In digital systems there is usually a global reset signal that uses active low logic, so the system is reset whenever rst_l is LOW. The suffix _l is used to indicate an active-low signal. It’s also common to see other suffixes like _b (for “bar”), or _inv (for “inverted”). Whenever a signal is active-low, it should be named with a _l suffix to clarify its behavior.
Why active-low reset? When a system is first powered up, all signals are effectively 0, and at different times their electrical levels may appear to be 0 or 1. By holding rst_l at 0, the system can be maintained in a reset condition until the supply voltage is stable.
In the state transition diagram, there is an implied transition from every state back to 0 whenever rst_l is 0. These transitions are hidden in the diagram, but are indicated in the init | !rst_l condition.
The refresh period is the time it takes to repeat from col 0 back to col 0 again. The refresh period should be much faster than the time it takes for a human finger to press and release a key. On the other hand, the refresh period should be much slower than the system clock, since the Basys3 electrical signals are slower than the internal FPGA clock.
A good refresh time might be around 12ms. To complete a scan of all four col wires in 12ms, each individual col needs to be scanned for (12ms)/4 = 3ms. To create the appropriate timing, we will use a clock divider module:
module clock_divider
#(
parameter N=300_000
)
(
input clk,
input rst_l,
output reg div_clk
);
integer clk_count;
initial begin
clk_count = 0;
div_clk = 0;
end
always @(posedge clk, negedge rst_l) begin
// RESET BEHAVIOR:
if (!rst_l) begin
clk_count <= 0;
div_clk <= 0;
end
// NORMAL BEHAVIOR:
// Pulse div_clk every N clock cycles.
else begin
if (clk_count == N) begin
clk_count <= 0;
div_clk <= 1;
end
else begin
clk_count <= clk_count + 1;
div_clk <= 0;
end
end
end // always @ (posedge clk, negedge rst_l)
endmodule // clock_dividerThe clock_divider module sets clk_div HIGH every N clock cycles. On the Basys3, the system clock frequency is fc= 100MHz, with a period of Tc= 10ns. To obtain a 3ms scanning period, we need Tc × N=(10ns)*N = 3ms, or N=300000. This is set as the default value for parameter N in the module declaration.
In the src subdirectory, create a file named clock_divider.v and enter the code shown above. It is prefered for you to enter the code manually so that you fully understand the module.
keypad ModuleCreate a file named src/keypad.v to implement the keypad interface. Use this declaration template:
module keypad
#(
parameter N=300_000
)
(
input clk,
input rst_l,
input [3:0] row,
output [3:0] col,
output reg [15:0] keys
);
wire scan;
reg [1:0] state;
endmoduleThe module has a col output to drive the keypad columns, and a row input to receive signals from the keypad rows. The detected keypress(es) are indicated in an output named keys. There are 16 keys; if a key is pressed then the corresponding bit position in keys is set to 1.
Declare a clock_divider submodule and initialize the state and keys signals:
initial begin
state = 0;
keys = 0;
end
clock_divider clkdiv(.clk(clk),.rst_l(rst_l),.div_clk(scan));The global signals clk and rst_l are “passed through” from the top to submodules. The clock_divider output div_clk is connected to the scan signal. Since scan is defined in a submodule, it is considered a wire within the scope of keypad.
Next, implement the state transition diagram using a case statement as shown below. The behavior for state 0 is already completed, you should fill in the remaining states. In the code below, the reset behavior is implemented using if/else if statements. Since the state transitions only occur when scan is high, it is used as a condition for
the entire case block:
always @(posedge clk, negedge rst_l) begin
if (!rst_l) begin
state <= 0;
keys <= 0;
end
else if (scan) begin
case (state)
0:
begin
// Set the key values for this column:
keys[4'h1] <= ~row[0];
keys[4'h4] <= ~row[1];
keys[4'h7] <= ~row[2];
keys[4'h0] <= ~row[3];
// Proceed to the next state:
state <= 1;
end
1:
begin
// You do this
end
2:
begin
// You do this
end
3:
begin
// You do this
end
endcase
end
endcol assignmentsTo complete the keypad design, the col signals need to be appropriately assigned. In each of the module’s states, only one of the col signals is assigned 0, while the others are all Z. This is achieved using assign statements with the conditional ? operator:
assign col[0] = (state == 0) ? 0 : 1'bz;
assign col[1] = (state == 1) ? 0 : 1'bz;
assign col[2] = (state == 2) ? 0 : 1'bz;
assign col[3] = (state == 3) ? 0 : 1'bz;Since the col signals use Z values, they can only be assigned as top-level outputs. They can’t be safely assigned as registers in the clocked always block. The best practice is to use assign statements to define tri-state outputs separately from the clocked logic, as is done here.
Enter the lines above to complete the keypad module definition.
A testbench is provided in the file src/testbench.v. Open the file and study its contents. The testbench simulates a succession of keypress events in the order: no key, then col 0: row 0, 1, 2, 3; then no key, followed by col 1: row 0, 1, 2, 3; and so on.
To simulate these keypresses, we first define the depressed key position using variables row_pressed and col_pressed. When the keypad module scans across the columns, the electrical row signals should be 1111 except when the pressed column is being scanned. To simulate this electrical activity, we make conditonal assignments to row_wire as shown here:
// Simulated row/col for keypress position:
reg [3:0] row_pressed;
reg [3:0] col_pressed;
// Interface wires:
wire [3:0] row_wire;
wire [3:0] col_wire;
wire [15:0] keys;
wire refresh;
// The row wire can be pulled down only if the column wire matches
// the column where the button is pressed:
assign row_wire[0] = &(col_wire===col_pressed) ? row_pressed[0] : 1 ;
assign row_wire[1] = &(col_wire===col_pressed) ? row_pressed[1] : 1 ;
assign row_wire[2] = &(col_wire===col_pressed) ? row_pressed[2] : 1 ;
assign row_wire[3] = &(col_wire===col_pressed) ? row_pressed[3] : 1 ;Here, the triple-equal operator === is used to compare 4-value logic vectors. If the keypad output col_wire matches col_pressed in all positions, then row_wire is assigned to equal row_pressed. Otherwise row_wire is assigned 1111.
For each simulated keypress, we need to give the keypad module enough time to scan through all the columns and complete a full refresh. To achieve the required timing, we use a clock_divider in the testbench to generate a timing signal called refresh:
// Timing to change key value every
// refresh interval
clock_divider #(.N(1_200_000)) clkdiv
(.clk(clk),.rst_l(rst_l),.div_clk(refresh));
This clock divider’s timing parameter is set 1,200,000, equal to four times the keypad scan period. This means we’ll change the keypress after the keypad completes its scan of all four columns.
Further down in the testbench, we see a nested pair of case statements:
if (refresh) begin
case (row_pressed)
4'b1111: row_pressed <= 4'b1110; // first row_pressed
4'b1110: row_pressed <= 4'b1101; // second row_pressed
4'b1101: row_pressed <= 4'b1011; // third row_pressed
4'b1011: row_pressed <= 4'b0111; // fourth row_pressed
4'b0111: // After the last row, we change column and
begin // start going through the rows again:
row_pressed <= 4'b1111;
case (col_pressed)
4'bZZZ0 : col_pressed <= 4'bZZ0Z;
4'bZZ0Z : col_pressed <= 4'bZ0ZZ;
4'bZ0ZZ : col_pressed <= 4'b0ZZZ;
4'b0ZZZ : col_pressed <= 4'bZZZ0;
endcase // case (col_pressed)
end
endcase
endWhenever the refresh signal is 1, this code block is evaluated. It scans through each of the four row_pressed values. On the final row, it reverts to a no-keypress state, and advances col_pressed to the next column. Then the sequence of row_pressed states is repeated.
Notice that this simple state-machine uses Z values in its registers. This was not allowed in the keypad module design. Why? The answer is that four-value register assignments are allowed in simulation, but are not synthesizeable. In the keypad module, we could have used Z assignments within the state machine in the always block, and it may have simulated correctly, but in the end the implemented design would not work properly on the Basys3 board, all without any clear error messages.
Once you have completed the clock_divider and keypad modules, and understand the testbench design, run make to compile and simulate your design. In the file results.txt, you should see an output like this:
clk: 300002 col: zzz0 row: 1111 keys: 0000000000000000
clk: 600003 col: zz0z row: 1111 keys: 0000000000000000
clk: 900004 col: z0zz row: 1111 keys: 0000000000000000
clk: 1200005 col: 0zzz row: 1111 keys: 0000000000000000
clk: 1500006 col: zzz0 row: 1110 keys: 0000000000000000
clk: 1800007 col: zz0z row: 1111 keys: 0000000000000010
clk: 2100008 col: z0zz row: 1111 keys: 0000000000000010
clk: 2400009 col: 0zzz row: 1111 keys: 0000000000000010
clk: 2700010 col: zzz0 row: 1101 keys: 0000000000000010
clk: 3000011 col: zz0z row: 1111 keys: 0000000000010000
clk: 3300012 col: z0zz row: 1111 keys: 0000000000010000
clk: 3600013 col: 0zzz row: 1111 keys: 0000000000010000
clk: 3900014 col: zzz0 row: 1011 keys: 0000000000010000
clk: 4200015 col: zz0z row: 1111 keys: 0000000010000000
clk: 4500016 col: z0zz row: 1111 keys: 0000000010000000
clk: 4800017 col: 0zzz row: 1111 keys: 0000000010000000
clk: 5100018 col: zzz0 row: 0111 keys: 0000000010000000
clk: 5400019 col: zz0z row: 1111 keys: 0000000000000001
clk: 5700020 col: z0zz row: 1111 keys: 0000000000000001
clk: 6000021 col: 0zzz row: 1111 keys: 0000000000000001
clk: 6300022 col: zzz0 row: 1111 keys: 0000000000000001
clk: 6600023 col: zz0z row: 1111 keys: 0000000000000000
clk: 6900024 col: z0zz row: 1111 keys: 0000000000000000
clk: 7200025 col: 0zzz row: 1111 keys: 0000000000000000
clk: 7500026 col: zzz0 row: 1111 keys: 0000000000000000
clk: 7800027 col: zz0z row: 1110 keys: 0000000000000000(The console output is more detailed and could be useful for debugging if your design has a problem). Each line of output represents one period of scan, and you can see the col signal rotate through each of the four columns. After every four lines, the row signal changes. In the output shown above, we see “no press” followed by keys 1, 4, 7, and 0, corresponding to the left-most column on the keypad.
top ModuleWe’re going to use the Basys3 board’s center button as the reset for this design. Since the buttons are active-high, we need a top module to invert it and make an active-low reset signal. This type of interface layer is sometimes called a “wrapper” module, since it performs a minimal logic function.
module top
(
input clk,
input rst,
input [3:0] row,
output [3:0] col,
output [15:0] keys
);
wire rst_l;
assign rst_l = ~rst;
keypad #(.N(300_000)) kypd
(
.clk(clk),
.rst_l(rst_l),
.row(row),
.col(col),
.keys(keys)
);
endmodule // topkeypad.xdc FileThe top-level I/O assignments are specified in the XDC file. Open it and observe the usual clk definition, and notice that the keys output vector is mapped to the 16 LEDs on the Basys3 board. The rst signal is mapped to the center button.
To interface with the PMod hardware, the row and col signals are mapped to the JA Header located on the upper left of the board. To test the keypad interface, you need to plug the keypad into the JA header as shown:
Run make implement to synthesize, place-and-route, and generate a bitstream. Program the bitstream onto your Basys3 board and verify that each key lights up the corresponding LED on the board.
After verifying correct function, take a short video demonstrating keys 0 through F, and upload it in Canvas to indicate that you are done.
gitTurn in your work using git: