Digital Systems Laboratory 4/MSc
ELEE10023/PGEE11117
School of Engineering, University of Edinburgh
Course Description
Aim: The course aims to produce students who are capable of developing hardware-software
digital systems from high level functional specifications and prototyping them on to FPGA
hardware using a standard hardware description language and software programming language.
Pre-requisites: Digital Systems Laboratory 3 (ELEE09018) or Digital Systems Laboratory A
(PGEE10017) or equivalent in other schools and outside institutions (see below). Engineering
Software 3 or equivalent is advisable but not necessary.
Co-requisites: Undergraduate students must take Digital System Design 4 (ELEE10007)
Prohibited Combinations: None
Visiting Students Pre-requisites: Digital design using Verilog, and embedded system
programming.
Keywords: Embedded Digital System Design, Embedded Processor Programming, Verilog,
Data path and Control Path design, Hardware-Software Co-design
Default Course Mode of Study: Lab only, 10 weekly 3-hr lab sessions
Default Delivery Period: Semester 2, starting in Week 2.
Learning Outcomes:
1. Knowledge and understanding of:
I. Data paths and Control paths and number of ways of designing them;
II. Instruction-set based control path design;
III. Control and data path integration;
IV. Capture the design of hardware-software digital systems in a standard hardware
description language;
2. Intellectual
I. Ability to use and choose between different techniques for digital system design
and capture;
II. Ability to evaluate implementation results (e.g. speed, area, power) and correlate
them with the corresponding high level design and capture;
3. Practical
I. Ability to use a commercial digital system development tool suite to develop
hardware-software digital systems and prototype them on to FPGA hardware;
2
Lab Content, What You Are Required To Do
You are required to develop a microprocessor-based system on FPGA with a demo application,
written in software running on the microprocessor, which controls toy race-cars remotely.
Students will be split into groups of two students each to tackle this problem. The final system
will allow a user to simulate controlling cars remotely using a mouse, a VGA screen, and the
BASYS 3 FPGA board as illustrated in the figure below.
Figure 1. Proposed System for FPGA-Based Remote Car Control
A user will be able to hover a mouse pointer over a VGA screen with the position of the mouse
pointer on screen commanding the movement of the remote car as illustrated in the following
figure.
3
Figure 2. Car movement (command) depending on mouse pointer position
The FPGA-based system will consist of a simple microprocessor, a VGA interface, and a mouse
interface, in addition to other peripherals which will be detailed later on this document. An
Infra-Red (IR) Transmitter interface can be added (As A Bonus) to control a toy car. Each team
member will first develop one of the following peripherals, individually: VGA interface, or
mouse interface. The whole group will then collaborate to develop the microprocessor at the
heart of the proposed system with all necessary peripherals, as well as the complete demo
application.
Assessment: The lab will be assessed during lab sessions through a number of checkpoints. The
overall lab mark will be split into individual (60%) and group components (40%) for both
undergraduate and postgraduate students. All students are encouraged to keep a lab book.
Verification: To support remote working, a verification environment will be provided for each
interface. Details will be provided on Learn.
Assessment: The individual component will consist of two checkpoints:
1. First individual assessment in Week 5, when every team member will be assessed on the
particular peripheral interface they developed i.e. mouse driver or VGA interface. Code
should be uploaded to Learn prior to the timetabled laboratory in Week 5 for assessment.
This will account for 25% of the overall lab mark.
2. Second individual assessment in Week 8, when every team member will demonstrate a
working microprocessor + peripheral demo software application. For instance, the team
member in charge of mouse driver development will present a demo software
application running on the microprocessor with the mouse peripheral. Similarly, the
team member in charge of VGA interface development will present a demo software
application running on the microprocessor with the VGA interface peripheral. The
specification of the individual demo software application will be specified later on this
4
document. This second individual assessment will account for 35% of the overall lab
mark. Note that while this assessment is individual, it requires prior design of the same
microprocessor architecture by all team members. Code should be uploaded to Learn
prior to the timetabled laboratory in Week 8 for assessment.
3. The final assessment will be a group assessment in Week 11, where the entire team will
demonstrate the complete demo software application running on the complete
microprocessor-based system on the BASYS 3 board. There will be an element of peer
assessment in this final group based assignment where individuals will be asked to
evaluate the individual performance of colleagues within the group. More details of this
process will be given nearer the time of assessment. Again all design files should be
uploaded to Learn prior to the start of the scheduled laboratory.
Details of the university semester structure can be found on the university web pages. Note that
the week between weeks 5 and 6 is usually an unnumbered week, Flexible Learning Week.
The remainder of this document will present the detailed specification of each component of
the proposed system. The details of the assessment components will also be presented where
appropriate.
5
1. PS/2 Mouse Driver
The USB connector on the BASYS 3 board can accommodate a USB mouse. Internally, the
signals are converted to PS/2-like signals via a microcontroller as discussed on page 7 and 8 of
the BASYS 3 reference manual. Hence, all we need do is implement a driver for a PS/2 mouse
as the USB connector could be seen as just a wrapper which has already been implemented.
The PIC24 drives several signals into the FPGA – two are used to implement a standard PS/2
interface for communication with a mouse or keyboard (see figure 3 below).
Figure 3: USB Host signals to PS/2 signal conversion
PS/2 devices use a two-wire serial bus (clock and data) to communicate with a host device
Communication is bidirectional and performed in packets of 11-bit words, with each word
containing a start, stop and odd parity bit. The following describes the PS/2 mouse protocol in
detail (NB. the PS/2 keyboard protocol can be found in the BASYS 3 user manual if you are
interested in developing a keyboard interface but this is not required in this lab).
The mouse device only outputs a clock and data signal when it is moved. Otherwise, the clock
and data lines remain at logic high (i.e. ‘1’). Open-Collector drivers are usually used to drive
the two-wire bus between the mouse and host.
The device can send data to the host only when both data and clock lines are high. Because the
host is the bus master, the device must check whether the host is sending data before driving
the bus. The clock line is used for this purpose as a “clear to send” signal; if the host pulls the
clock line low, the device must not send any data until the clock is released.
Communication is performed in 11-bit words, where each word consists of a ‘0’ start bit,
followed by 8 bits of data (LSB first), followed by an odd parity bit (i.e. a bit that is set to ‘1’ if
the number of 1’s in the 8 bits of data is even, and ‘0’ otherwise), and terminated with a ‘1’ stop
bit. The odd-parity bit is used for error detection.
Data sent from a PS/2 device to a host is read on the falling edge of the clock signal, whereas
data sent from a host to a PS/2 device is read on the rising edge of the clock signal. The
following figure shows PS/2 signal timing for a device to host communication. Note the timing
requirements which must be strictly adhered to. The clock frequency, for instance, must lie
between 10 and 16.7 KHz.
6
Figure 3. PS/2 Device to Host Signal Timing
The following figure shows PS/2 signal timing for a host to device communication. The host
brings the clock line low first, for at least 100µs. It then brings the data line low and releases
the clock line. The host then waits for the PS/2 device to bring the clock line low. After that, it
sets or resets the data line with the first data bit, and waits for the device to bring clock line
high. It then waits for the device to bring the clock line low before it sets/rests the data line
with the second data bit. This process is repeated until all eight data bits are sent as well as the
odd-parity bit. Next, the host releases the data line, and waits for the device to bring the data
line low, and then the clock line low. Finally, the host waits for the device to release data and
clock lines.
Figure 4. Host to PS/2 Device Signal Timing
Now that we have seen the low level PS/2 protocol, let us look at the high level host-mouse
communication. At power-up, a typical host-mouse communication consists of the following
steps:
1) The host sends a Reset Command (consisting of byte “FF”) to the mouse,
2) The mouse responds with an Acknowledgement byte “FA”,
3) The mouse then goes through a self-test process and sends “AA” when this is passed. Then
a mouse ID byte “00” is sent to the host, after which the host knows that the mouse is
functioning well and ready to transmit data,
4) The host sends byte “F4” to instruct the mouse to “Start Transmitting” its position
information,
5) The mouse acknowledges the “Start Transmitting” command by sending byte “FA” back
to the host**,
6) After this, the mouse starts transmitting its position information in the form of 3 bytes at a
sample rate that can be set by the host (the default is 100Hz)
7
**Note however that in the Basys3 FPGA board, probably due to the USB to PS/2
conversion, F4 instead of FA is returned, and parity test fails. Hence in state 8 of
MasterStateSM module, the acknowledgement code have been changed to F4, and parity
check skipped.
Thus, each data transmission from the mouse to the host after initialisation consists of 33 bits,
where bits 1 (first bit), 12, and 23 are ‘0’ start bits; bits 10, 21, and 32 are Odd-Parity bits; and
bits 11, 22, and 33 are ‘1’ stop bits. The three-byte data fields contain status and movement data
as shown in the figure below.
Byte 1: Status Byte
Byte 2: X Direction Byte
Byte 3: Y Direction Byte
Figure 5. Mouse Data Format
The mouse reports a relative coordinate system whereby a move to the right generates a positive
number in the X Direction Byte field, and a move to the left generates a negative number in this
field. Similarly, a move upwards generates a positive number in the Y Direction Byte field, and
a move downwards generates a negative number. Note that the X and Y Direction Bytes
represent the magnitude of the rate of mouse movement, the larger the number the faster the
mouse is moving. Bits XS and YS in the Status Byte are the sign bits, whereby a ‘1’ indicates a
negative number, whereas XV and YV bits are movement overflow indicators, whereby a ‘1’
means overflow has occurred. The L and R fields in the Status Byte indicate that the left and
right button have been pressed, respectively (‘1’ indicates the button has been pressed).
What you are required to do
You are required to design an FPGA PS/2 mouse interface and implement it on the BASYS 3
board. The clock line is physically connected to pin “C17” of the Artix7 FPGA chip, and the
data line is physically connected to pin “B17” of the chip.
Note that in connecting these pins in the XDC file, pull up need to be set true by using the
additional comment of the form: set_property PULLUP true [get_ports PS2_CLK] after the PS/2
clock and PS/2 Data ports.
The FPGA mouse interface can be built from three modules: a “Transmitter” module, a
“Receiver” module and a “State Machine” module to control the FPGA-Mouse communication,
as shown in Figure 6.
L R 0 1 XS
YS XV YV
X1 X2 X3 X4 X5 X6 X7 X8
Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8
8
Figure 6. Mouse Interface: Simplified Block Diagram
The following shows Verilog code fragments for the “Receiver” module:
module MouseReceiver(
//Standard Inputs
input RESET,
input CLK,
//Mouse IO - CLK
input CLK_MOUSE_IN,
//Mouse IO - DATA
input DATA_MOUSE_IN,
//Control
input READ_ENABLE,
output [7:0] BYTE_READ,
output [1:0] BYTE_ERROR_CODE,
output BYTE_READY
);
/* Fill in the code */
endmodule
Receiver
Transmitter
Master
State
Machine Byte_To_Send
CLK_MOUSE_IN DATA_MOUSE_IN
CLK_MOUSE_IN /
CLK_MOUSE_OUT_EN
DATA_MOUSE_IN /
DATA_MOUSE_OUT/
DATA_MOUSE_OUT_EN
PS2 Clock Line
PS2 Data Line
SEND_BYTE
BYTE_SENT
BYTE_SENT
Byte_Read
READ_ENABLE
9
The following shows Verilog code fragments for the “Transmitter” module:
module MouseTransmitter(
//Standard Inputs
input RESET,
input CLK,
//Mouse IO - CLK
input CLK_MOUSE_IN,
output CLK_MOUSE_OUT_EN, // Allows for the control of the Clock line
//Mouse IO - DATA
input DATA_MOUSE_IN, output DATA_MOUSE_OUT,
output DATA_MOUSE_OUT_EN,
//Control
input SEND_BYTE,
input [7:0] BYTE_TO_SEND,
output BYTE_SENT
);
/* Fill in the code */
endmodule
10
The following shows Verilog code fragments for the Master State Machine module:
module MouseMasterSM(
input CLK,
input RESET,
//Transmitter Control
output SEND_BYTE,
output [7:0] BYTE_TO_SEND,
input BYTE_SENT,
//Receiver Control
output READ_ENABLE,
input [7:0] BYTE_READ,
input [1:0]
BYTE_ERROR_CODE, input
BYTE_READY,
//Data Registers
output [7:0] MOUSE_DX,
output [7:0] MOUSE_DY,
output [7:0] MOUSE_STATUS,
output SEND_INTERRUPT
);
/* Fill in the code */
endmodule
11
Finally, the above three blocks should be connected in a “Mouse Transceiver” module as
suggested in the code fragments below:
Module MouseTransceiver(
//Standard Inputs
input RESET,
input CLK,
//IO - Mouse side
inout CLK_MOUSE,
inout DATA_MOUSE,
// Mouse data information
output [3:0] MouseStatus,
output [7:0] MouseX,
output [7:0] MouseY );
// X, Y Limits of Mouse Position e.g. VGA Screen with 160 x 120 resolution
parameter [7:0] MouseLimitX = 160; parameter [7:0]
MouseLimitY = 120;
/* Fill in the code */
endmodule
12
Note how we deal with bidirectional ports (inout’s) needed here as the Data line and the
Clock line are both written to and read from. In general, to make use of an inout port
“Port_Inout_Example”, you need to create an internal wire (“Port_Inout_Example_In”) with
the value of the “Port_Inout_Example” port assigned to it. This can be used internally as an
input to user logic when the port is in input mode. To write data to the port, we create an enable
signal “Port_Inout_Example_Enable” which when set causes the output port to take the value
of an internal signal “Port_Inout_Example_Out” from user logic. Otherwise, the inout port is
set to high impedance. The following show Verilog code snippets to the above effect.
wire Port_Inout_Example_In;
assign Port_Inout_Example_In = Port_Inout_Example;
// Use Port_Inout_Example_In as an input to your logic
…. ….
// Internal signal Port_Inout_Example_Out can be assigned to the inout port if an enable
// signal (Port_Inout_Example_Enable) is set
assign Port_Inout_Example = ( Port_Inout_Example_Enable ? Port_Inout_Example_Out : 1’bZ);
Assessment
You will need to complete the mouse interface code based on the above, synthesise and verify
your code with test benches, generate an FPGA bitstream and test on the BASYS 3 board. The
team member in charge of this peripheral development will be tested in Week 5. This individual
assessment will account for 25% of your overall lab mark. During the test, you will need to
demonstrate a functioning mouse interface on the BASYS 3 board through plugging a USB
mouse to the board, and showing the various mouse register values (Status Byte, X Direction
Byte, and Y Direction Byte) displayed on the LEDs and seven segment displays of the BASYS
3 board as the mouse is moved around. You will be supplied with the Verilog description of a
seven segment display interface (SevenSeg). A specification of the latter can also be found in
the Digital System Laboratory 3/A material. During the assessment, you will need to be able to
take the assessor through your code answering any possible query about your design choices,
coding style, etc. Your code will have been uploaded to Learn prior to the start of the laboratory
session.
13
2. VGA Interface
In order to display video onto a monitor screen, we will make use of the VGA port available on
the BASYS 3 board. The latter uses 14 signals (carried by 14 FPGA pins, see Figure on page
11 of the BASYS 3 Reference Manual) with 12-bit colour and two synchronisation signals (HS
– Horizontal Sync, and VS – Vertical Sync). HS and VS allow the monitor to align the incoming
colour signals such that individual pixels on the screen are coloured correctly. Colours are
derived by a combination of the three primary colours: red, blue and green. Four bits are used
for each colour (given 16 possible levels of each colour).
However, it is possible to use only 8 of the 12-bit colours, especially for compatibility with an
8 bit bus processor architecture. In this configuration, three bits are used for Red and Green
(giving 8 possible levels of each colour) and two bits are used for Blue (giving four possible
levels only, as the human eye is less sensitive to blue than it is to red and green). You could
either chose to implement an 8-bit colour (connecting only the 3 LSBs of Red and Green, and
2 LSBs of Blue), or implement the full 12 bits colour but you will have to send the colour
information twice on an 8-bit bus. In this description, we target the 8-bit configuration.
You are required to develop an FPGA-based VGA driver which generates the necessary VGA
signals (8 bit colour information and 2 synchronisation signals) to a VGA monitor using a frame
buffer that holds frame pixel values. Pages 11- 14 of the manual give details of the VGA
standard, providing much of the specification for this module - read it carefully. The following
will take you through a suggested design of the VGA driver.
What you are required to do
VGA provides a resolution of 640 x 480 pixels (horizontal x vertical). A VGA driver could be
built from two modules as shown in the following figure:
- “Frame_Buffer”: A dual ported memory module which can be written to by an outside
module e.g. a microprocessor, and read from by the “VGA_Sig_Gen” module (see
Figure 7 below) for VGA display
- “VGA_Sig_Gen”: VGA signal generator module, which reads consecutive pixel colours
in raster pattern, from the “Frame_Buffer” module, and outputs the VGA signals through
the proper FPGA pins
14
Figure 7. VGA Interface
Unfortunately, the FPGA chip on the BASYS 3 board does not have enough memory resources
to store a full VGA frame with 8-bit pixels (i.e. 640 x 480 x 8 bits memory). In fact, few FPGA
chips on the market can hold complete frames on-chip. Instead, off-chip memory (e.g. SDRAM)
is often used to implement the frame buffer. The BASYS 3 board, however, does not have such
external memory resource, which means that FPGA logic must be used to hold frame buffer
data. To solve this problem, we can use a reduced colour resolution as well as a reduced pixel
resolution to minimise memory storage requirements. In our suggested design, we will reduce
the screen resolution by 4 in each direction i.e. each 4x4 pixel region on the screen would be
represented by one single data element on the frame buffer, hence the above wordlength of the
X and Y addresses in Figure 7 (i.e. 8 and 7 bits respectively instead of 10 and 9 bits for the 640
x 480 VGA resolution). We also reduce the colour resolution from 256 possible colours to just
two colours (foreground and background) hence 1 bit data is sufficient for the colour
information. A dual ported 256 x 128 1-bit memory should then be large enough to hold the
whole frame buffer, which could be easily stored on the Artix-7 chip. Note that in the proposed
code below, the foreground and background colours can be set by an external module e.g. a
microprocessor, through input Config_Colour[15:0] (see Figure 7 above) which represents 2 x
8 bits of data for two possible 8-bit colours.
VGA_Sig_Gen
Frame_Buffer
8 HS VS
7 8
VGA_Colour
Addr_X Addr_Y Pixel_Data_Out
Config_Colours[15:0]
Pixel_Data_In Addr_X 8 7 Addr_Y
Write_Enable
15
The following shows possible Verilog code for the Frame_Buffer module:
module Frame_Buffer( ///
Port A - Read/Write
input A_CLK,
input [14:0] A_ADDR, // 8 + 7 bits = 15 bits hence [14:0]
input A_DATA_IN, // Pixel Data In
output reg A_DATA_OUT,
input A_WE, // Write Enable
//Port B - Read Only
input B_CLK,
input [14:0] B_ADDR, // Pixel Data Out
output reg B_DATA
);
// A 256 x 128 1-bit memory to hold frame data
//The LSBs of the address correspond to the X axis, and the MSBs to the Y axis
/* Fill in the code */
endmodule
16
The following shows Verilog code fragments for the VGA_Sig_Gen module:
module VGA_Sig_Gen(
input CLK,
//Colour Configuration Interface
input [15:0] CONFIG_COLOURS,
// Frame Buffer (Dual Port memory) Interface
output DPR_CLK,
output [14:0] VGA_ADDR,
input VGA_DATA,
//VGA Port Interface
output reg VGA_HS,
output reg VGA_VS,
output [7:0] VGA_COLOUR
);
//change the clock to 25MHz to drive the VGA display
/*
Define VGA signal parameters e.g. Horizontal and Vertical display time, pulse widths, front and back porch
widths etc.
*/
// Use the following signal parameters
parameter HTs = 800; // Total Horizontal Sync Pulse Time
parameter HTpw = 96; // Horizontal Pulse Width Time
parameter HTDisp = 640; // Horizontal Display Time
parameter Hbp = 48; // Horizontal Back Porch Time
parameter Hfp = 16; // Horizontal Front Porch Time
parameter VTs = 521; // Total Vertical Sync Pulse Time
parameter VTpw = 2; // Vertical Pulse Width Time
parameter VTDisp = 480; // Vertical Display Time
parameter Vbp = 29; // Vertical Back Porch Time
parameter Vfp = 10; // Vertical Front Porch Time
/* Fill in the code */
endmodule
Note that the VGA standard was designed for CRT monitors, and hence it is important to be
aware of the timing of the original system, even if we are using a digital display. It should also
be noted that in addition to the HS and VS timing definitions within the reference manual, the
8-bit colour signal needs to be set to 8'h00 (zero) whilst not during the display time.
You will need to complete your code based on the above, synthesise and verify your code with
test benches, generate an FPGA bitstream and test on the BASYS 3 board. Test the above driver
block by packaging it within a top level module that generates frame buffer and colour
configuration data, and outputs the VGA signals to the proper FPGA pins. Display the following
chequered image on the VGA display, changing colours every one second.
17
Figure 8. Chequered image to be displayed on the VGA screen
Assessment
The team member in charge of this peripheral development will be tested on Week 5. This
individual assessment will account for 25% of your overall lab mark. During the test, you will
need to demonstrate a functioning VGA interface on the BASYS 3 board through plugging a
VGA monitor to the BASYS 3 board, and showing the above chequered image, changing
colours every one second. You will need to take the assessor through your code answering any
possible query about your design choices, coding style, etc. Your code will have been uploaded
to Learn prior to the start of the laboratory session.
1 VGA Buffer Element,
equivalent to a 4x4 VGA
Pixel Area on screen
18
3. Microprocessor-based System for Remote Car Control
The following figure gives a block diagram of the overall FPGA-based system for remote car
control. At its heart is a microprocessor which will be the master of an 8-bit bus to which various
peripherals (slaves) will be connected.
Figure 9. Microprocessor-based system block architecture
The following presents the memory mapping of the peripherals on the microprocessor’s data
address bus.
Peripheral Base Address High Address
IR Transmitter 0x90 0x90
Mouse 0xA0 0xA2
VGA 0xB0 0xB2
LEDs 0xC0 0xC0
SevenSeg 0xD0 0xD1
Timer 0xF0 0xF3
Table 1. Peripheral Memory Address Mapping
Note that the proposed microprocessor has a Harvard architecture which means that the
instruction memory and data memory are distinct with separate address and data busses for each
of them. Parallel accesses to both instructions and program data can thus be made, resulting in
higher performance compared to Von-Neumann processors where instructions and data are
stored on the same memory.
19
In our architecture, the data memory consists of 128 bytes and is mapped to the
microprocessor’s address space as follow:
Data Memory Base Address High Address
0x00 0x7F
Table 2. Data Memory Address Mapping
Note that in advanced microprocessor systems, data memory is given its own high speed local
bus, with a separate peripheral bus for relatively slower devices. In our case, data memory
shares the same bus as the peripherals since high performance is not a major concern for us in
this lab.
The following presents a suggested Verilog design of the data memory:
module RAM(
//standard signals
input CLK,
//BUS signals
inout [7:0] BUS_DATA,
input [7:0] BUS_ADDR,
input BUS_WE
);
parameter RAMBaseAddr = 0;
parameter RAMAddrWidth = 7; // 128 x 8-bits memory
//Tristate
wire [7:0] BufferedBusData;
reg [7:0] Out;
reg RAMBusWE;
//Only place data on the bus if the processor is NOT writing, and it is addressing this memory assign
BUS_DATA = (RAMBusWE) ? Out : 8'hZZ; assign BufferedBusData = BUS_DATA;
//Memory
reg [7:0] Mem [2**RAMAddrWidth-1:0];
// Initialise the memory for data preloading, initialising variables, and declaring constants
initial $readmemh("Complete_Demo_RAM.txt", Mem);
//single port ram always@(posedge CLK)
begin
// Brute-force RAM address decoding. Think of a simpler way...
if((BUS_ADDR >= RAMBaseAddr) & (BUS_ADDR < RAMBaseAddr + 128)) begin
if(BUS_WE) begin
Mem[BUS_ADDR[6:0]] <= BufferedBusData;
RAMBusWE <= 1'b0; end else
RAMBusWE <= 1'b1; end else
RAMBusWE <= 1'b0;
Out <= Mem[BUS_ADDR[6:0]];
end
endmodule
20
The instruction memory has its own data and address bus, hence no decoding is necessary. In
fact, this is a point to point connection. The following presents a suggested Verilog design of
the instruction memory, which consists of 256 bytes and is read-only (ROM).
module ROM(
//standard signals
input CLK,
//BUS signals
output reg [7:0] DATA,
input [7:0] ADDR
);
parameter RAMAddrWidth = 8;
//Memory
reg [7:0] ROM [2**RAMAddrWidth-1:0];
// Load program
initial $readmemh("Complete_Demo_ROM.txt", ROM);
//single port ram
always@(posedge CLK)
DATA <= ROM[ADDR];
endmodule
3.1 Interrupts
In our system architecture presented in Figure 9 above, interrupts come from two possible
sources: 1) the mouse, when it is moved or clicked, and 2) the timer, which outputs an interrupt
signal every one second. In general, an interrupt is an asynchronous signal from hardware
indicating the need for attention, or a synchronous event in software indicating the need for a
change in execution. Multiple hardware interrupts can be ORed or serviced through an interrupt
controller which acts as another bus peripheral whose task is to service interrupts before they
are sent to the microprocessor. This includes dealing with priorities for instance. In this lab,
interrupts will be served on a “first-come first-served” basis. If two interrupts arrive at exactly
the same time, the mouse interrupt will be dealt with first.
When an interrupt request is received by the microprocessor, the current program execution is
suspended after the execution of the current instruction. The context information is then saved
so that execution can return to the current program after interrupt servicing. In the case of our
microprocessor, the context consists in the address of the next instruction to be executed by the
interrupted process. After context saving, execution is transferred to an interrupt handler to
service the interrupt. The start (or base) address of the interrupt handler’s service routine is
usually predefined, for each interrupt line, in a particular memory address. In our case, the
memory address where the base address of the mouse interrupt handler’s service routine is
stored is “FF”, whereas that of the timer is “FE”. This means that whenever a mouse interrupt
is received, for instance, the microprocessor fetches the base address of the mouse interrupt
handler’s service routine to be executed from address “FF”. In other words, the content of
21
address “FF” will be the address of the first instruction to be executed by the interrupt handler’s
service routine.
The following gives you a possible Verilog code to implement the Timer peripheral.
Code for the seven segment display peripheral has already been given to you as part of the
mouse interface module (you would need to wrap your existing peripheral codes with bus
interfaces though), while the LEDs peripheral is straightforward to implement.
The seven segment display should show the VGA Screen region that the mouse hovers
over: F for Forward, B for Backward, R for Right, L for Left, F R for Forward Right, F L
for Forward Left, B R for Backward Right, B L for Backward Left, and I for Idle.
22
module Timer(
//standard signals
input CLK,
input RESET,
//BUS signals
inout [7:0] BUS_DATA,
input [7:0] BUS_ADDR,
input BUS_WE,
output BUS_INTERRUPT_RAISE,
input BUS_INTERRUPT_ACK
);
parameter [7:0] TimerBaseAddr = 8'hF0; // Timer Base Address in the Memory Map
parameter InitialIterruptRate = 100; // Default interrupt rate leading to 1 interrupt every 100 ms
parameter InitialIterruptEnable = 1'b1; // By default the Interrupt is Enabled
//////////////////////
//BaseAddr + 0 -> reports current timer value
//BaseAddr + 1 -> Address of a timer interrupt interval register, 100 ms by default
//BaseAddr + 2 -> Resets the timer, restart counting from zero
//BaseAddr + 3 -> Address of an interrupt Enable register, allows the microprocessor to disable
// the timer
//This module will raise an interrupt flag when the designated time is up. It will
//automatically set the time of the next interrupt to the time of the last interrupt plus
//a configurable value (in milliseconds).
//Interrupt Rate Configuration - The Rate is initialised to 100 by the parameter above, but can
//also be set by the processor by writing to mem address BaseAddr + 1; reg [7:0]
InterruptRate; always@(posedge CLK) begin
if(RESET)
InterruptRate <= InitialIterruptRate;
else if((BUS_ADDR == TimerBaseAddr + 8'h01) & BUS_WE)
InterruptRate <= BUS_DATA;
end
//Interrupt Enable Configuration - If this is not set to 1, no interrupts will be
//created.
reg InterruptEnable; always@(posedge CLK)
begin
if(RESET)
InterruptEnable <= InitialIterruptEnable;
else if((BUS_ADDR == TimerBaseAddr + 8'h03) & BUS_WE)
InterruptEnable <= BUS_DATA[0];
end
//First we must lower the clock speed from 50MHz to 1 KHz (1ms period) reg
[31:0] DownCounter; always@(posedge CLK) begin if(RESET)
DownCounter <= 0;
else begin
if(DownCounter == 32'd49999)
DownCounter <= 0;
else
DownCounter <= DownCounter + 1'b1;
end
end
//Now we can record the last time an interrupt was sent, and add a value to it to determine if it is
// time to raise the interrupt.
// But first, let us generate the 1ms counter (Timer)
23
reg [31:0] Timer; always@(posedge CLK) begin
if(RESET | (BUS_ADDR == TimerBaseAddr + 8'h02))
Timer <= 0; else begin
if((DownCounter == 0)) Timer <=
Timer + 1'b1; else
Timer <= Timer; end
end
//Interrupt generation reg TargetReached; reg [31:0]
LastTime; always@(posedge CLK) begin if(RESET)
begin
TargetReached <= 1'b0;
LastTime <= 0;
end else if((LastTime + InterruptRate) == Timer) begin
if(InterruptEnable)
TargetReached <= 1'b1;
LastTime <= Timer;
end else
TargetReached <= 1'b0;
end
//Broadcast the Interrupt reg Interrupt;
always@(posedge CLK) begin
if(RESET)
Interrupt <= 1'b0; else
if(TargetReached) Interrupt <= 1'b1;
else if(BUS_INTERRUPT_ACK) Interrupt <= 1'b0;
end
assign BUS_INTERRUPT_RAISE = Interrupt;
//Tristate output for interrupt timer output value
reg TransmitTimerValue; always@(posedge CLK) begin
if(BUS_ADDR == TimerBaseAddr)
TransmitTimerValue <= 1'b1;
else
TransmitTimerValue <= 1'b0; end
assign BUS_DATA = (TransmitTimerValue) ? Timer[7:0] : 8'hZZ;
endmodule
24
3.2 Microprocessor architecture
The microprocessor that you are required to design is an 8-bit processor with a load-store
architecture whereby two internal registers (A and B) are used to hold operands and operation
results. Central to the processor is an Arithmetic and Logic Unit (ALU) which can perform the
following operations:
- Add two operands A, B
- Subtract two operands A, B
- Multiply two operands A, B
- Left shift operand A (by one bit)
- Right shift operand A (by one bit)
- Increment operand A
- Increment operand B
- Decrement operand A
- Decrement operand B
- Check if two operands A, B are equal (output 0x01 if that’s the case, otherwise 0x00)
- Check if A>B (output 0x01 if that’s the case, otherwise 0x00)
- Check if A<B (output 0x01 if that’s the case, otherwise 0x00)
An operation code of four bits dictates which of these operations is performed (see Figure 10
below).
Figure 10. Arithmetic and Logic Unit (ALU)
A B
Result
ALU_Op_Code[3:0]
25
A possible Verilog code to implement the above ALU is given to you below.
module ALU(
//standard signals
input CLK,
input RESET,
//I/O
input [7:0] IN_A, input
[7:0] IN_B, input
[3:0] ALU_Op_Code, output [7:0]
OUT_RESULT
);
reg [7:0] Out;
//Arithmetic Computation
always@(posedge CLK) begin
if(RESET)
Out <= 0;
else begin
case (ALU_Op_Code)
//Maths Operations
//Add A + B
4'h0: Out <= IN_A + IN_B;
//Subtract A - B
4'h1: Out <= IN_A - IN_B;
//Multiply A * B
4'h2: Out <= IN_A * IN_B;
//Shift Left A << 1
4'h3: Out <= IN_A << 1;
//Shift Right A >> 1
4'h4: Out <= IN_A >> 1;
//Increment A+1
4'h5: Out <= IN_A + 1'b1;
//Increment B+1
4'h6: Out <= IN_B + 1'b1;
//Decrement A-1
4'h7: Out <= IN_A - 1'b1;
//Decrement B-1
4'h8: Out <= IN_B - 1'b1;
// In/Equality Operations
//A == B
4'h9: Out <= (IN_A == IN_B) ? 8'h01 : 8'h00;
//A > B
4'hA: Out <= (IN_A > IN_B) ? 8'h01 : 8'h00;
//A < B
4'hB: Out <= (IN_A < IN_B) ? 8'h01 : 8'h00;
//Default A
default: Out <= IN_A;
endcase
end
end
assign OUT_RESULT = Out;
endmodule
26
The microprocessor has 6 types of instructions overall:
1. Read from memory to Register A or B
2. Write to memory from Register A or B
3. Do an ALU operation and save the result in register A or B
4. Jump operations: conditional jump depending on whether register A’s content is
equal, greater than or less than register B’s content, or unconditional jump to a
particular address.
5. Function call and return
6. Dereference Register A or B
Different instructions have different word lengths, but they are always issued in consecutive
bytes. The following table presents the instruction set architecture in more detail.
27
Table 3. Microprocessor’s Instruction Set
Such a small instruction set with direct hardware support for its implementation is referred to
as a RISC architecture (RISC = Reduced Instruction Set Computing), as opposed to CISC
architecture (CISC = Complex Instruction Set Computing) whereby the instruction set is large
and complex with further microcode translation needed for complex instruction execution.
RISC architectures are dominant nowadays as they are simpler and faster in hardware.
The proposed microprocessor’s behaviour is essentially a state machine, with one sequential
pipeline of states for each operation as shown in the following figure.
Figure 11. Microprocessor’s state machine
Idle
Choose_Op
Do_Maths_Op_
Save_In_A
Dereference
_A
Do_Maths_Op_
Save_In_B Read_From
_Mem_To_A
Read_From_
Mem_To_B
Dereference
_B
Interrupt
Operation Code GOTO_IDLE
28
Based on the above, the following shows suggested Verilog code fragments for the
microprocessor’s behaviour:
module Processor(
//Standard Signals
input CLK,
input RESET,
//BUS Signals
inout [7:0] BUS_DATA,
output [7:0] BUS_ADDR,
output BUS_WE,
// ROM signals
output [7:0] ROM_ADDRESS,
input [7:0] ROM_DATA,
// INTERRUPT signals
input [1:0] BUS_INTERRUPTS_RAISE,
output [1:0] BUS_INTERRUPTS_ACK
);
//The main data bus is treated as tristate, so we need a mechanism to handle this.
//Tristate signals that interface with the main state machine
wire [7:0] BusDataIn;
reg [7:0] CurrBusDataOut, NextBusDataOut;
reg CurrBusDataOutWE, NextBusDataOutWE;
//Tristate Mechanism
assign BusDataIn = BUS_DATA;
assign BUS_DATA = CurrBusDataOutWE ? CurrBusDataOut : 8'hZZ;
assign BUS_WE = CurrBusDataOutWE;
//Address of the bus
reg [7:0] CurrBusAddr, NextBusAddr;
assign BUS_ADDR = CurrBusAddr;
//The processor has two internal registers to hold data between operations, and a third to hold
//the current program context when using function calls.
reg [7:0] CurrRegA, NextRegA;
reg [7:0] CurrRegB, NextRegB;
reg CurrRegSelect, NextRegSelect;
reg [7:0] CurrProgContext, NextProgContext;
//Dedicated Interrupt output lines - one for each interrupt line
reg [1:0] CurrInterruptAck, NextInterruptAck;
assign BUS_INTERRUPTS_ACK = CurrInterruptAck;
//Instantiate program memory here
//There is a program counter which points to the current operation. The program counter
//has an offset that is used to reference information that is part of the current operation
reg [7:0] CurrProgCounter, NextProgCounter;
reg [1:0] CurrProgCounterOffset, NextProgCounterOffset;
wire [7:0] ProgMemoryOut;
wire [7:0] ActualAddress;
assign ActualAddress = CurrProgCounter + CurrProgCounterOffset;
// ROM signals
assign ROM_ADDRESS = ActualAddress;
assign ProgMemoryOut = ROM_DATA;
29
//Instantiate the ALU
//The processor has an integrated ALU that can do several different operations
wire [7:0] AluOut;
ALU ALU0(
//standard signals
.CLK(CLK),
.RESET(RESET),
//I/O
.IN_A(CurrRegA),
.IN_B(CurrRegB),
.IN_OPP_TYPE(ProgMemoryOut[7:4]),
.OUT_RESULT(AluOut)
);
//The microprocessor is essentially a state machine, with one sequential pipeline
//of states for each operation.
//The current list of operations is:
// 0: Read from memory to A
// 1: Read from memory to B
// 2: Write to memory from A
// 3: Write to memory from B
// 4: Do maths with the ALU, and save result in reg A
// 5: Do maths with the ALU, and save result in reg B
// 6: if A (== or < or > B) GoTo ADDR
// 7: Goto ADDR
// 8: Go to IDLE
// 9: End thread, goto idle state and wait for interrupt.
// 10: Function call
// 11: Return from function call
// 12: Dereference A
//13: Dereference B
parameter [7:0] //Program thread selection
IDLE = 8'hF0, //Waits here until an interrupt wakes up the processor.
GET_THREAD_START_ADDR_0 = 8'hF1, //Wait.
GET_THREAD_START_ADDR_1 = 8'hF2, //Apply the new address to the program counter.
GET_THREAD_START_ADDR_2 = 8'hF3, //Wait. Goto ChooseOp.
//Operation selection
30
//Depending on the value of ProgMemOut, goto one of the instruction start states.
CHOOSE_OPP = 8'h00,
//Data Flow
READ_FROM_MEM_TO_A = 8'h10, //Wait to find what address to read, save reg select.
READ_FROM_MEM_TO_B = 8'h11, //Wait to find what address to read, save reg select.
READ_FROM_MEM_0 = 8'h12, //Set BUS_ADDR to designated address.
READ_FROM_MEM_1 = 8'h13, //wait - Increments program counter by 2. Reset offset.
READ_FROM_MEM_2 = 8'h14, //Writes memory output to chosen register, end op.
WRITE_TO_MEM_FROM_A = 8'h20, //Reads Op+1 to find what address to Write to.
WRITE_TO_MEM_FROM_B = 8'h21, //Reads Op+1 to find what address to Write to.
WRITE_TO_MEM_0 = 8'h22, //wait - Increments program counter by 2. Reset offset.
//Data Manipulation
DO_MATHS_OPP_SAVE_IN_A = 8'h30, //The result of maths op. is available, save it to Reg A.
DO_MATHS_OPP_SAVE_IN_B = 8'h31, //The result of maths op. is available, save it to Reg B.
DO_MATHS_OPP_0 = 8'h32, //wait for new op address to settle. end op.
/*
Complete the above parameter list for In/Equality, Goto Address, Goto Idle, function start, Return from
function, and Dereference operations.
*/
………………..
FILL IN THIS AREA
……………….
//Sequential part of the State Machine.
reg [7:0] CurrState, NextState;
always@(posedge CLK) begin
if(RESET) begin
CurrState = 8'h00;
CurrProgCounter = 8'h00;
CurrProgCounterOffset = 2'h0;
CurrBusAddr = 8'hFF; //Initial instruction after reset.
CurrBusDataOut = 8'h00;
CurrBusDataOutWE = 1'b0;
CurrRegA = 8'h00;
CurrRegB = 8'h00;
CurrRegSelect = 1'b0;
CurrProgContext = 8'h00;
31
CurrInterruptAck = 2'b00;
end else begin
CurrState = NextState;
CurrProgCounter = NextProgCounter;
CurrProgCounterOffset = NextProgCounterOffset;
CurrBusAddr = NextBusAddr;
CurrBusDataOut = NextBusDataOut;
CurrBusDataOutWE = NextBusDataOutWE;
CurrRegA = NextRegA;
CurrRegB = NextRegB;
CurrRegSelect = NextRegSelect;
CurrProgContext = NextProgContext;
CurrInterruptAck = NextInterruptAck;
end
end
//Combinatorial section – large!
always@* begin
//Generic assignment to reduce the complexity of the rest of the S/M
NextState = CurrState;
NextProgCounter = CurrProgCounter;
NextProgCounterOffset = 2'h0;
NextBusAddr = 8'hFF;
NextBusDataOut = CurrBusDataOut;
NextBusDataOutWE = 1'b0;
NextRegA = CurrRegA;
NextRegB = CurrRegB;
NextRegSelect = CurrRegSelect;
NextProgContext = CurrProgContext;
NextInterruptAck = 2'b00;
//Case statement to describe each state
case (CurrState)
///////////////////////////////////////////////////////////////////////////////////////
//Thread states.
IDLE: begin
if(BUS_INTERRUPTS_RAISE[0]) begin // Interrupt Request A.
NextState = GET_THREAD_START_ADDR_0;
32
NextProgCounter = 8'hFF;
NextInterruptAck = 2'b01;
end else if(BUS_INTERRUPTS_RAISE[1]) begin //Interrupt Request B.
NextState = GET_THREAD_START_ADDR_0;
NextProgCounter = 8'hFE;
NextInterruptAck = 2'b10;
end else begin
NextState = IDLE;
NextProgCounter = 8'hFF; //Nothing has happened.
NextInterruptAck = 2'b00;
end
end
//Wait state - for new prog address to arrive.
GET_THREAD_START_ADDR_0: begin
NextState = GET_THREAD_START_ADDR_1;
end
//Assign the new program counter value
GET_THREAD_START_ADDR_1: begin
NextState = GET_THREAD_START_ADDR_2;
NextProgCounter = ProgMemoryOut;
end
//Wait for the new program counter value to settle
GET_THREAD_START_ADDR_2:
NextState = CHOOSE_OPP;
///////////////////////////////////////////////////////////////////////////////////////
//CHOOSE_OPP - Another case statement to choose which operation to perform
CHOOSE_OPP: begin
case (ProgMemoryOut[3:0])
4'h0: NextState = READ_FROM_MEM_TO_A;
4'h1: NextState = READ_FROM_MEM_TO_B;
4'h2: NextState = WRITE_TO_MEM_FROM_A;
4'h3: NextState = WRITE_TO_MEM_FROM_B;
4'h4: NextState = DO_MATHS_OPP_SAVE_IN_A;
4'h5:NextState = DO_MATHS_OPP_SAVE_IN_B;
4'h6:NextState = IF_A_EQUALITY_B_GOTO;
4'h7: NextState = GOTO;
33
4'h8:NextState = IDLE;
4'h9:NextState = FUNCTION_START;
4'hA:NextState = RETURN;
4'hB:NextState = DE_REFERENCE_A;
4'hC:NextState = DE_REFERENCE_B;
default:
NextState = CurrState;
endcase
NextProgCounterOffset = 2'h1;
end
///////////////////////////////////////////////////////////////////////////////////////
//READ_FROM_MEM_TO_A : here starts the memory read operational pipeline.
//Wait state - to give time for the mem address to be read. Reg select is set to 0
READ_FROM_MEM_TO_A:begin
NextState = READ_FROM_MEM_0;
NextRegSelect = 1'b0;
end
//READ_FROM_MEM_TO_B : here starts the memory read operational pipeline.
//Wait state - to give time for the mem address to be read. Reg select is set to 1
READ_FROM_MEM_TO_B:begin
NextState = READ_FROM_MEM_0;
NextRegSelect = 1'b1;
end
//The address will be valid during this state, so set the BUS_ADDR to this value.
READ_FROM_MEM_0: begin
NextState = READ_FROM_MEM_1;
NextBusAddr = ProgMemoryOut;
end
//Wait state - to give time for the mem data to be read
//Increment the program counter here. This must be done 2 clock cycles ahead
//so that it presents the right data when required.
READ_FROM_MEM_1: begin
NextState = READ_FROM_MEM_2;
NextProgCounter = CurrProgCounter + 2;
end
//The data will now have arrived from memory. Write it to the proper register.
34
READ_FROM_MEM_2: begin
NextState = CHOOSE_OPP;
if(!CurrRegSelect)
NextRegA = BusDataIn;
else
NextRegB = BusDataIn;
end
///////////////////////////////////////////////////////////////////////////////////////
//WRITE_TO_MEM_FROM_A : here starts the memory write operational pipeline.
//Wait state - to find the address of where we are writing
//Increment the program counter here. This must be done 2 clock cycles ahead
//so that it presents the right data when required.
WRITE_TO_MEM_FROM_A:begin
NextState = WRITE_TO_MEM_0;
NextRegSelect = 1'b0;
NextProgCounter = CurrProgCounter + 2;
end
//WRITE_TO_MEM_FROM_B : here starts the memory write operational pipeline.
//Wait state - to find the address of where we are writing
//Increment the program counter here. This must be done 2 clock cycles ahead
// so that it presents the right data when required.
WRITE_TO_MEM_FROM_B:begin
NextState = WRITE_TO_MEM_0;
NextRegSelect = 1'b1;
NextProgCounter = CurrProgCounter + 2;
end
//The address will be valid during this state, so set the BUS_ADDR to this value,
//and write the value to the memory location.
WRITE_TO_MEM_0: begin
NextState = CHOOSE_OPP;
NextBusAddr = ProgMemoryOut;
if(!NextRegSelect)
NextBusDataOut = CurrRegA;
else
NextBusDataOut = CurrRegB;
NextBusDataOutWE = 1'b1;
end
35
///////////////////////////////////////////////////////////////////////////////////////
//DO_MATHS_OPP_SAVE_IN_A : here starts the DoMaths operational pipeline.
//Reg A and Reg B must already be set to the desired values. The MSBs of the
// Operation type determines the maths operation type. At this stage the result is
// ready to be collected from the ALU.
DO_MATHS_OPP_SAVE_IN_A: begin
NextState = DO_MATHS_OPP_0;
NextRegA = AluOut;
NextProgCounter = CurrProgCounter + 1;
end
//DO_MATHS_OPP_SAVE_IN_B : here starts the DoMaths operational pipeline
//when the result will go into reg B.
DO_MATHS_OPP_SAVE_IN_B: begin
NextState = DO_MATHS_OPP_0;
NextRegB = AluOut;
NextProgCounter = CurrProgCounter + 1;
end
//Wait state for new prog address to settle.
DO_MATHS_OPP_0: NextState = CHOOSE_OPP;
/*
Complete the above case statement for In/Equality, Goto Address, Goto Idle, function start, Return
from
function, and Dereference operations.
*/
………………..
FILL IN THIS AREA
……………….
endcase
end
endmodule
36
What you are required to do - Assessment
Before you can design your microprocessor and write software for it, you will need to wrap up
your existing peripheral codes (i.e. for Mouse, VGA) with a bus interface to connect them to
the microprocessor bus. You will need to simulate and verify these new peripheral codes with
test benches. Make sure they synthesise, before you can test on the BASYS 3 board. You are
then required to code the above microprocessor behaviour in Verilog based on the specification
and codes provided. Once your system is fully captured in Verilog, simulated with test benches
and tested on the BASYS 3 board, you need to develop a demo software application for each
microprocessor and peripheral combination (you will be tested individually on this task) and
then go on to develop the full demo software application as outlined at the start of this document
(you will be tested as a group on this task).
37
Individual Demo Software Application
The following will specify the individual demo software for each microprocessor and peripheral
combination.
Microprocessor + Mouse Demo Application
This task should be performed by the team member who developed the mouse peripheral
interface. Here, you will need to complete a software demo application running on the
microprocessor that the whole team developed, using only the mouse peripheral among the
peripherals developed by the individual team members i.e. do not use the VGA or other
interfaces here. The team member in charge of this task will be tested in Week 8. This individual
assessment will account for 35% of your overall lab mark. During the test, you will need to
demonstrate your program on the BASYS 3 board and explain your code.
The application in question here consists in re-implementing the same original mouse demo
which you developed earlier i.e. the demo which showed the mouse registers content on the
LEDs and seven segment displays, but this time purely in software using the instruction set of
the microprocessor developed by the whole team.
Microprocessor + VGA Interface Demo Application
This task should be performed by the team member who developed the VGA peripheral
interface. Here, you will need to complete a software demo application running on the
microprocessor that the whole team developed, using only the VGA peripheral among the
peripherals developed by the individual team members. The team member in charge of this task
will be tested in Week 8. This individual assessment will account for 35% of your overall lab
mark. During the test, you will need to demonstrate your program on the BASYS 3 board and
explain your code.
The application in question here consists in re-implementing the original VGA demo which
showed the chequered image with changing colours on the VGA screen, but this time purely in
software using the instruction set of the microprocessor developed by the whole team.
Complete Demo Software Application
This task should be performed by team members as a group. Here, you will develop the
complete software demo application described at the beginning of this document using all
required peripherals. You need to implement the complete system described in Figure 9 (IR
Transmitter is Bonus) and program the microprocessor to implement the complete demo
application. The team as a whole will be tested on this task in Week 11.
This group assessment will account for the remaining 40% of your overall lab mark. During
the test, you will need to demonstrate your program running on the BASYS 3 board and explain
your code, especially the software code running on the microprocessor. There will be an element
of peer assessment in this final group based assignment where individuals will be asked to
evaluate the individual performance of colleagues within the group. More details of this process
will be given nearer the time of assessment. Your code will have been uploaded to Learn prior
to the start of the final laboratory session.
38
4. IR Transmitter Driver (Bonus)
This driver is considered a bonus and it targets controlling a real toy car through IR
commands. The BASYS 3 board provides four 12-pin peripheral module connectors. Each is
organised in two rows of 6-pins, with each row providing a power pin (Vdd @3.3V), a ground
pin (GND), and four unique FPGA signals (see BASYS 3 reference manual, page 17). (Note
that one of the connectors is designed for JXADC. Use any of the other three for this lab).
Several 6-pin (or 12-pin) module boards that can attach to this connector are available from
Digilent (see www.digilentinc.com for more information). For the purpose of this lab, we
have developed our own 6-pin IR Transmitter module, which can be attached to any of the
three peripheral module connectors. The following gives the circuit diagram of the IR
Transmitter module.
Figure 12. IR Transmitter circuit
What you are required to do
Your task is to generate the proper pulse codes to control the cars remotely using the Artix-7
FPGA chip with the above IR Transmitter peripheral module. The following will present the
pulse codes needed to control each car type: RED, BLUE, GREEN, YELLOW. In general,
however, the pulse code for any car consists of the following generic packet, generated at
10Hz frequency.
Figure 13. Car Pulse Code: Generic Packet
The following describes the packet details for each car type. These might vary from one car
batch to another, so it is always wise to check the packet details using a logic analyser.
39
Blue-coded Cars:
In the case of blue-coded cars, the pulse frequency F = 1/T (see Figure 13 above) is equal to
36KHz. The following gives the number of pulses in each packet region as labelled in Figure
13:
• Start = 191
• Gap = 25
• CarSelect = 47 (NB. The number of pulses in this region identifies the car type i.e.
REDcoded here)
• Right: If the right direction is to be asserted i.e. the car is to move to the right, the number
of pulses here is set to 47, otherwise it is 22
• Left: If the left direction is to be asserted i.e. the car is to move to the left, the number of
pulses here is set to 47, otherwise it is 22
• Backward: If the Backward direction is to be asserted i.e. the car is to move backwards,
the number of pulses here is set to 47, otherwise it is 22
• Forward: If the Forward direction is to be asserted i.e. the car is to move forwards, the
number of pulses here is set to 47, otherwise it is 22
Yellow-coded Cars:
In the case of yellow-coded cars, the pulse frequency F = 1/T (see figure 13 above) is equal
to 40KHz. The following gives the number of pulses in each packet region as labelled in
Figure 13:
• Start = 88
• Gap = 40
• CarSelect = 22
• Right: If the right direction is to be asserted i.e. the car is to move to the right, the number
of pulses here is set to 44, otherwise it is 22
• Left: If the left direction is to be asserted i.e. the car is to move to the left, the number of
pulses here is set to 44, otherwise it is 22
• Backward: If the Backward direction is to be asserted i.e. the car is to move backwards,
the number of pulses here is set to 44, otherwise it is 22
• Forward: If the Forward direction is to be asserted i.e. the car is to move forwards, the
number of pulses here is set to 44, otherwise it is 22
Green-coded Cars:
In the case of green-coded cars, the pulse frequency F = 1/T (see figure 13 above) is equal to
37.5 KHz. The following gives the number of pulses in each packet region as labelled in
Figure 13:
• Start = 88
• Gap = 40
• CarSelect = 44
• Right: If the right direction is to be asserted i.e. the car is to move to the right, the number
of pulses here is set to 44, otherwise it is 22
40
• Left: If the left direction is to be asserted i.e. the car is to move to the left, the number of
pulses here is set to 44, otherwise it is 22
• Backward: If the Backward direction is to be asserted i.e. the car is to move backwards,
the number of pulses here is set to 44, otherwise it is 22
• Forward: If the Forward direction is to be asserted i.e. the car is to move forwards, the
number of pulses here is set to 44, otherwise it is 22
Red-coded Cars:
In the case of red-coded cars, the pulse frequency F = 1/T (see figure 13 above) is equal to 36
KHz. The following gives the number of pulses in each packet region as labelled in Figure
13:
• Start = 192
• Gap = 24
• CarSelect = 24
• Right: If the right direction is to be asserted i.e. the car is to move to the right, the number
of pulses here is set to 48, otherwise it is 24
• Left: If the left direction is to be asserted i.e. the car is to move to the left, the number of
pulses here is set to 48, otherwise it is 24
• Backward: If the Backward direction is to be asserted i.e. the car is to move backwards,
the number of pulses here is set to 48, otherwise it is 24
• Forward: If the Forward direction is to be asserted i.e. the car is to move forwards, the
number of pulses here is set to 48, otherwise it is 24
Generating the necessary pulse codes for all of these variations requires a generic state
machine with the following parameters:
parameter StartBurstSize e.g. = 192;
parameter CarSelectBurstSize e.g. = 24;
parameter GapSize e.g. = 24;
parameter AsserBurstSize e.g. = 48;
parameter DeAssertBurstSize e.g. = 24;
Figure 14. IR Transmitter State Machine
The state machine is illustrated in Figure 14 where COMMAND consists of four bits: bit 0 to
assert or de-assert the right direction, bit 1 to assert or de-assert the left direction, bit 2 to
assert or de-assert the backward direction, and bit 3 to assert or de-assert the forward direction.
IR_Transmitter_SM
CLK
RESET
COMMAND IR_LED
SEND_PACKET
41
Note that the state machine can be enabled by setting SEND_PACKET to ‘1’ for one clock
cycle, which will result in the generation of one single packet of those shown Figure 13. This
has to be done ten times per second for the car to respond to the command in question. A 10Hz
counter is thus needed as illustrated in Figure 15 below.
Figure 15. IR Transmitter Interface
The following shows code fragments for the IR Transmitter State Machine:
IR_Transmitter_SM
CLK
RESET
COMMAND IR_LED
SEND_PACKET 10Hz
Counter
42
module IRTransmitterSM( //Standard
Signals
input RESET,
input CLK,
// Bus Interface Signals
input [3:0] COMMAND,
input SEND_PACKET,
// IF LED signal
output IR_LED
);
/*
Generate the pulse signal here from the main clock running at 50MHz to generate the right frequency for
the car in question e.g. 40KHz for BLUE coded cars
*/
………………..
FILL IN THIS AREA
……………….
/*
Simple state machine to generate the states of the packet i.e. Start, Gaps, Right Assert or De-Assert, Left
Assert or De-Assert, Backward Assert or De-Assert, and Forward Assert or De-Assert
*/
………………..
FILL IN THIS AREA
……………….
// Finally, tie the pulse generator with the packet state to generate IR_LED
………………..
FILL IN THIS AREA
……………….
endmodule
For Bonus Marks:
The team will need to complete the code based on the above, synthesise and verify your code
with test benches, generate an FPGA bitstream and test on the BASYS 3 board. The team
should integrate this interface with the micro-processor and control the toy car through
sending IR commands based on the mouse location on the screen. During the test, you will
need to demonstrate a functioning car control interface on the BASYS 3 board through the
mouse, which causes the remote car to move forward, backward, to the right and to the left.
請加QQ：99515681 郵箱：99515681@qq.com WX：codinghelp
