\section{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. 