UART Communication on FPGA4U

UART Communication on FPGA4U
Learning Goal: Use UART module for communication between two FPGA4U boards.
Requirements: Nios2Sim Simulator, Quartus, FPGA4U Board.
1
Introduction
During this lab, you will modify the Pong that you implemented in the ArchOrd lab (refer to the lab
Programming in Assembly: A Simple Pong in the Additional material section on the course webpage). The
goal of the project is to play the game with two FPGA4Us communicating by UART. Each player will
control his paddle with the push buttons from his FPGA4U board.
One of the two players will be the host of the game and the other one the client. The host will have to
compute the behavior of the game, send the game information to the client (i.e., the position of the ball
and the paddles, and the score), and receive commands from the client (essentially to move his paddle).
Both of them will display the game on the LEDs as illustrated in the following figure.
0
8
11
x axis
0
1
position of paddle 2 (y=1)
position of paddle 1 (y=4)
4
5
position of the ball (x=8,y=5)
7
y axis
The client will receive from the host the necessary information to be able to display the game on the
LEDs:
• The current position of the ball (i.e., the x and y coordinates of the ball).
• The current position of the paddles. The client only needs and will only receive the y coordinate of
the paddles, as their position over the x axis is constant (0 for paddle 1, 11 for paddle 2).
• The current score. The current score is needed by the client, because the score is displayed on the
LEDs at the end of a point.
2
UART Module
For this project you will use the same system like the one you used in the lab Nios II Interrupt Management. You will use the UART module (Universal Asynchronous Receiver Transmitter) for communication.
Version 1.5 of 19th March 2015, EPFL ©2015
1 of 5
UART Communication on FPGA4U
The UART module receives and sends data serially through the rx input and the tx output, respectively.
It contains a parallel to serial converter to transmit data and a serial to parallel converter to receive data.
clk
rx
tx
reset_n
oe
cs
write
2
address
32
wrdata
UART
rddata
32
irq
In the system, the UART module is mapped at the address 0x2010. The following subsection describes its registers and their functions.
2.1
Register Map
Register
0
1
2
3
2.1.1
Name
receive
transmit
status
control
31...8
Reserved
Reserved
Reserved
Reserved
7...2
1
0
Receive Data
Transmit Data
trdy
rrdy
itrdy irrdy
receive
The receive register holds the 8-bit data that is received through the rx input signal. When new data
is received, it is available in the receive register, and the rrdy bit of the status register is set to 1. The
rrdy bit is set to 0 when the receive register is read. New data is always transferred into the receive
register, regardless of whether the previous data was read or not. The receive register is read-only
(writing it has no effect).
2.1.2
transmit
The 8-bit value written in the transmit register is transmitted through the tx output signal. A new
value should not be written to the transmit register until the transmitter is ready for a new data, as
indicated by the trdy bit in the status register. The trdy bit is set to 0 when data is written into the
transmit register. The trdy bit is set back to 1 when the data is fully transferred and the UART is ready
to transmit an new byte. Writes to the transmit register when trdy is 0 are ignored. The transmit
register is write-only (reading it returns an undefined value).
2.1.3
status
The rrdy bit (receive ready) indicates whether some data has been received. When the receive register
is empty, there is nothing to read and rrdy is 0. When a newly received value is transferred into the
receive register, rrdy is set to 1. Reading the receive register clears the rrdy bit to 0.
2 of 5
Version 1.5 of 19th March 2015, EPFL ©2015
UART Communication on FPGA4U
The trdy bit (transmit ready) indicates whether or not the module is ready to transmit new data. When
the module is busy sending data it is not ready to accept a new byte to transmit and trdy is 0. Reversely,
when it is ready for transmission of new data, trdy is 1.
2.1.4
control
The irrdy or itrdy can be set by the programmer to activate an interrupt when the rrdy or trdy bit is 1,
respectively.
3
Communication protocol
We will use a simple protocol to transmit the game information from the host to the client.
With the UART module, the data is transfered per block of 8 bits, bytes. In our case, 8 bits are
sufficient to send a complete message: we will use 1 bit for error detection, 3 bits to encode the message
type, and 4 bits for the data (see the following table).
7
Parity bit
6 ... 4
OP
3 ... 0
Data
The OP field identifies the command to execute or the property of the game that has to be updated
with the content of the Data field. The encoding is listed in the following table.
Operation to execute
Update x coordinate of the ball with Data
Update y coordinate of the ball with Data
Update y coordinate of paddle 1 with Data
Update y coordinate of paddle 2 with Data
Update the score of player 1 with Data
Update the score of player 2 with Data
Display the score on the LEDs
Display the game on the LEDs
OP code
0
1
2
3
4
5
6
7
Every time that the host modifies the state of the game (e.g., move the ball, move a paddle, increment
the score of a player, etc), it must tell the client to update it by sending the appropriate code and data.
For example, if paddle 1 is moved to y=3, the host will send to the client a byte with the value of 0x23.
Every time that the display of the game needs to be updated, the host will send a message to the client
with OP=7. This will force the client to redraw the game on the LEDs.
When a player wins a point, the game is suspended and the new score is displayed on the LEDs.
When this occurs, the host first sends the new score to the client and then a message with OP=6, telling
the client to display the score on the LEDs instead of the game.
The parity bit is a simple way to detect errors during the transmission of data. It is set in a way
to ensure that the number of bits with the value of 1 in the data is always even or always odd. In this
project, the parity bit will ensure that the number of bits set to 1 in the transmitted bytes is always odd.
4
Exercise
For this lab, you will have to choose to implement either the client or the host. Try to work in groups
of two, assigning one to the implementation of the host and the other one to the implementation of the
client. It will be easier to test your project. If you have not implemented or finished the Pong during the
first semester, we suggest you to implement the client part, as it requires less familiarity with the code
than for the host.
Make sure to download the last version of the Nios2Sim simulator.
Version 1.5 of 19th March 2015, EPFL ©2015
3 of 5
UART Communication on FPGA4U
4.1
The Client
The client executes the directives coming from the host. The client also sends a message to the host each
time when one of his push buttons is pressed.
• In a pong_client.asm, copy all the functions that you will need to display the game and the
score on the LEDs. If you do not have it, use the pong_client.asm file that is proposed in the
project template.
• Implement a send_uart procedure.
– The procedure sends the data given in the a0 argument register trough the UART module.
The procedure has to set the parity bit correctly before sending the data.
– Make sure that the UART module is ready to transmit data before you write in its transmit
register.
• Implement a receive_uart procedure.
– The procedure waits until some data is received by the UART module, and reads it. It verifies
the parity, and if it detects an error, it returns -1 in v0; otherwise, it returns the OP field in v0
and the Data field in v1.
• Complete the code so that:
– When a push button is pressed, the client sends a message to the host with the content of the
edgecapture register of the Button module (refer to the lab Nios II Interrupt Management).
The client does not need to specify some OP field since this is the only information that is sent
to the host.
– The client executes the directives given by the host. The messages that contain a parity error
are ignored.
4.2
The Host
The host computes the behavior of the game, sends directives to the client, and receives messages each
time that the client wants to move his paddle.
• Make a copy of your implementation of the Pong in a pong_host.asm file. If you do not have it,
use the pong_host.asm file that is proposed in the project template.
• Implement a send_uart procedure.
– The procedure sends the data provided in the a0 and a1 argument registers trough the UART
module. The a0 register specifies the OP field, and a1 the Data field. The procedure has to
set the parity bit correctly before sending the data.
– Make sure that the UART module is ready to transmit data before you write in its transmit
register.
• In this new version of the Pong, the paddles move each time that a button is pressed. The
move_paddles function that you implemented previously is not used anymore by the main function. Remove each call to this procedure, but do not remove the procedure itself yet, it could help
you to implement the next routines.
• Implement an interrupt handler that will serve the interrupts coming from the buttons and from
the UART module with a uart_isr and button_isr routine.
• Implement a button_isr routine.
4 of 5
Version 1.5 of 19th March 2015, EPFL ©2015
UART Communication on FPGA4U
– The routine must be called each time that one of the push buttons is pressed. The routine
reads the edgecapture register of the Button module (refer to the lab Nios II Interrupt Management), and moves the paddle of the host in function of which button has been pressed (for
example, button 3 could move the paddle down, while button 0 moves it up).
– Do not forget to refresh the display after any modification.
• Implement a uart_isr routine.
– The routine must be called each time that the UART module receives a new data. The routine
reads the data and verifies the parity. The data sent by the client identifies the buttons that
have been pressed in the same way that for the edgecapture register of the Button module.
The routine has to move the paddles of the client in function of the buttons that has been
pressed (for example, button 0 could move the paddle down, while button 3 moves it up).
– Do not forget to refresh the display after a modification.
• Complete the code so that:
– Each time that the host modifies a property of the game, he sends a message to the client with
the new value of the property.
– Each time that the host refreshes the display (with the game state or the score), he must send
a message to the client telling him to do the same.
5
Running the program on the FPGA
In this last section, you will test your program on the FPGA4U. We will provide cables to connect your
FPGA4U to another one. Ask for them when you are ready.
• To run it successfully, you use the processor that you extended with interrupt management during
the lab Nios II Interrupt Management.
• Update the initialization file of the ROM:
– In the Nios2Sim simulator, open your program.
– Select File >Export to Hex File..., and select the ROM.
– Save the program content in the ROM.hex file of the quartus folder.
• Compile the Quartus project.
• Program the board.
• Connect your FPGA4U to another one with a cable.
6
Submission
To get points for this lab, you should submit your file and demonstrate your work to one of the assistants. The demo of this lab can be done during one of the two lab sessions of Lab 4 (weeks 5-6) or during
the first hour of Lab 5 (week 8).
Version 1.5 of 19th March 2015, EPFL ©2015
5 of 5