ROUGH DRAFT authorea.com/20214

# FPGA Lab 8

Abstract

Lab 8 explored the use of an RS232 port to communicate between the FPGA and pieces of circuits that are off of the board. I was able to compile a circuit which listened to the port and transmitted the incoming signal back over the RS232 port to display it on the serial port of a computer. This lab was very useful in showing how one would connect an FPGA to more complicated circuitry and transmit data between the two, allowing the FPGA to add as a central microprocessor for a more complicated lab.

# Introduction

Lab 8 introduced a way of communicating with the FPGA from an external device using a serial port. I began by compiling the provided code (shown in diagram 1) and verified that the loop-back interface behaved as seeing the pressd keys in the SecureCRT serial monitor provided by Quartus and not seeing anything when the switch was in the off position. With the switch in the on position, the signal was being retransmitted back to the computer, indicated by the TX led going on. Since the FPGA was also recieving a signal from the computer (which it resent) the RX led would go on as well. I pressed ctrl+a on the keyboard which turned on only one of the LEDS and showed the number 01 on the 7 segmment displays. This is as expected since the ASCII code for ctrl+a is 1. With the DIP switch off, so that it was not sending the signal back to the computer, the TX led was always high since it was always sending a low signal. When dealing with the serial monitor, I had the opportunity to illustrate parity. The FPGA sends signals with no parity so when the serial monitor was told not to have parity, things worked as expected. However, if I told the serial monitor to expect odd parity then it interpreted off letters (like a and b) as needing a parity bit of 0 which is interpretted as a start bit for a new signal rather than the parity bit (since the FPGA doens’t send one anyway). This fake start bit causes the computer to keep reading the next stream for input which is all idle bits. In the UART protocol, idle bits are high so this gets interpretted as a very high value, displaying FF on the 7 segment display.

The second part of the lab explored the use of the oscilloscope to monitor the signal being transmitted over the RS232 port. By attaching a female jumper wire to the serial port I could plot the voltage being transmitted as a function of time. The waveform was always a fixed width corresponding to the 12 bits being sent over the UART protoctol. As shown in 4, the start bit of the signal was always low and the stop bit is always high. By looking at a signal that had only one high bit (like ctrl+a) I could easily measure the width of a single pulse. I measured a width of 8 $$\mu$$s which corresponds to a period of 114000 bits per second. This is close to the 115200 baud rate that the board was set to.

# Circuits

This diagram shows the timing and DFFs for the UART signal. In the top circuit, the signal is taken the DFFs and then passed on to a timing circuit which triggers the DFFs at the appropriate baud rate. The 12 bit counter allows us to keep track of time at the same rate that it is being sent by the RS232 port. Each time signal that represents a new data signal triggers the DFFs which reads the next value. The DFFs then connect their output to a bus which is called q and represents the data being transmitted.

This diagram shows the loop back function that send the received signal back over the RS232 port to the computer so I can see what button I pressed. The FPGA is always sending the data on the ’transmit’ line which is either held low (not sending anything) or if the DIP switch is high, transmits the data back to the computer. The output is also connected to an LED array and two 7-segment displays so I can verify the character being sent to the board.