184 Rapid Prototyping of Digital Systems Chapter 9
fetch :
begin
instruction_register = memory_data_register;
program_counter = program_counter + 1;
state = decode;
end
// Decode instruction and send out address of any required data operands
decode :
begin
case (instruction_register[15:8])
8'b00000000:
state = execute_add;
8'b00000001:
state = execute_store;
8'b00000010:
state = execute_load;
8'b00000011:
state = execute_jump;
default:
state = fetch;
endcase
end
// Execute the ADD instruction
execute_add :
begin
register_A = register_A + memory_data_register;
state = fetch;
end
// Execute the STORE instruction (needs three clock cycles for memory write)
execute_store :
begin
// write register_A to memory
state = execute_store2;
end
// This state ensures that the memory address is valid until after memory_write goes low
execute_store2 :
begin
state = execute_store3;
end
// Execute the LOAD instruction
execute_load :
begin
register_A = memory_data_register;
state = fetch;
// Execute the JUMP instruction
end
execute_jump :
begin
program_counter = instruction_register[7:0];
state = fetch;
end
default :
A Simple Computer Design: The µP3 185
begin
state = fetch;
end
endcase
end
// Make these assignments immediately during current state (i.e., unregistered)
always @(state or program_counter or instruction_register)
begin
case (state)
reset_pc: memory_address_register = 8'h 00;
fetch: memory_address_register = program_counter;
decode: memory_address_register = instruction_register[7:0];
execute_add: memory_address_register = program_counter;
execute_store: memory_address_register = instruction_register[7:0];
execute_store2: memory_address_register = program_counter;
execute_load: memory_address_register = program_counter;
execute_jump: memory_address_register = instruction_register[7:0];
default: memory_address_register = program_counter;
endcase
case (state)
execute_store: memory_write = 1'b 1;
default: memory_write = 1'b 0;
endcase
end
endmodule
Figure 9.12 Verilog Model of μP 3 Computer.
DEPTH = 256; % Memory depth and width are required %
WIDTH = 16;
% Enter a decimal number %
ADDRESS_RADIX = HEX; % Address and value radixes are optional %
DATA_RADIX = HEX; % Enter BIN, DEC, HEX, or OCT; unless %
% otherwise specified, radixes = HEX %
-- Specify values for addresses, which can be single address or range
CONTENT : 0000; % Range--Every address from 00 to FF = 0000 (Default) %
BEGIN 0210; % LOAD AC with MEM(10) %
[00..FF] 0011; % ADD MEM(11) to AC %
00 : 0112; % STORE AC in MEM(12) %
01 : 0212; % LOAD AC with MEM(12) check for new value of FFFF %
02 : 0304; % JUMP to 04 (loop forever) %
03 : AAAA; % Data Value of B %
04 : 5555; % Data Value of C%
10 : 0000; % Data Value of A - should be FFFF after running program %
11 :
12 :
END ;
Figure 9.13 Progam.mif file containg μP 3 Computer Program and DATA.
186 Rapid Prototyping of Digital Systems Chapter 9
9.5 Automatically Generating a State Diagram of the μP3
Using Tools Netlist Viewers State Diagram Viewer to automatically
produce a state diagram of the μP3 model’s state machine, the state diagram
seen in Figure 9.14 is generated.
Note that the Fetch, Decode and Execute cycle is clearly displayed in the state
diagram. The initial reset state is seen on the far left of the state diagram. The
Fetch state (highlighted) jumps to Decode. Decode then jumps to one of several
Execute states depending on the instruction opcode. After execution of the
instruction is complete, all of the various execute states jump back to Fetch.
The state table displayed below the state diagram. Click on the encoding tab at
the very bottom to see how the different states are encoded in hardware.
Figure 9.14 Automatically generated state diagram of the μP3 model.
A Simple Computer Design: The µP3 187
9.6 Simulation of the μP3 Computer
A simulation output from the VHDL model is seen in Figure 9.15. After a reset,
the test program seen in Figure 9.13, loads, adds, and stores a data value to
compute A = B + C. The final value is then loaded again to demonstrate that the
memory contains the correct value for A. The program then ends with a jump
instruction that jumps back to its own address producing an infinite loop. After
running the program, FF is stored in location 12. Memory can be examined in
the Simulator after running a program by clicking on the Logical Memories
section in the left column of the Simulation Report. An example is shown in
Figure 9.16. Note that the clock period is set to 20ns for simulation.
Figure 9.15 Simulation of the Simple μP 3 Computer Program.
Figure 9.16 Simulation display of μP 3 Computer Memory showing result stored in memory
188 Rapid Prototyping of Digital Systems Chapter 9
9.7 Laboratory Exercises
1. Compile and simulate the μP 3 computer VHDL or Verilog model. Rewrite the machine
language program in the program.mif file to compute A = (B + C) + D. Store D in
location 13 in memory. End the program with a Jump instruction that jumps to itself. Be
sure to select the UP3’s Cyclone device as the target. Find the maximum clock rate of the
μP 3 computer. Examine the project’s compiler report and find the logic cell (LC)
percentage utilized.
2. Add the JNEG execute state to the CASE statement in the model. JNEG is Jump if AC <
0. If A >= 0 the next sequential instruction is executed. In most cases, a new instruction
will just require a new execute state in the decode CASE statement. Use the opcode value
of 04 for JNEG. Test the new instruction with the following test program that implements
the operation, IF A>= 0 THEN B = C
End_of_If: Assembly Language Machine Language Memory Address
LOAD A 0210 00
JNEG End_of_If 0404 01
LOAD C 0212 02
STORE B 0111 03
JMP End_of_If 0304 04
End_of_If is an example of a label; it is a symbolic representation for a location in the
program. Labels are used in assembly language to mark locations in a program. The last
line that starts out with End_of_If: is the address used for the End_of_If symbol in the
Jump instruction address field. Assuming the program starts at address 00, the value of
the End_of_If label will be 04. Test the JNEG instruction for both cases A < 0 and
A >= 0. Place nonzero values in the *.mif file for B and C so that you can verify the
program executes correctly.
3. Add the instructions in the table below to the VHDL model, construct a test program for
each instruction, compile and simulate to verify correct operation. In JPOS and JZERO
instructions, both cases must be tested.
Instruction Function Opcode
SUBT address AC = AC - MDR 05
XOR address AC = AC XOR MDR 06
OR address AC = AC OR MDR 07
AND address AC = AC AND MDR 08
JPOS address IF AC > 0 THEN PC = address 09
JZERO address IF AC = 0 THEN PC = address 0A
ADDI address AC = AC + address 0B
A Simple Computer Design: The µP3 189
In the logical XOR instruction each bit is exclusive OR’ed with the corresponding bit in
each operation for a total of sixteen independent exclusive OR operations. This is called a
bitwise logical operation. OR and AND are also bitwise logical operations. The add-
immediate instruction, ADDI, sign extends the 8-bit address field value to 16 bits. To
sign extend, copy the sign bit to all eight high bits. This allows the use of both positive
and negative two’s complement numbers for the 8-bit immediate value stored in the
instruction.
4. Add the following two shift instructions to the simple computer model and verify with a
test program and simulation.
Instruction Function Opcode
SHL address AC = AC shifted left address bits 0C
SHR address AC = AC shifted right address bits 0D
The function LPM_CLSHIFT is useful to implement multiple bit shifts. SHL and SHR
can also be used if 1993 VHDL features are enabled in the compiler. Only the low four
bits of the address field contain the shift amount. The other four bits are always zero.
5. Run the μP 3 computer model using one of the FPGA boards. Use a debounced
pushbutton for the clock and the other pushbutton for reset. Output the PC in hex to the
LCD display or seven segment LEDs. Run a test program on the board and verify the
correct value of the PC appears in the LCD display by stepping through the program
using the pushbutton.
6. Add these two input/output (I/O) instructions to the μP 3 computer model running on the
UP3 board.
Instruction Function Opcode
IN i/o address AC = switch bits (low 4 bits) 0E
OUT i/o address 0F
LCD or 7-Seg LED displays hex value of
AC
These instructions modify or use only the low eight bits of AC. Remove the PC display
feature from the previous problem, if it was added or for more of a challenge place the
AC value on the second line of the hex display by modifying the LCD display code. Test
the new I/O instructions by writing a program that reads in the switches, adds one to the
switch value, and outputs this value to the LED display. Repeat the input, add, and output
operation in an infinite loop by jumping back to the start of the program. Add a new
register, register_output, to the input of the seven-segment decoder that drives the LED
display or use the LCD display. The register is loaded with the value of AC only when an
OUT instruction is executed. Compile, download, and execute the program on the FPGA
board. When several I/O devices are present, they should respond only to their own
unique I/O address, just like memory.
190 Rapid Prototyping of Digital Systems Chapter 9
7. Use the timing analyzer to determine the maximum clock rate for the μP 3 computer.
Using this value, compute the execution time for the example program in Figure 9.4.
8. Modify the video output display described in Chapter 9 for the MIPS computer example
to display the μP 3’s internal registers. While running on the FPGA board, use the
pushbuttons for clock and reset as suggested in problem 5.
9. Add video character output and keyboard input to the computer, after studying the
material presented in Chapters 9 and 10.
10. Add the WAIT instruction to the simple computer model and verify with a test program
and simulation. WAIT value, loads and starts an 8-bit ten-millisecond (10-2 second) timer
and then waits value*10 ms before returning to fetch for the next instruction. Use an
opcode of 10 for the WAIT instruction.
11. Expand the memory address space of the μP 3 computer from eight bits to nine bits.
Some registers will also need an additional bit. Use 512 locations of 16-bit memory.
Expand the address field by 1-bit by reducing the size of the opcode field by 1-bit. This
will limit the number of different instructions to 128 but the maximum program size can
now increase from 256 locations to 512 locations.
12. Modify the μP 3 computer so that it uses two different memories. Use one memory for
instructions and a new memory for data values. The new data memory should be 256 or
512 (see previous problem ) locations of 16-bit data.
13. Add a subroutine CALL and RETURN instruction to the μP 3 computer design. Use a
dedicated register to store the return address or use a stack with a stack pointer register.
The stack should start at high addresses and as it grows move to lower addresses.
14. Implement a stack as suggested in the previous problem and add instructions to PUSH or
POP register AC from the stack. At reset, set the stack pointer to the highest address of
data memory.
15. Add all of the instructions and features suggested in the exercises to the μP 3 computer
and use it as a microcontroller core for one of the robot projects suggested in Chapter 12.
Additional instructions of your own design along with an interval timer that can be read
using the IN instruction may also be useful.
16. Using the two low-bits from the opcode field, add a register address field that selects one
of four different data registers A, B, C, or D for each instruction.
17. Use the implementation approach in the μP 3 computer model as a starting point to
implement the basic instruction set of a different computer from your digital logic
textbook or other reference manual.
CHAPTER 10
VGA Video Display
Generation using
FPGAs
The video image above was produced by an FPGA board design.
192 Rapid Prototyping of Digital Systems Chapter 10
10 VGA Video Display Generation using FPGAs
To understand how it is possible to generate a video image using an FPGA
board, it is first necessary to understand the various components of a video
signal. A VGA video signal contains 5 active signals. Two signals compatible
with TTL logic levels, horizontal sync and vertical sync, are used for
synchronization of the video. Three analog signals with 0.7 to 1.0-Volt peak-to-
peak levels are used to control the color. The color signals are Red, Green, and
Blue. They are often collectively referred to as the RGB signals. By changing
the analog levels of the three RGB signals all other colors are produced.
10.1 Video Display Technology
The first technology used to display video images dictated the nature of the
video signals. Even though LCD monitors are now in common use, the major
component inside early VGA computer monitors was the color CRT or Cathode
Ray Tube shown in Figure 10.1. The electron beam must be scanned over the
viewing screen in a sequence of horizontal lines to generate an image. The
deflection yoke uses magnetic or electrostatic fields to deflect the electron
beam to the appropriate position on the face of the CRT. The RGB color
information in the video signal is used to control the strength of the electron
beam. Light is generated when the beam is turned on by a video signal and it
strikes a color phosphor dot or line on the face of the CRT. The face of a color
CRT contains a series of rows with three different phosphors. One type of
phosphor is used for each of the primary colors of red, green, and blue.
In standard VGA format, as seen in Figure 10.2, the screen contains 640 by 480
picture elements or pixels. The video signal must redraw the entire screen 60
times per second to provide for motion in the image and to reduce flicker. This
period is called the refresh rate. The human eye can detect flicker at refresh
rates less than 30 to 60Hz.
To reduce flicker from interference from fluorescent lighting sources, refresh
rates higher than 60 Hz at around 70Hz are sometimes used in PC monitors.
The color of each pixel is determined by the value of the RGB signals when the
signal scans across each pixel. In 640 by 480-pixel mode, with a 60Hz refresh
rate, this is approximately 40 ns per pixel. A 25MHz clock has a period of 40
ns. A slightly higher clock rate will produce a higher refresh rate.
10.2 Video Refresh
The screen refresh process seen in Figure 10.2 begins in the top left corner and
paints 1 pixel at a time from left to right. At the end of the first row, the row
increments and the column address is reset to the first column. Each row is
painted until all pixels have been displayed. Once the entire screen has been
painted, the refresh process begins again.
The video signal paints or refreshes the image using the following process. The
vertical sync signal, as shown in Figure 10.3 tells the monitor to start
displaying a new image or frame, and the monitor starts in the upper left corner
VGA Video Display Generation 193
with pixel 0,0. The horizontal sync signal, as shown in Figure 10.4, tells the
monitor to refresh another row of 640 pixels.
After 480 rows of pixels are refreshed with 480 horizontal sync signals, a
vertical sync signal resets the monitor to the upper left comer and the process
continues. During the time when pixel data is not being displayed and the beam
is returning to the left column to start another horizontal scan, the RGB signals
should all be set to the color black (all zeros).
Scanning Electron Beam
Deflection
Yoke
Electron Gun
Phosphor
Grid Screen
Blue
Electron Guns
Red Green
Metal
Mask
RBG RBGR Phosphor Dots
on Glass Face
B G R B G R B G Plate
RBG RBGRB
Glass Face Plate
Figure 10.1 Color CRT and Phosphor Dots on Face of Display.
194 Rapid Prototyping of Digital Systems Chapter 10
640 Pixels in a row
0,0 639,0
480 Horizontal Scan Lines and Retrace 480
. Pixels
.
. in a
column
0,479 639,479
Figure 10.2 VGA Image - 640 by 480 Pixel Layout.
480 Horizontal Refresh Cycles
Red, Green, 1.02 ms 15.24 ms 0.35 ms
Blue
Pixel Data
Vertical
Sync
64 µs
16.6 ms
Figure 10.3 Vertical Sync Signal Timing for 640 by 480 at 60Hz.
Red, Green, 1.89 µs 25.17 µs 0.94 µs
Blue
Pixel Data
Horizontal
Sync
3.77µs
31.77 µs
Figure 10.4 Horizontal Sync Signal Timing for 640 by 480 at 60Hz.
VGA Video Display Generation 195
Many VGA monitors will shut down if the two sync signals are not the correct
values. Most PC monitors have an LED that is green when it detects valid sync
signals and yellow when it does not lock in with the sync signals. Modern
monitors will sync up to an almost continuous range of refresh rates up to their
design maximum. In a PC graphics card, a dedicated video memory location is
used to store the color value of every pixel in the display. This memory is read
out as the beam scans across the screen to produce the RGB signals. There is
not enough memory inside current generation FPGA chips for this approach, so
other techniques will be developed which require less memory.
10.3 Using an FPGA for VGA Video Signal Generation
To provide interesting output options in complex designs, video output can be
developed using hardware inside the FPGA. Only five signals or pins are
required, two sync signals and three RGB color signals. A simple resistor and
diode circuit is used to convert TTL output pin signals from the FPGA to the
low voltage analog RGB signals for the video signal. This supports two levels
for each signal in the RGB data and thus produces a total of eight colors. This
circuit and a VGA connector for a monitor are already installed on the Altera
UP3 board. The FPGA’s Phase Locked Loop (PLL) can be used to generate
clocks for a wide variety of video resolutions and refresh rates.
25 Mhz S y n c G e n e ra tio n H o riz o n ta l
C lo c k C ounters Sync
D ata Row Col V e rtic a l
fro m Sync
D e sign P ix e l R A M o r
C haracter V G A S ig n a ls
G enerator R O M
R
G
B
Figure 10.5 FPGA based generation of VGA Video Signals.
As seen in Figure 10.5, a 25.175 MHz clock, which is the 640 by 480 VGA
pixel data rate of approximately 40ns is used to drive counters that generate the
horizontal and vertical sync signals. Additional counters generate row and
column addresses. In some designs, pixel resolution will be reduced from 640
by 480 to a lower resolution by using a clock divide operation on the row and
column counters. The row and column addresses feed into a pixel RAM for
graphics data or a character generator ROM when used to display text. The
required RAM or ROM is also implemented inside the FPGA chip.
196 Rapid Prototyping of Digital Systems Chapter 10
10.4 A VHDL Sync Generation Example: FPGAcore VGA_SYNC
VGA_SYNC
clock_48Mhz red_out
red green_out
green
blue blue_out
horiz_sy nc_out
v ert_sy nc_out
v ideo_on
pixel_clock
pixel_row[9..0]
pixel_column[9..0]
inst
The FPGAcore function, VGA_SYNC is used to generate the timing signals
needed for a VGA video display. Although VGA_SYNC is written in VHDL,
like the other FPGAcore functions it can be used as a symbol in a design
created with any entry method.
The following VHDL code generates the horizontal and vertical sync signals,
by using 10-bit counters, H_count for the horizontal count and V_count for the
vertical count. H_count and V_count generate a pixel row and column address
that is output and available for use by other processes. User logic uses these
signals to determine the x and y coordinates of the present video location. The
pixel address is used in generating the image’s RGB color data. On all boards
except the UP2 and UP1, the internal logic uses a 25 MHz clock generated by a
PLL in the design file Video_PLL.vhd. Counters are used to produce video sync
timing signals like those seen in figures 10.3 and 10.4. This process is used in
all of the video examples that follow.
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.STD_LOGIC_ARITH.ALL;
USE IEEE.STD_LOGIC_UNSIGNED.ALL;
ENTITY VGA_SYNC IS
PORT( clock_25MHz, red, green, blue : IN STD_LOGIC;
red_out, green_out, blue_out : OUT STD_LOGIC;
horiz_sync_out, vert_sync_out : OUT STD_LOGIC;
pixel_row, pixel_column : OUT STD_LOGIC_VECTOR( 9 DOWNTO 0 ));
END VGA_SYNC;
ARCHITECTURE a OF VGA_SYNC IS
SIGNAL horiz_sync, vert_sync : STD_LOGIC;
SIGNAL video_on, video_on_v, video_on_h : STD_LOGIC;
SIGNAL h_count, v_count : STD_LOGIC_VECTOR( 9 DOWNTO 0 );
BEGIN
-- video_on is High only when RGB data is displayed
video_on <= video_on_H AND video_on_V;
VGA Video Display Generation 197
PROCESS
BEGIN
WAIT UNTIL( clock_25MHz'EVENT ) AND ( clock_25MHz = '1' );
--Generate Horizontal and Vertical Timing Signals for Video Signal
-- H_count counts pixels (640 + extra time for sync signals)
--
-- Horiz_sync -------------------------------------------________--------
-- H_count 0 640 659 755 799
--
IF ( h_count = 799 ) THEN
h_count <= "0000000000";
ELSE
h_count <= h_count + 1;
END IF;
--Generate Horizontal Sync Signal using H_count
IF ( h_count <= 755 ) AND (h_count => 659 ) THEN
horiz_sync <= '0';
ELSE
horiz_sync <= '1';
END IF;
--V_count counts rows of pixels (480 + extra time for sync signals)
--
-- Vert_sync ----------------------------------------_______------------
-- V_count 0 480 493-494 524
--
IF ( v_count >= 524 ) AND ( h_count => 699 ) THEN
v_count <= "0000000000";
ELSIF ( h_count = 699 ) THEN
v_count <= v_count + 1;
END IF;
-- Generate Vertical Sync Signal using V_count
IF ( v_count <= 494 ) AND ( v_count = >493 ) THEN
vert_sync <= '0';
ELSE
vert_sync <= '1';
END IF;
-- Generate Video on Screen Signals for Pixel Data
IF ( h_count <= 639 ) THEN
video_on_h <= '1';
pixel_column <= h_count;
ELSE
video_on_h <= '0';
END IF;
IF ( v_count <= 479 ) THEN
video_on_v <= '1';
pixel_row <= v_count;
ELSE
video_on_v <= '0';
198 Rapid Prototyping of Digital Systems Chapter 10
END IF;
-- Put all video signals through DFFs to eliminate
-- any delays that can cause a blurry image
-- Turn off RGB outputs when outside video display area
red_out <= red AND video_on;
green_out <= green AND video_on;
blue_out <= blue AND video_on;
horiz_sync_out <= horiz_sync;
vert_sync_out <= vert_sync;
END PROCESS;
END a;
To turn off RGB data when the pixels are not being displayed the video_on
signals are generated. Video_on is gated with the RGB inputs to produce the
RGB outputs. Video_on is low during the time that the beam is resetting to the
start of a new line or screen. They are used in the logic for the final RGB
outputs to force them to the zero state. VGA_SYNC also puts the all of video
outputs through a final register to eliminate any timing differences in the video
outputs. VGA_SYNC outputs the pixel row and column address. See the
comments at the end of VGA_SYNC.VHD for information on setting up other
screen resolutions and refresh rates.
10.5 Final Output Register for Video Signals
The final video output for the RGB and sync signals in any design should be
directly from a flip-flop output. Even a small time delay of a few nanoseconds
from the logic that generates the RGB color signals will cause a blurry video
image. Since the RGB signals must be delayed a pixel clock period to eliminate
any possible timing delays, the sync signals must also be delayed by clocking
them through a D flip-flop. If the outputs all come directly from a flip-flop
output, the video signals will all change at the same time and a sharper video
image is produced. The last few lines of VHDL code in the FPGAcore
VGA_SYNC design generate this final output register.
10.6 Required Pin Assignments for Video Output
The FPGA board requires the chip pins as seen in Table 10.1 to be defined in
the project’s *.qsf file, or elsewhere in your design in order to display the video
signals. These pins are hard wired on the FPGA board to the VGA connector
and cannot be changed.
A pixel clock is also needed at the appropriate rate for the screen resolution and
refresh rate. A PLL is used to generate this clock on the FPGA. The FPGA’s
external crystal controlled clock is used as input for the PLL on all boards
except the UP2 and UP1 (no PLL on these boards). On the UP3, set jumper JP3
to short pins 3-4 for the 48Mhz clock. A table of the common screen resolutions
and refresh rates with the required pixel clocks and sync counter values can be
found at the end of the VGA_SYNC IP core code.
VGA Video Display Generation 199
Table 10.1 The VGA Video Display Pin Assignments
Pin Name DE1 DE2 UP3 UP2, Pin Function of Pin
CLOCK L1 N2 153 UP1 Type
50Mhz 50Mhz 48Mhz 91 Input 25-50MHz Clock
VGA_RED B7 E10 228 25Mhz Output
VGA_GREEN A8 D12 122 236 Output VGA Red Video Signal
(highest bit on DE1/2)
VGA_BLUE B10 B12 170 237 Output
VGA_VSYNC B11 D8 226 Output VGA Green Video
VGA_HSYNC A11 A7 227 238 Output Signal (highest bit on
239 DE1/2)
VGA Blue Video Signal
240 (highest bit on DE1/2)
VGA Connector Vertical
Sync Signal
VGA Connector
Horizontal Sync Signal
10.7 Video Examples
For a simple video example with the VGA_SYNC function, the following
schematic produces a video simulation of a red LED. When the PB1 pushbutton
is hit, the color of the entire video screen will change from black to red. The
VGA_LED project setup is seen below:
VGA_SYNC
Clock_48Mhz INPUT clock_48Mhz red_out OUTPUT VGA_Red
PBSWITCH4 red green_out OUTPUT VGA_Green
VCC green OUTPUT VGA_Blue
INPUT blue blue_out OUTPUT VGA_HSync
horiz_sy nc_out OUTPUT VGA_VSync
VCC v ert_sy nc_out
GND v ideo_on
11 pixel_clock
pixel_row[9..0]
pixel_column[9..0]
1
VGA_SYNC outputs the pixel row and column address. Pixel_row and
Pixel_column are normally inputs to user logic that in turn generates the RGB
color data. Here is a simple example that uses the pixel_column output to
generate the RGB inputs. Bits 7, 6, and 5 of the pixel_column count are
connected to the RGB data. Since bits 4 through 0 of pixel column are not
connected, RGB color data will only change once every 32 pixels across the
screen. This in turn generates a sequence of color bars in the video output. The
color bars display the eight different colors that can be generated by the three
digital RGB outputs in the VGA_BAR project.
200 Rapid Prototyping of Digital Systems Chapter 10
VGA_SYNC
Clock_48Mhz INPUT clock_48Mhz red_out OUTPUT VGA_Red
VCC red green_out OUTPUT VGA_Green
green OUTPUT VGA_Blue
blue blue_out OUTPUT VGA_HSy nc
horiz_sy nc_out OUTPUT VGA_VSy nc
v ert_sy nc_out
Pixel_column[5] Pixel_row[9..0]
Pixel_column[6] v ideo_on
Pixel_column[7] pixel_clock Pixel_column[9..0]
pixel_row[9..0]
pixel_column[9..0]
1
10.8 A Character Based Video Design
One option is a video display that contains mainly textual data. For this
approach, a pixel pattern or font is needed to display each different character.
The character font can be stored in a ROM implemented inside the FPGA. A
memory initialization file, *.mif, can be used to initialize the ROM contents
during download. Given the memory limitations inside many FPGAs, one
option that fits is a display of 40 characters by 30 lines.
Each letter, number, or symbol is a pixel image from the 8 by 8 character font.
To make the characters larger, each dot in the font maps to a 2 by 2 pixel block
so that a single character requires 16 by 16 pixels. This was done by dividing
the row and column counters by 2. Recall that in binary, division by powers of
two can be accomplished by truncating the lower bits, so no hardware is needed
for this step. The row and column counters provide inputs to circuits that
address the character font ROM and determine the color of each pixel. The
clock used is the onboard 25.175MHz clock and other timing signals needed
are obtained by dividing this clock down in hardware.
10.9 Character Selection and Fonts
Because the screen is constantly being refreshed and the video image is being
generated on-the-fly as the beam moves across the video display, it is necessary
to use other registers, ROM, or RAM inside the FPGA to hold and select the
characters to be displayed on the screen. Each location in this character ROM
or RAM contains only the starting address of the character font in font ROM.
Using two levels of memory results in a design that is more compact and uses
far less memory bits. This technique was used on early generation computers
before the PC.
Here is an example implementation of a character font used in the FPGAcore
function, char_ROM. To display an "A" the character ROM would contain only
the starting address 000001 for the font table for "A". The 8 by 8 font in the
character generation ROM would generate the letter "A" using the following
eight memory words:
VGA Video Display Generation 201
Address Font Data 8 by 8 Font
000001000 : 00011000 ; Pixel Data
000001001 : 00111100 ;
000001010 : 01100110 ;
000001011 : 01111110 ;
000001100 : 01100110 ;
000001101 : 01100110 ;
000001110 : 01100110 ;
000001111 : 00000000 ;
Figure 10.6 Font Memory Data for the Character "A".
Character 6 Character 8
Generation
Address
000001 for A ROM
3 64 characters
Font Row 512 by 8 ROM
Address 8 8-bit words
000...111 per character
Figure 10.7 Accessing a Character Font Using a ROM.
The column counters are used to select each font bit from left to right in each
word of font memory as the video signal moves across a row. This value is used
to drive the logic for the RGB signals so that a "0" font bit has a different color
from a "1". Using the low three character font row address bits, the row counter
would select the next memory location from the character font ROM when the
display moves to the next row.
A 3-bit font column address can be used with a multiplexer to select the
appropriate bit from the ROM output word to drive the RGB pixel color data.
Both the character font ROM and the multiplexer are contained in the
FPGAcore char_ROM as shown below. The VHDL code declares the memory
size using the LPM_ROM function and the tcgrom.mif file contains the initial
values or font data for the ROM.
202 Rapid Prototyping of Digital Systems Chapter 10
Char_ROM rom_mux_output
clock
character_address[5..0]
f ont_row[2..0]
f ont_col[2..0]
inst
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.STD_LOGIC_ARITH.ALL;
USE IEEE.STD_LOGIC_UNSIGNED.ALL;
LIBRARY lpm;
USE lpm.lpm_components.ALL;
ENTITY Char_ROM IS : IN STD_LOGIC_VECTOR( 5 DOWNTO 0 );
PORT( character_address : IN STD_LOGIC_VECTOR( 2 DOWNTO 0 );
font_row, font_col : OUT STD_LOGIC);
rom_mux_output
END Char_ROM;
ARCHITECTURE a OF Char_ROM IS
SIGNAL rom_data : STD_LOGIC_VECTOR( 7 DOWNTO 0 );
SIGNAL rom_address : STD_LOGIC_VECTOR( 8 DOWNTO 0 );
BEGIN
-- Small 8 by 8 Character Generator ROM for Video Display
-- Each character is 8 8-bit words of pixel data
char_gen_rom: lpm_rom
GENERIC MAP (
lpm_widthad => 9,
lpm_numwords => 512,
lpm_outdata => "UNREGISTERED",
lpm_address_control => "UNREGISTERED",
-- Reads in mif file for character generator font data
lpm_file => "tcgrom.mif",
lpm_width => 8)
PORT MAP ( address => rom_address, q = > rom_data);
rom_address <= character_address & font_row;
-- Mux to pick off correct rom data bit from 8-bit word
-- for on screen character generation
rom_mux_output <= rom_data (
(CONV_INTEGER( NOT font_col( 2 DOWNTO 0 ))) );
END a;
VGA Video Display Generation 203
Table 10.2 Character Address Map for 8 by 8 Font ROM.
CHAR ADDRESS CHAR ADDRESS CHAR ADDRESS CHAR ADDRESS
@ 00 P 20 Space 40 0 60
A 01 Q 21 ! 41 1 61
B 02 R 22 " 42 2 62
C 03 S 23 # 43 3 63
D 04 T 24 $ 44 4 64
E 05 U 25 % 45 5 65
F 06 V 26 & 46 6 66
G 07 W 27 ‘ 47 7 67
H 10 X 30 ( 50 8 70
I 11 Y 31 ) 51 9 71
J 12 Z 32 * 52 A 72
K 13 [ 33 + 53 B 73
L 14 Dn Arrow 34 , 54 C 74
M 15 ] 35 - 55 D 75
N 16 Up Arrow 36 . 56 E 76
O 17 37 / 57 F 77
Lft Arrow
A 16 by 16 pixel area is used to display a single character with the character
font. As the display moves to another character outside of the 16 by 16 pixel
area, a different location is selected in the character RAM using the high bits of
the row and column counters. This in turn selects another location in the
character font ROM to display another character.
Due to limited ROM space, only the capital letters, numbers and some symbols
are provided. Table 10.2 shows the alphanumeric characters followed by the
high six bits of its octal character address in the font ROM. For example, a
space is represented by octal code 40. The repeated letters A-F were used to
simplify the conversion and display of hexadecimal values.
10.10 VHDL Character Display Design Examples
The FPGAcores VGA_SYNC and CHAR_ROM are designed to be used
together to generate a text display. CHAR_ROM contains an 8 by 8 pixel
character font. In the following schematic, a test pattern with 40 characters
across with 30 lines down is displayed in the VGA_CHARACTER project.
Examining the RGB inputs on the VGA_SYNC core you can see that characters
will be white (111 = RGB) with a red (100 = RGB) background. Each character
uses a 16 by 16 pixel area in the 640 by 480 display area. Since the low bit in
the pixel row and column address is skipped in the font row and font column
ROM inputs, each data bit from the font is a displayed in a 2 by 2 pixel area.
Since pixel row bits 9 to 4 are used for the character address a new character
will be displayed every 16th pixel row or character line. Division by 16 occurs
without any logic since the low four bits are not connected.
204 Rapid Prototyping of Digital Systems Chapter 10
Clock_48Mhz VGA_SYNC
VCC
INPUT clock_48Mhz red_out OUTPUT VGA_Red
VCC red green_out OUTPUT VGA_Green
green OUTPUT VGA_Blue
blue blue_out OUTPUT VGA_HSy nc
horiz_sy nc_out OUTPUT VGA_VSy nc
v ert_sy nc_out
Pixel_column[9..0] Pixel_row[9..0]
v ideo_on
pixel_clock
pixel_row[9..0]
pixel_column[9..0]
1
Char_ROM rom_mux_output
Pixel_row[9..4] clock
Pixel_row[3..1] character_address[5..0]
Pixel_column[3..1] f ont_row[2..0]
f ont_col[2..0]
inst
Normally, more complex user designed logic is used to generate the character
address. The video example shown in Figure 10.8 is an implementation of the
MIPS RISC processor core. The values of major busses are displayed in
hexadecimal and it is possible to single step through instructions and watch the
values on the video display. This example includes both constant and variable
character display areas. The video setup is the same as the schematic, but
additional logic is used to generate the character address.
Figure 10.8 MIPS Computer Video Output.
VGA Video Display Generation 205
Pixel row address and column address counters are used to determine the
current character column and line position on the screen. They are generated as
the image scans across the screen with the VGA_SYNC core by using the high
six bits of the pixel row and pixel column outputs. Each character is a 16 by 16
block of pixels. The divide by 16 operation just requires truncation of the low
four bits of the pixel row and column. The display area is 40 characters by 30
lines.
Constant character data for titles in the left column is stored in a small ROM
called the character format ROM. This section of code sets up the format ROM
that contains the character addresses for the constant character data in the left
column of the video image for the display.
-- Character Format ROM for Video Display
-- Displays constant format character data
-- on left side of Display area
format_rom: lpm_rom
GENERIC MAP (
lpm_widthad => 6,
lpm_numwords =>60,
lpm_outdata => "UNREGISTERED",
lpm_address_control => "UNREGISTERED",
-- Reads in mif file for data display titles
lpm_file =>"format.mif",
lpm_width => 6)
Each pixel clock cycle, a process containing a series of nested CASE
statements is used to select the character to display as the image scans across
the screen. The CASE statements check the row and column counter outputs
from the sync unit to determine the exact character column and character line
that is currently being displayed. The CASE statements then output the
character address for the desired character to the char_ROM FPGAcore.
Table 10.1 lists the address of each character in the font ROM. Alphabetic
characters start at octal location 01 and numbers start at octal location 60. Octal
location 40 contains a space that is used whenever no character is displayed.
When the display is in the left column, data from the format_ROM is used. Any
unused character display areas must select the space character that has blank or
all zero font data.
Hexadecimal variables in the right column in Figure 10.8 are generated by
using 4-bit data values from the design to index into the character font ROM.
As an example, the value "11" & PC(7 DOWNTO 4), when used as the
character address to the FPGAcore, char_ROM, will map into the character font
for 0..9 and A..F. The actual hex character selected is based on the current value
of the 4 bits in the VHDL signal, PC. As seen in the last column of Table 10.1,
the letters, A..F, appear again after decimal numbers in the font ROM to
simplify this hexadecimal mapping conversion.
206 Rapid Prototyping of Digital Systems Chapter 10
10.11 A Graphics Memory Design Example
For another example, assume the display will be used to display only graphics
data. The Cyclone EP1C6 FPGA contains 92K bits of memory. If only two
colors are used in the RGB signals, one bit will be required for each pixel in the
video RAM. If a 300 by 300 pixel video RAM was implemented in the Cyclone
chip it would use all of the chip’s 92K-bit memory. For full color RGB data of
three bits per pixel, a 175 by 175 pixel RAM would use all of the 92K on-chip
memory and no memory would be left for the remainder of the design.
Pixel memory must always be in read mode whenever RGB data is displayed.
To avoid flicker and memory access conflicts on single port memory, designs
should update pixel RAM and other signals that produce the RGB output,
during the time the RGB data is not being displayed.
When the scan of each horizontal line is complete there are typically over 100
clock cycles before the next RGB value is needed, as seen in Figure 10.9.
Additional clocks are available when a vertical sync signal resets the monitor to
the first display line. The exact number of clocks available depends on the
video resolution and refresh rate.
In most cases, calculations that change the video image should be performed
during this off-screen period of time to avoid memory conflicts with the
readout of video RAM or other registers which are used to produce the RGB
video pixel color signals. Since on-chip pixel memory is limited, complex
graphic designs with higher resolutions will require another approach.
Horizontal Sync Counter
0 639 799
Display Compute
RGB New RGB
Data Data
On Screen During
Retrace
479
524
Vertical Sync Counter
Figure 10.9 Display and Compute clock cycles available in a single 640 by 480 Video Frame.
VGA Video Display Generation 207
10.12 Video Data Compression
Here are some ideas to save memory and produce more complex graphics.
Compress the video pixel data in memory and uncompress it on-the-fly as the
video signal is generated. One compression technique that works well is run
length encoding (RLE). The RLE compression technique only requires a simple
state machine and a counter for decoding.
In RLE, the pixels in the display are encoded into a sequence of length and
color fields. The length field specifies the number of sequentially scanned
pixels with the same color. In simple color images, substantial data
compression can be achieved with RLE and it is used in PCs to encode color
bitmaps. Matlab can be used to read bitmaps into a two-dimensional array and
then write the output as an RLE encoded version directly to a *.mif file. An
example program is available on the DVD. Bitmap file formats and some C
utilities to help read bitmaps can be found on the web.
Many early video games, such as Pong, have a background color with a few
moving images. In such cases, the background image can be the default color
value and not stored in video RAM. Hardware comparators can check the row
and column counts as the video signal is generated and detect when another
image other than the background should be displayed. When the comparator
signals that the row and column count matches the image location, the image’s
color data instead of the normal background data is switched into the RGB
output using gates or a multiplexer.
The image can be made to move if its current row and column location is stored
in registers and the output of these registers are used as the comparator input.
Additional logic can be used to increment or decrement the image’s location
registers slowly over time and produce motion. Multiple hardware comparators
can be used to support several fixed and moving images. These moving images
are also called sprites. This approach was used in early-generation video
games.
10.13 Video Color Mixing using Dithering
PC graphics cards use an analog to digital converter to drive the analog RGB
color signals. Although the hardware directly supports only eight different pixel
colors using digital color signals, there are some techniques that can be used to
generate more colors. On analog CRTs, pixels can be overclocked at two to four
times the normal rate to turn on and off the 1-bit color signal several times
while scanning across a single pixel. The FPGA’s PLL is handy to generate the
higher frequency clocks need. Along the same lines, anding the final color
signal output with the clock signal itself can further reduce the signal’s on time
to ½ a clock or less. Unfortunately, this technique does not work quite as well
on LCD monitors due to the differences in the internal electronics.
The screen is refreshed at 60Hz, but flicker is almost undetected by the human
eye at 30Hz. So, in odd refresh scans one pixel color is used and in even refresh
scans another pixel color is used. This 30Hz color mixing or dithering
technique works best if large areas have both colors arranged in a checkerboard
pattern. Alternating scans use the inverse checkerboard colors. At 30Hz, the eye
208 Rapid Prototyping of Digital Systems Chapter 10
can detect color intensity flicker in large regions unless the alternating
checkerboard pattern is used.
10.14 VHDL Graphics Display Design Example
This simple graphics example will generate a ball that bounces up and down on
the screen. As seen in Figure 10.10, in the VGA_BALL project the ball is red
and the background is white. This example requires the VGA_SYNC design
from Section 10.4 to generate the video sync and the pixel address signals. The
pixel_row signal is used to determine the current row and the pixel_column
signal determines the current column. Using the current row and column
addresses, the process Display_Ball generates the red ball on the white
background and produces the ball_on signal which displays the red ball using
the logic in the red, green, and blue equations.
Figure 10.10 Bouncing Ball Video Output.
Ball_X_pos and Ball_y_pos are the current address of the center of the ball.
Size is the size of the square ball.
The process Move_Ball moves the ball a few pixels every vertical sync and
checks for bounces off of the walls. Ball_motion is the number of pixels to
move the ball at each vertical sync clock. The VGA_SYNC core is also used to
generate sync signals and pixel addresses, but is not shown in the code below.
ENTITY ball IS
PORT(
SIGNAL Red, Green, Blue : OUT STD_LOGIC;
SIGNAL vert_sync_out : IN STD_LOGIC;
SIGNAL pixel_row, pixel_column : IN STD_LOGIC_VECTOR( 9 DOWNTO 0 ));
END ball;
ARCHITECTURE behavior OF ball IS
-- Video Display Signals
SIGNAL reset, Ball_on, Direction : STD_LOGIC;
SIGNAL Size : STD_LOGIC_VECTOR( 9 DOWNTO 0 );
SIGNAL Ball_Y_motion : STD_LOGIC_VECTOR( 9 DOWNTO 0 );
SIGNAL Ball_Y_pos, Ball_X_pos : STD_LOGIC_VECTOR( 9 DOWNTO 0 );
VGA Video Display Generation 209
BEGIN -- Size of Ball
Size <= CONV_STD_LOGIC_VECTOR (8,10 );
-- Ball center X address
Ball_X_pos <= CONV_STD_LOGIC_VECTOR( 320,10 );
-- Colors for pixel data on video signal
Red <= '1'; -- Turn off Green and Blue to make
-- color Red when displaying ball
Green <= NOT Ball_on;
Blue <= NOT Ball_on;
Display_Ball:
PROCESS ( Ball_X_pos, Ball_Y_pos, pixel_column, pixel_row, Size )
BEGIN -- check row & column for ball area
-- Set Ball_on = '1' to display ball
IF ( ‘0’ & Ball_X_pos <= pixel_column + Size ) AND
( Ball_X_pos + Size >= ‘0’ & pixel_column ) AND
( ‘0’ & Ball_Y_pos <= pixel_row + Size ) AND
( Ball_Y_pos + Size >= ‘0’ & pixel_row ) THEN
Ball_on <= '1';
ELSE
Ball_on <= '0';
END IF;
END PROCESS Display_Ball;
Move_Ball:
PROCESS
BEGIN
-- Move ball once every vertical sync
WAIT UNTIL Vert_sync'EVENT AND Vert_sync = '1';
-- Bounce off top or bottom of screen
IF (‘0’ & Ball_Y_pos) >= CONV_STD_LOGIC_VECTOR(480,10) - Size THEN
Ball_Y_motion <= CONV_STD_LOGIC_VECTOR(-2,10);
ELSIF Ball_Y_pos <= Size THEN
Ball_Y_motion <= CONV_STD_LOGIC_VECTOR(2,10);
END IF;
-- Compute next ball Y position
Ball_Y_pos <= Ball_Y_pos + Ball_Y_motion;
END PROCESS Move_Ball;
END behavior;
10.15 Higher Video Resolution and Faster Refresh Rates
The Video Sync FPGAcore function is designed to support higher resolutions
and refresh rates. The UP2 and UP1 boards can only support their Video Sync
core’s existing 640 by 480 60Hz video mode since it does not have an internal
PLL to produce different pixel clocks. Table 10.3 shows several common
screen resolutions and refresh rates. To change resolutions or refresh rates two
changes are needed. First, change the PLL’s video output pixel clock to the new
frequency value by editing the Video_PLL.vhd file using the MegaWizard edit
feature. Second, the six counter constant values used to generate the horizontal
and vertical sync signals in the Video_Sync.vhd core need to be changed to the
new six values for the desired resolution and refresh rate found in the large
210 Rapid Prototyping of Digital Systems Chapter 10
table at the end of the Video_Sync.vhd file. Keep in mind that higher
resolutions will require more pixel memory and smaller hardware delays that
can support the faster clock rates needed.
Table 10.3 Pixel clock rates for some common video resolutions and refresh rates.
Mode Refresh Hor. Sync Pixel clock
640x480 60Hz 31.5kHz 25.175MHz
640x480 63Hz 32.8kHz 28.322MHz
640x480 70Hz 36.5kHz 31.5MHz
640x480 72Hz 37.9kHz 31.5MHz
800x600 56Hz 35.1kHz 36.0MHz
800x600 60Hz 37.9kHz 40.0MHz
800x600 72Hz 48.0kHz 50.0MHz
1024x768 60Hz 48.4kHz 65.0MHz
1024x768 70Hz 56.5kHz 75.0MHz
1024x768 70Hz 56.25kHz 72.0MHz
1024x768 76Hz 62.5kHz 85.0MHz
1280x1024 61Hz 64.24kHz 110.0MHz
1280x1024 74Hz 78.85kHz 135.0MHz
10.16 Laboratory Exercises
1. Design a video output display that displays a large version of your initials. Hint: use the
character generation ROM, the Video Sync FPGAcore, and some of the higher bits of the
row and column pixel counters to generate larger characters.
2. Modify the bouncing ball example to bounce and move in both the X and Y directions.
You will need to add code for motion in two directions and check additional walls for a
bounce condition.
3. Modify the bouncing ball example to move up or down based on input from the two
pushbuttons.
4. Modify the example to support different speeds. Read the speed of the ball from the
FPGA switches.
5. Draw a more detailed ball in the bouncing ball example. Use a small ROM to hold a
small detailed color image of a ball.
6. Make a Pong-type video game by using pushbutton input to move a paddle up and down
that the ball will bounce off of.
7. Design your own video game with graphics. Some ideas include breakout, space
invaders, Tetris, a slot machine, poker, craps, blackjack, pinball, and roulette. Keep the
VGA Video Display Generation 211
graphics simple so that the design will fit on the FPGA chip. If the video game needs a
random number generator, information on random number generation can be found in
Appendix A.
8. Use the character font ROM and the ideas from the MIPS character output example to
add video character output to another complex design.
9. Using Matlab or C, write a program to convert a color bitmap into a *.mif file with run-
length encoding. Design a state machine to read out the memory and generate the RGB
color signals to display the bitmap. Use a reduced resolution pixel size such as 160 by
120. Find a bitmap to display or create one with a paint program. It will work best if the
bitmap is already 160 by 120 pixels or smaller. A school mascot or your favorite cartoon
character might make an interesting choice. Limited internal memory is available in the
FPGA, so a 12-bit RLE format with nine bits for length and three bits for color can be
used with up to 7,600 locations on the UP3. Some boards have more slightly more
memory as seen in Table 2.1. This means that the bitmap can only have several thousand
color changes as the image is scanned across the display. Simple images such as cartoons
have fewer color changes. A Matlab example is on the DVD.
10. Add color mixing or dithering with more than 8 colors to the previous problem. The 3-bit
color code in the RLE encoded memory can be used to map into a color palette. The
color palette contains the RGB patterns used for color mixing or interlacing. On boards
that support more than 8 colors directly in hardware, the color palette value can be used
directly to drive several of the higher RGB output bits. The color palette memory selects
8 different colors. The program translating the bitmap should select the 8 closest colors
for the color palette.
11. Modify the VGA Sync core to support a higher screen resolution and demonstrate it
using one of the earlier example video designs.
CHAPTER 11
Interfacing to the PS/2
Keyboard and Mouse
A PS/2 mouse is shown above with the cover removed. The ball (upper right) rolls two
plastic X and Y axles with a slotted wheel at one end. The slotted wheel passes through a
square slotted case containing an IR emitter and detector pair. When the wheel rotates it
generates pulses by interrupting the IR light beam. A microcontroller (lower left) counts
the pulses and sends data packets containing mouse movement and button data to the PC.
214 Rapid Prototyping of Digital Systems Chapter 11
11 Interfacing to the PS/2 Keyboard and Mouse
The PS/2 interface was originally developed for the IBM PC/AT’s mouse and
keyboard in 1984. The Altera FPGA boards support the use of either a mouse or
keyboard using a PS/2 connector on the board (not both at the same time). This
provides only the basic electrical connections from the PS/2 cable and the
FPGA chip. It is necessary to design a hardware interface using logic in the
FPGA chip to communicate with a keyboard or a mouse. Serial-to-parallel
conversion using a shift register is required in the interface hardware.
11.1 PS/2 Port Connections
The PS/2 port consists of 6 pins including ground, power (VDD), keyboard
data, and a keyboard clock line. The FPGA board supplies the power to the
mouse or keyboard. Two lines are not used. Pins must be specified in one of the
design files.
Table 11.1 PS/2 Keyboard Commands and Messages.
Commands Sent to Keyboard Hex Value
FF
Reset Keyboard
FE
Keyboard returns AA, 00 after self-test FB, XX
Resend Message
Set key typematic (autorepeat) FC, XX
FD, XX
XX is scan code for key FA
Set key make and break F9
Set key make F8
Set all key typematic, make and break F7
Set all keys make F6
Set all keys make and break F4
Make all keys typematic (autorepeat) F3, XX
Set to Default Values
Clear Buffers and start scanning keys F2
Set typematic (autorepeat) rate and delay
F0, XX
Set typematic (autorepeat) rate and delay
Bits 6 and 5 are delay (250ms to 1 sec) EE
Bits 4 to 0 are rate (all 0’s-30x/sec to all 1’s 2x/sec) ED, XX
Read keyboard ID
Keyboard sends FA, 83, AB
Set scan code set
XX is 01, 02, or 03
Echo
Set Keyboard LEDs
XX is 00000 Scroll, Num, and Caps Lock bits
1 is LED on and 0 is LED off
Both the clock and data lines are open collector and bi-directional. The clock
line is normally controlled by the keyboard, but it can also be driven by the
computer system or in this case the FPGA chip, when it wants to stop data
transmissions from the keyboard. Both the keyboard and the system can drive
the data line. The data line is the sole source for the data transfer between the
Interfacing to the PS/2 Keyboard and Mouse 215
computer and keyboard. The keyboard and the system can exchange several
commands and messages as seen in Tables 11.1 and 11.2.
Table 11.2 PS/2 Commands and messages sent by keyboard.
Messages Sent by Keyboard Hex Value
FE
Resend Message FC
Two bad messages in a row
Keyboard Acknowledge Command FA
Sent by Keyboard after each command byte EE
Response to Echo command AA
Keyboard passed self-test 00
Keyboard buffer overflow
11.2 Keyboard Scan Codes
Keyboards are normally encoded by placing the key switches in a matrix of
rows and columns. All rows and columns are periodically checked by the
keyboard encoder or "scanned" at a high rate to find any key state changes. Key
data is passed serially to the computer from the keyboard using what is known
as a scan code. Each keyboard key has a unique scan code based on the key
switch matrix row and column address to identify the key pressed.
There are different varieties of scan codes available to use depending on the
type of keyboard used. The PS/2 keyboard has two sets of scan codes. The
default scan code set is used upon power on unless the computer system sends a
command the keyboard to use an alternate set. The typical PC sends commands
to the keyboard on power up and it uses an alternate scan code set. To interface
the keyboard to the FPGA board, it is simpler to use the default scan code set
since no initialization commands are required.
11.3 Make and Break Codes
The keyboard scan codes consist of 'Make' and 'Break' codes. One make code
is sent every time a key is pressed. When a key is released, a break code is sent.
For most keys, the break code is a data stream of F0 followed by the make code
for the key. Be aware that when typing, it is common to hit the next key(s)
before releasing the first key hit.
Using this configuration, the system can tell whether or not the key has been
pressed, and if more than one key is being held down, it can also distinguish
which key has been released. One example of this is when a shift key is held
down. While it is held down, the '3' key should return the value for the '#'
symbol instead of the value for the '3' symbol. Also note that if a key is held
down, the make code is continuously sent via the typematic rate until it is
released, at which time the break code is sent.
216 Rapid Prototyping of Digital Systems Chapter 11
11.4 The PS/2 Serial Data Transmission Protocol
The scan codes are sent serially using 11 bits on the bi-directional data line.
When neither the keyboard nor the computer needs to send data, the data line
and the clock line are High (inactive).
As seen in Figure 11.1, the transmission of a single key or command consists of
the following components:
1. A start bit ('0')
2. 8 data bits containing the key scan code in low to high bit order
3. Odd parity bit such that the eight data bits plus the parity bit are an odd
number of ones
4. A stop bit ('1')
The following sequence of events occur during a transmission of a command by
the keyboard:
1. The keyboard checks to ensure that both the clock and keyboard lines are
inactive. Inactive is indicated by a High state. If both are inactive, the keyboard
prepares the 'start' bit by dropping the data line Low.
2. The keyboard then drops the clock line Low for approximately 35us.
3. The keyboard will then clock out the remaining 10 bits at an approximate
rate of 70us per clock period. The keyboard drives both the data and clock line.
4. The computer is responsible for recognizing the ‘start’ bit and for receiving
the serial data. The serial data, which is 8 bits, is followed by an odd parity bit
and finally a High stop bit. If the keyboard wishes to send more data, it follows
the 12th bit immediately with the next ‘start’ bit.
This pattern repeats until the keyboard is finished sending data at which point
the clock and data lines will return to their inactive High state.
Clock 0 1 10 1 00 0
Data
8 Data Bits in Low to High Order Odd Parity Stop
Start Scan Code shown is 16H for a “1” character Bit=0 Bit=1
Bit=0 which is keyboard key #2
Figure 11.1 Keyboard Transmission of a Scan Code.
Interfacing to the PS/2 Keyboard and Mouse 217
In Figure 11.1 the keyboard is sending a scan code of 16 for the "1" key and it
has a zero parity bit. When implementing the interface code, it will be
necessary to filter the slow keyboard clock to ensure reliable operation with the
fast logic inside the FPGA chip. Whenever an electrical pulse is transmitted on
a wire, electromagnetic properties of the wire cause the pulse to be distorted
and some portions of the pulse may be reflected from the end of the wire. On
some PS/2 keyboards and mice there is a reflected pulse on the cable that is
strong enough to cause additional phantom clocks to appear on the clock line.
Here is one approach that solves the reflected pulse problem. Feed the PS/2
clock signal into an 8-bit shift register that uses a 24MHz clock. AND the bits
of the shift register together and use the output of the AND gate as the new
"filtered" clock. This prevents noise and ringing on the clock line from causing
occasional extra clocks during the serial-to-parallel conversion in the FPGA
chip.
A few keyboards and mice will work without the clock filter and many will not.
They all will work with the clock filter, and it is relatively easy to implement.
This circuit is included in the FPGAcores for the keyboard and the mouse. Pin
assignments for the various FPGA boards are seen in Table 11.3
Table 11.3 The PS/2 Keyboard or Mouse Pin Assignments
Pin Name DE1 DE2 UP3 UP2, Pin Function of Pin
UP1 Type
PS2_CLK H15 D26 12 PS2 Connector
PS2_DATA J14 C24 13 30 Bidir. PS2 Connector
31 Bidir.
As seen in Figure 11.2, the computer system or FPGA chip in this case sends
commands to the PS/2 keyboard as follows:
1. System drives the clock line Low for approximately 60us to inhibit any new
keyboard data transmissions. The clock line is bi-directional.
2. System drives the data line Low and then releases the clock line to signal
that it has data for the keyboard.
3. The keyboard will generate clock signals in order to clock out the remaining
serial bits in the command.
4. The system will send its 8-bit command followed by a parity bit and a stop
bit.
5. After the stop bit is driven High, the data line is released.
Upon completion of each command byte, the keyboard will send an
acknowledge (ACK) signal, FA, if it received the data successfully. If the
system does not release the data line, the keyboard will continue to generate the
clock, and upon completion, it will send a ‘re-send command’ signal, FE or FC,
to the system. A parity error or missing stop bit will also generate a re-send
command signal.
218 Rapid Prototyping of Digital Systems Chapter 11
Clock
Data
Inhibit 0 0 10 1 1 1 1
I/O
8 Data Bits in Low to High Order Odd Parity Stop
System Data Command Code shown is F4H Bit=0 Bit=1
Ready
to Send=0
Figure 11.2 System Transmission of a Command to PS/2 Device.
11.5 Scan Code Set 2 for the PS/2 Keyboard
PS/2 keyboards are available in several languages with different characters
printed on the keys. A two-step process is required to find the scan code. A key
number is used to lookup the scan code. Key numbers needed for the scan code
table are shown in Figure 11.3 for the English language keyboard layout.
ESC F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 Print Scroll Pause
110 112 113 114 115 116 117 118 119 120 121 122 123 Scrn Lock
125 126
124
~ ` ! 1 @ 2 #3 $4 %5 ^6 &7 *8 ( 9 ) 0 -_ =+ Backspace Insert Home Pg Up Num / *-
1 2 3 4 5 6 7 8 9 10 11 12 13 15 75 80 85 Lock 95 100 105
Del End Pg Dn 90
Tab Q W E R T Y U I O P [ { ]} \| 76 81 86 8 9 +
16 17 18 19 20 21 22 23 24 25 26 27 28 29 7 96 Pg Up
83 Home
101
79 84 89 91
Caps Lock A S D F G H J K L ; : ‘“ Enter 45 6
30 31 32 33 34 35 36 37 38 39 40 41 43 76 97 102 106
Shift Z X C V B N M ,< .> /? Shift 1 2 3 Enter
44 46 47 48 49 50 51 52 53 54 55 57 End Pg Dn
93 98
103
Ctrl Alt Alt Ctrl 0 Ins . Del
99 104
58 60 61 62 64 108
Figure 11.3 Key Numbers for Scan Code.
Each key sends out a make code when hit and a break code when released.
When several keys are hit at the same time, several make codes will be sent
before a break code.
Interfacing to the PS/2 Keyboard and Mouse 219
The keyboard powers up using this scan code as the default. Commands must
be sent to the keyboard to use other scan code sets. The PC sends out an
initialization command that forces the keyboard to use the other scan code.
The interface is much simpler if the default scan code is used. If the default
scan code is used, no commands will need to be sent to the keyboard. The keys
in Table 11.4 for the default scan code are typematic (i.e. they automatically
repeat the make code if held down).
Table 11.4 Scan Codes for PS/2 Keyboard.
Key# Make Break Key# Make Break Key# Make Break
Code Code Code Code Code Code
1 31 90
2 0E F0 0E 32 1C F0 1C 91 77 F0 77
3 16 F0 16 33 1B F0 1B 92 6C F0 6C
4 1E F0 1E 34 23 F0 23 93 6B F0 6B
5 26 F0 26 35 2B F0 2B 96 69 F0 69
6 25 F0 25 36 34 F0 34 97 75 F0 75
7 2E F0 2E 37 33 F0 33 98 73 F0 73
8 36 F0 36 38 3B F0 3B 99 72 F0 72
9 3D F0 3D 39 42 F0 42 100 70 F0 70
10 3E F0 3E 40 4B F0 4B 101 7C F0 7C
11 46 F0 46 41 4C F0 4C 102 7D F0 7D
12 45 F0 45 43 52 F0 52 103 74 F0 74
13 4E F0 4E 44 5A F0 5A 104 7A F0 7A
15 55 F0 55 46 12 F0 12 105 71 F0 71
16 66 F0 66 47 1A F0 1A 106 7B F0 7B
17 0D F0 0D 48 22 F0 22 110 79 F0 79
18 15 F0 15 49 21 F0 21 112 76 F0 76
19 1D F0 1D 50 2A F0 2A 113 05 F0 05
20 24 F0 24 51 32 F0 32 114 06 F0 06
21 2D F0 2P 52 31 F0 31 115 04 F0 04
22 2C F0 2C 53 3A F0 3A 116 0c F0 0C
23 35 F0 35 54 41 F0 41 117 03 F0 03
24 3C F0 3C 55 49 F0 49 118 0B F0 0B
25 43 F0 43 57 4A F0 4A 119 83 F0 83
26 44 F0 44 58 59 F0 59 120 0A F0 0A
27 4D F0 4D 60 14 F0 14 121 01 F0 01
28 54 F0 54 61 11 F0 11 122 09 F0 09
29 5B F0 5B 62 29 F0 29 123 78 F0 78
5D F0 5D E0 11 E0 F0 11 07 F0 07
The remaining key codes are a function of the shift, control, alt, or num-lock keys.
220 Rapid Prototyping of Digital Systems Chapter 11
Table 11.4 (Continued) - Scan Codes for PS/2 Keyboard.
Key No Shift or Shift* Num Lock On
Num Lock
# Make Break Make Break Make Break
76 E0 70 E0 F0 70 E0 F0 12 E0 70 E0 F0 70 E0 12 E0 12 E0 70 E0 F0 70 E0 F0 12
76 E0 71 E0 F0 71 E0 F0 12 E0 71 E0 F0 71 E0 12 E0 12 E0 71 E0 F0 71 E0 T0 12
79 E0 6B E0 F0 6B E0 F0 12 E0 6B E0 F0 6B E0 12 E0 12 E0 6B E0 F0 6B E0 F0 12
80 E0 6C E0 F0 6C E0 F0 12 E0 6C E0 F0 6C E0 12 E0 12 E0 6C E0 F0 6C E0 F0 12
81 E0 69 E0 F0 69 E0 F0 12 E0 69 E0 F0 69 E0 12 E0 12 E0 69 E0 F0 69 E0 F0 12
83 E0 75 E0 F0 75 E0 F0 12 E0 75 E0 F0 75 E0 12 E0 12 E0 75 E0 F0 75 E0 F0 12
84 E0 72 E0 F0 72 E0 F0 12 E0 72 E0 F0 72 E0 12 E0 12 E0 72 E0 F0 72 E0 F0 12
85 E0 7D E0 F0 7D E0 F0 12 E0 7D E0 F0 7D E0 12 E0 12 E0 7D E0 F0 7D E0 F0 12
86 E0 7A E0 F0 7A E0 F0 12 E0 7A E0 F0 7A E0 12 E0 12 E0 7A E0 F0 7A E0 F0 12
89 E0 74 E0 F0 74 E0 F0 12 E0 74 E0 F0 74 E0 12 E0 12 E0 74 E0 F0 74 E0 F0 12
* When the left Shift Key is held down, the 12 - FO 12 shift make and break is sent with the other scan
codes. When the right Shift Key is held down, 59 – FO 59 is sent.
Key Scan Code Shift Case *
# Make Break Make Break
95 E0 4A E0 F0 4A E0 F0 12 E0 4A E0 12 F0 4A
* When the left Shift Key is held down, the 12 - FO 12 shift make and break is sent with the other scan
codes. When the right Shift Key is held down, 59 - FO 59 is sent. When both Shift Keys are down, both
sets of codes are sent with the other scan codes.
Key Scan Code Control Case, Shift Case Alt Case
Make Break
# Make Break Make Break
84 F0 84
124 E0 12 E0 7C E0 F0 7C E0 F0 I2 E0 7C E0 F0 7C
Key # Make Code Control Key Pressed
E0 7E E0 F0 7E
126 * El 14 77 El F0 14 F0 77
* This key does not repeat
11.6 The Keyboard FPGAcore
The following VHDL code for the keyboard FPGAcore shown in Figure 11.4
reads the scan code bytes from the keyboard. In this example code, no
command is ever sent to the keyboard, so clock and data are always used as
inputs and the keyboard power-on defaults are used.
To send commands, a more complex bi-directional tri-state clock and data
interface is required. The details of such an interface are explained in later
sections on the PS/2 mouse. The keyboard powers up and sends the self-test
code AA and 00 to the FPGA chip before it is downloaded.
Interfacing to the PS/2 Keyboard and Mouse 221
key board scan_code[7..0]
scan_ready
key board_clk
key board_data
clock_48Mhz
reset
read
inst
Figure 11.4 Keyboard FPGAcore
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.STD_LOGIC_ARITH.ALL;
USE IEEE.STD_LOGIC_UNSIGNED.ALL;
ENTITY keyboard IS
PORT( keyboard_clk, keyboard_data, clock_48MHz ,
reset, read : IN STD_LOGIC;
scan_code : OUT STD_LOGIC_VECTOR( 7 DOWNTO 0 );
scan_ready : OUT STD_LOGIC);
END keyboard;
ARCHITECTURE a OF keyboard IS : STD_LOGIC_VECTOR( 3 DOWNTO 0 );
SIGNAL INCNT : STD_LOGIC_VECTOR( 8 DOWNTO 0 );
SIGNAL SHIFTIN : STD_LOGIC;
SIGNAL READ_CHAR, clock_enable : STD_LOGIC;
SIGNAL INFLAG, ready_set : STD_LOGIC;
SIGNAL keyboard_clk_filtered : STD_LOGIC_VECTOR( 7 DOWNTO 0 );
SIGNAL filter
BEGIN
PROCESS ( read, ready_set )
BEGIN
IF read = '1' THEN
scan_ready <= '0';
ELSIF ready_set'EVENT AND ready_set = '1' THEN
scan_ready <= '1';
END IF;
END PROCESS;
--This process filters the raw clock signal coming from the
-- keyboard using a shift register and two AND gates
Clock_filter:
PROCESS
BEGIN
WAIT UNTIL clock_48MHz'EVENT AND clock_48MHz = '1';
clock_enable <= NOT clock_enable;
IF clock_enable = ‘1’ THEN
filter ( 6 DOWNTO 0 ) <= filter( 7 DOWNTO 1 ) ;
222 Rapid Prototyping of Digital Systems Chapter 11
filter( 7 ) <= keyboard_clk;
IF filter = "11111111" THEN
keyboard_clk_filtered <= '1';
ELSIF filter = "00000000" THEN
keyboard_clk_filtered <= '0';
END IF;
END IF;
END PROCESS Clock_filter;
--This process reads in serial scan code data coming from the keyboard
PROCESS
BEGIN
WAIT UNTIL (KEYBOARD_CLK_filtered'EVENT AND KEYBOARD_CLK_filtered = '1');
IF RESET = '0' THEN
INCNT <= "0000";
READ_CHAR <= '0';
ELSE
IF KEYBOARD_DATA = '0' AND READ_CHAR = '0' THEN
READ_CHAR <= '1';
ready_set <= '0';
ELSE
-- Shift in next 8 data bits to assemble a scan code
IF READ_CHAR = '1' THEN
IF INCNT < "1001" THEN
INCNT <= INCNT + 1;
SHIFTIN( 7 DOWNTO 0 ) <= SHIFTIN( 8 DOWNTO 1 );
SHIFTIN( 8 ) <= KEYBOARD_DATA;
ready_set <= '0';
-- End of scan code character, so set flags and exit loop
ELSE
scan_code <= SHIFTIN( 7 DOWNTO 0 );
READ_CHAR <='0';
ready_set <= '1';
INCNT <= "0000";
END IF;
END IF;
END IF;
END IF;
END PROCESS;
END a;
The keyboard clock is filtered in the Clock_filter process using an 8-bit shift
register and an AND gate to eliminate any reflected pulses, noise, or timing
hazards that can be found on some keyboards. The clock signal in this process
is the 48 MHz system clock divided by two to produce a 24 MHz clock rate
using the clock enable signal. On DE1 and DE2 boards, a 50Mhz clock input is
used. The output signal, keyboard_clk_filtered, will only change if the input
signal, keyboard_clk, has been High or Low for eight successive 24 MHz
clocks or 320ns. This filters out noise and reflected pulses on the keyboard
cable that could cause an extra or false clock signal on the fast FPGA chip. This
problem has been observed to occur on some PS/2 keyboards and mice and is
fixed by the filter routine.
Interfacing to the PS/2 Keyboard and Mouse 223
The RECV_KBD process waits for a start bit, converts the next eight serial data
bits to parallel, stores the input character in the signal, charin, and sets a flag,
scan_ready, to indicate a new character was read. . The scan_ready or input
ready flag is a handshake signal needed to ensure that a new scan code is read
in and processed only once. Scan_ready is set whenever a new scan code is
received. The input signal, read, resets the scan ready handshake signal.
The process using this code to read the key scan code would need to wait until
the input ready flag, scan_ready, goes High. This process should then read in
the new scan code value, scan_code. Last, read should be forced High and Low
to clear the scan_ready handshake signal.
Since the set and reset conditions for scan_ready come from different processes
each with different clocks, it is necessary to write a third process to generate
the scan_ready handshake signal using the set and reset conditions from the
other two processes. Hitting a common key will send a 1-byte make code and a
2-byte break code. This will produce at least three different scan_code values
each time a key is hit and released.
A shift register is used with the filtered clock signals to perform the serial to
parallel conversion. No command is ever sent the keyboard and it powers up
using scan code set 2. Since commands are not sent to the keyboard, in this
example clock and data lines are not bi-directional. The parity bit is not
checked.
11.7 A Design Example Using the Keyboard FPGAcore
Here is a simple design using the Keyboard and LCD_Display FPGAcores. The
last six bytes of scan codes will appear in the LCD display (or on some FPGA
boards in the seven segment LEDs). The block code_FIFO saves the last six
scan codes for the LCD display and is not used on the FPGA boards with a two
digit hex LED display.
PS2_CLK VCC key board scan_code[7..0]
PS2_DATA BIDIR scan_ready
VCC key board_clk
BIDIR key board_data
clock_48Mhz
reset
read
inst
code_FIFO Hex_Display _Data[39..0]
scan_code[7..0] Hex_display _data[39..0]
scan_ready read
clock_48Mhz
reset
CLK_48Mhz INPUT inst3
VCC
SW8 INPUT LCD_Display LCD_RS OUTPUT LCD_RS
VCC reset LCD_E OUTPUT LCD_E
Hex_Display _Data[39..0] clk_48Mhz OUTPUT LCD_RW
Hex_Display _Data[num_hex_digits*4-1..0] LCD_RW BIDIR DATA_BUS[7..0]
DATA_BUS[7..0] VCC
inst1
Figure 11.5 Example design using the Keyboard FPGAcore.
224 Rapid Prototyping of Digital Systems Chapter 11
11.8 Interfacing to the PS/2 Mouse
Just like the PS/2 keyboard, the PS/2 mouse uses the PS/2 synchronous bi-
directional serial communication protocol described in section 11.4 and shown
in Figures 11.1 and 11.2. Internally, the mouse contains a ball that rolls two
slotted wheels. The wheels are connected to two optical encoders. The two
encoders sense x and y motion by counting pulses when the wheels move. It
also contains two or three pushbuttons that can be read by the system and a
single-chip microcontroller. The microcontroller in the mouse sends data
packets to the computer reporting movement and button status.
It is necessary for the computer or in this case the FPGA chip to send the mouse
an initialization command to have it start sending mouse data packets. This
makes interfacing to the mouse more difficult than interfacing to the keyboard.
As seen in Table 11.5, the command value needed for initialization after power
up is F4, enable streaming mode.
Table 11.5 PS/2 Mouse Commands.
Commands Sent to Mouse Hex Value
FF
Reset Mouse
Mouse returns AA, 00 after self-test FE
F6
Resend Message F4
Set to Default Values
Enable Streaming Mode F5
F3, XX
Mouse starts sending data packets at default rate
Disable Streaming Mode F2
Set sampling rate EE
EC
XX is number of packets per second
Read Device Type EB
Set Remote Mode
Set Wrap Mode EA
E9
Mouse returns data sent by system
Read Remote Data E8, XX
Mouse sends 1 data packet E7
Set Stream Mode E6
Status Request
Mouse returns 3-bytes with current settings
Set Resolution
XX is 0, 1, 2, 3
Set Scaling 2 to 1
Reset Scaling
Interfacing to the PS/2 Keyboard and Mouse 225
Table 11.6 PS/2 Mouse Messages. Hex Value
FE
Messages Sent by Mouse FC
Resend Message FA
Two bad messages in a row
Mouse Acknowledge Command AA
Sent by Mouse after each command byte
Mouse passed self-test
After streaming mode is enabled, the mouse sends data to the system in three
byte data packets that contain motion and pushbutton status. The format of a
three-byte mouse data packet is seen in Table 11.7.
Table 11.7 PS/2 Mouse Data Packet Format.
MSB LSB
Bit 7 6 5 4 3 2 1 0
Byte 1 Yo Xo Ys Xs 1 M R L
Byte 2 X7 X6 X5 X4 X3 X2 X1 X0
Byte 3 Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0
L = Left Key Status bit ( For buttons 1 = Pressed and 0 = Released )
M = Middle Key Status bit ( This bit is reserved in the standard PS/2 mouse protocol, but
some three button mice use the bit for middle button status.)
R = Right Key Status bit
X7– X0 = Moving distance of X in two’s complement
( Moving Left = Negative; Moving Right = Positive )
Y7 – Y0 = Moving distance of Y in two’s complement
( Moving Up = Positive; Moving Down = Negative )
Xo= X Data Overflow bit ( 1 = Overflow )
Yo= Y Data Overflow bit ( 1 = Overflow )
Xs = X Data sign bit ( 1 = Negative )
Ys = Y Data sign bit ( 1 = Negative )
226 Rapid Prototyping of Digital Systems Chapter 11
11.9 The Mouse FPGAcore
The FPGAcore function Mouse is designed to provide a simple interface to the
mouse. This function initializes the mouse and then monitors the mouse data
transmissions. It outputs a mouse cursor address and button status. The internal
operation of the Mouse FPGAcore is rather complex and the fundamentals are
described in the section that follows. Like the other FPGAcore functions, it is
written in VHDL and complete source code is provided.
MOUSE mouse_data
mouse_clk
clock_48Mhz lef t_button
reset right_button
mouse_cursor_row[9..0]
mouse_cursor_column[9..0]
inst
To interface to the mouse, a clock filter, serial-to-parallel conversion and
parallel-to-serial conversion with two shift registers is required along with a
state machine to control the various modes. See the earlier PS/2 keyboard
section for an example of a clock filter design.
11.10 Mouse Initialization
Two lines are used to interface to the mouse, PS/2 clock and data. The lines
must be tri-state bi-directional, since at times they are driven by the mouse and
at other times by the FPGA chip. All clock, data, and handshake signals share
two tri-state, bi-directional lines, clock and data. These two lines must be
declared bi-directional when pin assignments are made and they must have tri-
state outputs in the interface. The mouse actually has open collector outputs
that can be simulated by using a tri-state output. The mouse always drives the
clock signal for any serial data exchanges. The FPGA chip can inhibit mouse
transmissions by pulling the clock line Low at any time.
The FPGA chip drives the data line when sending commands to the mouse.
When the mouse sends data to the FPGA chip it drives the data line. The tri-
state bi-directional handshaking is described in more detail in the IBM PS/2
Technical Reference manual. A simpler version with just the basics for
operation with the FPGA boards is presented here. Just like the keyboard, the
mouse interface is more reliable if a clock filter is used on the clock line.
At power-up, the mouse runs a self-test and sends out the codes AA and 00. The
clock and data FPGA chip outputs are tri-stated before downloading the board,
so they float High. High turns out to be ready to send for mouse data, so AA
Interfacing to the PS/2 Keyboard and Mouse 227
and 00 are sent out prior to downloading and need not be considered in the
interface. This assumes that the mouse is plugged in before applying power to
the UP3 board and downloading the design.
The default power-up mode is streaming mode disabled. To get the mouse to
start sending 3-byte data packets, the streaming mode must be turned on by
sending the enable streaming mode command, F4, to the mouse from the FPGA
chip. The clock tri-state line is driven Low by the FPGA for at least 60us to
inhibit any data transmissions from the mouse. This is the only case when the
FPGA chip should ever drive the clock line. The data line is then driven Low
by the FPGA chip to signal that the system has a command to send the mouse.
Clock
Data
Inhibit 0 0 10 1 1 1 1
I/O
8 Data Bits in Low to High Order Odd Parity Stop
System Data Command Code shown is F4H Bit=0 Bit=1
Ready
to Send=0
Figure 11.6 Transmission of Mouse Initialization Command.
The clock line is driven High for four clocks at 24 MHz and then tri-stated to
simulate an open collector output. This reduces the rise time and reflections on
the mouse cable that might be seen by the fast FPGA chip logic as the clock
line returns to the High state. As an alternative, the mouse clock input to the
FPGA could be briefly disabled while the clock line returns to the High state.
Next the mouse, seeing data Low and clock High, starts clocking in the serial
data from the FPGA chip. The data is followed by an odd parity bit and a High
stop bit. The handshake signal of the data line starting out Low takes the place
of the start bit when sending commands to the mouse.
With the FPGA chip clock and data drivers both tri-stated, the mouse then
responds to this message by sending an acknowledge message code, FA, back
to the FPGA chip. Data from the mouse includes a Low start bit, eight data bits,
an odd parity bit, and a High stop bit. The mouse, as always, drives the clock
line for the serial data transmission. The mouse is now initialized.
11.11 Mouse Data Packet Processing
As long as the FPGA chip clock and data drivers remain tri-stated, the mouse
then starts sending 3-byte data packets at the power-up default sampling rate of
100 per second. Bytes 2 and 3 of the data packet contain X and Y motion values
as was seen in Table 11.6. These values can be positive or negative, and they
are in two’s complement format.
228 Rapid Prototyping of Digital Systems Chapter 11
For a video mouse cursor such as is seen in the PC, the motion value will need
to be added to the current value every time a new data packet is received.
Assuming 640 by 480 pixel resolution, two 10-bit registers containing the
current cursor row and column addresses are needed. These registers are
updated every packet by adding the sign extended 8-bit X and Y motion values
found in bytes 2 and 3 of the data packet. The cursor normally would be
initialized to the center of the video screen at power-up.
11.12 An Example Design Using the Mouse FPGAcore
In this example design, the mouse drives the LCD display on the DE2 or UP3
boards. The mouse cursor powers up to the center position of the 640 by 480
video screen. Note that the PS/2 mouse clock and data pins must be bi-
directional. The block Mouse_LCD_interface rearranges the mouse core output
signals for use by the LCD_Display core function. On FPGA boards without an
LCD module, the seven segment LED displays are used instead.
MOUSE mouse_data BIDIR PS2_DATA
mouse_clk VCC PS2_CLK
clock_48Mhz lef t_button BIDIR
reset right_button VCC
mouse_cursor_row[9..0] right_button lef t_button
mouse_cursor_column[9..0]
CLK_48Mhz INPUT inst1
SW8 VCC
INPUT LCD_Display LCD_RS OUTPUT LCD_RS
VCC reset LCD_E OUTPUT LCD_E
clk_48Mhz OUTPUT LCD_RW
Hex_Display _Data[num_hex_digits*4-1..0] LCD_RW BIDIR DATA_BUS[7..0]
DATA_BUS[7..0] VCC
inst
mouse_LCD_interf ace Hex_Display _Data[23..0]
lef t_button mouse_cursor_row[9..0]
mouse_cursor_column[9..0]
right_button lef t_button
right_button
inst3
Figure 11.7 Example design using the Mouse FPGAcore.
Interfacing to the PS/2 Keyboard and Mouse 229
11.13 For Additional Information
The IBM PS/2 Hardware Interface Technical Reference Manual, IBM
Corporation, 1988 contains the original PS/2 information on the keyboard and
mouse in the Keyboard and Auxiliary Device Controller Chapter. Scan codes
for the alternate scan code set normally used by the PC can be found on the
web and in many PC reference manuals.
11.14 Laboratory Exercises
1. Write a VHDL module to read a keyboard scan code and display the entire scan code
string in hexadecimal on the VGA display using the VGA_SYNC and CHAR_ROM
FPGAcores. It will require the use of the read and scan ready handshake lines and a small
RAM to hold the scan code bytes.
2. After reading the section on the PS/2 mouse, design an interface that can also send
commands to the keyboard. Demonstrate that the design works correctly by changing the
status of the keyboard LEDs after reading the new settings from switches.
3. Develop a keyboard module that uses the alternate scan code set used by the PC.
4. Write the keyboard module in another HDL such as Verilog.
5. Use the keyboard as a new input device for a video game, the μP1 computer, or another
application.
6. Generate a video display that has a moving cursor controlled by the mouse using the
Mouse and VGA_Sync FPGAcores. Use the mouse buttons to change the color of the
cursor.
7. Use the mouse as input to a video etch-a-sketch. Use a monochrome 128 by 128 1-bit
pixel RAM with the VGA_Sync core in your video design. Display a cursor. To draw a
line, the left mouse button should be held down.
8. Use the mouse as an input device in another design with video output or a simple video
game such as pong, breakout, or Tetris.
9. Write a mouse driver in Verilog. Use the mouse information provided in sections 11.2
and 11.3.
CHAPTER 12
Legacy Digital I/O
Interfacing Standards
ASCII “P” = 0x50
00 001010
Mark (1)
Space (0)
Start 0 1 23 45 6 7 Stop
Data Bit number
Bit Bit
LSB Time MSB
The EIA RS-232C standard is widely used in PCs on the COM ports for serial data
transmission.
232 Rapid Prototyping of Digital Systems Chapter 12
12 Legacy Digital I/O Interfacing Standards
Historically, several common digital interface standards have developed over
the years to interface computers to their peripheral devices. This chapter will
introduce several of the older standards and briefly describe how they function
in a hardware design. Each standard has a unique set of hardware and
performance tradeoffs. Many devices and ICs are available that use these
standards. These interfaces are present in most PCs and are found in many
embedded systems including FPGA boards.
12.1 Parallel I/O Interface
The parallel printer interface standard was developed by Centronics in the
1970s and is a widely used standard for transferring 8-bit parallel data. Most
PCs have a parallel port. Data is transferred in parallel using eight data bits and
standard digital logic voltage levels. Additional status and control bits are
required for the sender and receiver to exchange handshake signals that
synchronize each 8-bit data transfer. Typically, the parallel printer port is
interfaced to two 8-bit I/O ports on a processor. One I/O port is used for 8-bit
data transfers and one I/O port for the status and control bits that are used for
handshake signals.
The transfer of an 8-bit data value is shown in Figure 12.1. First, the computer
waits for the printer’s busy signal to go Low. Next, the computer outputs the
eight data bits and the computer then sets strobe Low for at least 0.5us. The
computer then waits for the printer to pulse Ack Low. The computer must wait
for Ack Low before changing the data or strobe lines. The printer may go Busy
after it raises Ack. The printer handshake lines are also used to force the
computer to wait for events like a slow carriage return or page feed on a
mechanical printer or errors like a paper out condition. Sometimes a timeout
loop is used to detect conditions like paper out. The UP3 board has a standard
printer parallel port connector. With the appropriate hardware, it can be used to
communicate with a standard printer.
In addition to printers, some special purpose devices also use the individual
parallel port bits in a number of different ways to output digital logic bits to
control external hardware. The ByteBlaster adapter you use to program the
FPGA is one such example.
The original parallel interface supported only unidirectional data transfers from
a computer to a printer. Recent parallel port standards such as IEEE 1284 ECP
and EPP support bidirectional and faster data transfers between an external
device and the computer. In these newer modes, another control bit from the
computer specifies the data transfer direction and tri-state gate outputs are used
in both the computer and printer to drive the data lines bidirectionally.
Parallel cables will only work for relatively short distances. The RS-232C
standard in the next section supports longer cables with fewer wires, but it also
has lower bandwidth and data transfer rates.
Legacy Digital I/O Interface Standards 233
Data Lines Data Valid
Busy
nStrobe
nAck 4
123
Figure 12.1 Parallel Port transfer of an 8-bit data value
12.2 RS-232C Serial I/O Interface
The Electronics Industry Association (EIA) RS-232C Serial interface is one of
the oldest serial I/O standards. In Europe, is it also called V.24. 8-bit data is
transmitted one bit at a time serially. Most PCs have an RS-232C serial COM
port. Serial interfaces have an advantage in that they require fewer wires in the
cable than a parallel interface and can support longer cables. In RS-232C’s
simplest implementation, only three wires are used in the cable. One wire for
transmit data (TD), one for receive data (RD) and one for signal ground (GND).
Individual bits are clocked in and out serially using a clock signal. The
frequency of this bit clock is called the serial interface’s baud rate. (Baudot was
a French engineer that developed an early serial interface for the telegraph.)
Since two different signal wires are used for receive and transmit, serial devices
can be transferring data in both directions at the same time (full-duplex). The
ASCII character code is typically used on serial devices, but they can also be
used to transfer 8-bit binary values.
The baud rate clock is not synchronized by using a signal wire connected
between the sending and receiving devices, rather it is asynchronous and is
derived by a state machine watching the serial data bit transitions occurring at
the receiver. For this to function correctly, the transmitter and receiver must be
setup to operate at the same clock or baud rate. Even though they have the same
clock rate, the clock phase must still be synchronized between a serial
transmitter and receiver by examining the incoming serial data line. The
hardware logic circuit needed for this common serial interface is called a
Universal Asynchronous Receiver Transmitter (UART).
The words you are searching are inside this book. To get more targeted content, please make full-text search by clicking here.
31_Michel_J.F._Digonnet_Rapid_Prototyping_of_Digita_428_2008
Discover the best professional documents and content resources in AnyFlip Document Base.
Search