User Tools
Table of Contents
Sp20 UART Receiver
In this laboratory you will create and test the receiver part of a UART. Your design will closely follow the serial transmitter you previously did. That is, you will have handshaking with a host (but the signals are called Receive and Received). And, the receiver has similar components - a state machine, a bit counter, and a timer.
Learning Outcomes
- Implement an asynchronous receiver
- Strengthen behavioral SystemVerilog skills
Preliminary
What was discussed in class lecture, along with the textbook section on UART receivers will form the basis for the lab. However, you will note that far less of the design is provided to you this week.
In this lab we will operate the receiver at a baud rate of 19,200 and will use odd parity, just like before.
Using a 100 MHz clock, how many clock cycles does it take to reach the middle of the bit period using this baud rate? (see Figure 28.15)
Exercises
Exercise #1 - Asynchronous Receiver Module
Begin your laboratory assignment by creating a receiver module that has the following parameters and ports:
| Module Name = rx | |||
|---|---|---|---|
| Port Name | Direction | Width | Function |
| clk | Input | 1 | 100 MHz System Clock |
| Reset | Input | 1 | The system reset signal |
| Sin | Input | 1 | Receiver serial input signal |
| Receive | Output | 1 | Indicates that the receiver now has a byte it is asking to hand off on the Dout pins |
| Received | Input | 1 | Indicates that the other circuitry has accepted the received byte on the Dout pins. Receive and Received serve as Req and Ack from Figure 28.7. However, the requestor who raises Receive is your rx module and the acknowledger who raises the Received signal is the testbench or other outside agent. |
| Dout | Output | 8 | 8-bit data received by the receiver which is then output on pins |
| parityErr | Output | 1 | Indicates that there was a parity error on the last byte reception. |
Next, complete the full design of the receiver. See the textbook for more information. You will need:
- Baud timer
- Bit counter
- Shift register
- Parity checker
Baud Timer
This is very similar to your timer from last time except it needs to be able to tell you when a whole bit time has passed as well as when a half bit time has passed. Both are needed at some point in your state machine's operation. One way to implement this is to simply add a second output to the timer to signify when it has reached its half-count. It need not roll over when it reaches its half-count - it can simply raise this second output and keep counting until it reaches the full termination count.
Shift Register
The purpose of this is to collect the serially received bits as they come in. It is recommended that you shift all 8 data bits plus the parity bit into the shift register. But, you will only output the 8 data bits on the Dout pins.
Parity Checker
Once you have shifted all 9 bits into the shift register, you should check that the parity bit is correct (odd parity). If this is not true, you should raise the parityErr signal.
The parityErr signal can be a combinational logic signal which computes whether what is in the shift register at that time has odd parity. It will thus transition as things are shifted into the shift register and will only be an accurate error signal once you have shifted in the 9th bit (the parity bit). That is OK - the circuit that checks this will only look at the parityErr signal when Receive == 1.
You need to think carefully - given the order that bits arrive - do you want the register to shift right or shift left? The textbook explicitly states which bit is transmitted first. Given that, should you feed the bits in from the left of the shift register and right shift each time or the other way around? All you care about is that when you are done that you can assign the bits to Dout for output.
Finite State Machine
You get to design this yourself from scratch. However, we suggest you pattern it somewhat after the transmitter state machine. Note that you have to have your timer get you over into the middle of each bit period and so your timer may have additional output signals. And, your state machine will need to be designed to control when the shift register shifts so that you collect the 8 data bits and parity bits. Finally, your state machine will need to handshake using the Receive and Received signals at the end of each byte reception. You may assume that a new byte will not start to arrive on the Sin signal before the Receive/Received handshake has completed.
Exercise 1 Pass-off: Using Zoom, discuss with a TA the state graph of your state
machine.
Exercise #2 - Simulation
After creating your rx module, create a TCL file and simulate your receiver module to make sure that there are no major errors.
Attach a copy of your Tcl file and a
screenshot of your working simulation to Learning Suite.
Then simulate your module with the following testbench file:
Attach a copy of your receiver design's SystemVerilog code to your lab report, in PDF.
Attach a copy of the console output from the testbench simulation in your lab report, showing no errors.
Exercise #3 - Test It in hardware
In this exercise you are going to test your receiver in hardware.
Make a new top-level module with the following ports:
| Module Name = uart_rx_top | |||
|---|---|---|---|
| Port Name | Direction | Width | Function |
| clk | Input | 1 | 100 MHz System Clock |
| reset | Input | 1 | Reset signal, wired to a button |
| ser_in | Input | 1 | The serial signal coming from putty, wired to the receive rx_in signal on the FPGA |
| Receive | Output | 1 | Receive handshake: character has been received by UART, tied to an LED |
| Received | Input | 1 | Receive handshake: host acknowledge receipt of character, tied to a button |
| rxData | Output | 8 | Data that was received by receiver, wired to LEDs |
| parityErr | Output | 1 | Parity error signal, wired out to an LED |
Next, create a .xdc file which maps your top-level signal names to pins on the FPGA. In this case, your top level signal names don't match what is in the .xdc file so you will have to edit it to make them match like you have done in some previous labs. What to wire your top level ports to are given above. If any additional signals are needed, add them to the module and .xdc file as well.
Synthesize, implement, and generate a bitstream for your design. Test it in hardware with putty. In putty, anything you type will be sent down the line (make sure you have the baudrate, parity, etc all done correctly). It will NOT be mirrored to the putty screen but will go down the serial line where your receiver will receive it and display it on the LED's. Once your receiver has received a byte it should light up the Receive output to tell you that a new character has arrived. The handshaking will be that you assert the Received input (from a button) and your state machine will lower Receive and that is the end of the handshake. The received byte should be reflected on the LED's along with the parity error signal.
Some Thoughts on Testing
- Upon startup when your shift register has all 0's in it, what would you expect the value of your parityErr signal to be? Check it to be sure.
- Remember that after each character is received you must acknowledge it via handshaking using the Received button.
- This can be a difficult design to debug if it is not working. For example, if you set up putty and push a character and absolutely nothing happens, then what do you do? One common strategy would be to bring your state machine bits out to output pins and wire them to LED's. That way, if you FSM is just stuck in some state you will have a hint.
- The .xdc file for this design has been left wide open - it is easy to get confused about the role of Receive vs. Received and other signals. Carefully think through them until you are sure you understand what they are to do.
Include a copy of your top-level module in your laboratory report
Make a video demonstrating your final design and showing that, indeed, it does receive ASCII letters, punctuation, and digits and can display them on the LEDs. To test if the parity works, then change the parity in putty to even parity and show that you always get a parity error (even though the received character is good).
