User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
labs:sp20_uar [2020/05/28 18:46] nelson [Sp20 UART Receiver] |
labs:sp20_uar [2020/06/10 17:08] (current) nelson [Exercise #3 - Test It in hardware] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Sp20 UART Receiver ====== | ====== Sp20 UART Receiver ====== | ||
| - | In this laboratory you will create and simulate the receiver part of a | + | 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. | 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 | That is, you will have handshaking with a host (but the signals are | ||
| Line 17: | Line 17: | ||
| In this lab we will operate the receiver at a baud rate of 19,200 and | In this lab we will operate the receiver at a baud rate of 19,200 and | ||
| - | will use odd parity. | + | will use odd parity, just like before. |
| <color red>Using a 100 MHz clock, how many clock cycles does it take | <color red>Using a 100 MHz clock, how many clock cycles does it take | ||
| Line 66: | Line 66: | ||
| true, you should raise the parityErr signal. | true, you should raise the parityErr signal. | ||
| - | The parityErr signal can be a combinational logic signal which is | + | The parityErr signal can be a combinational logic signal which computes whether |
| - | constantly reflecting the contents of the shift register. It will | + | 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 | 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 | only be an accurate error signal once you have shifted in the 9th bit | ||
| Line 92: | Line 92: | ||
| signal before the Receive/Received handshake has completed. | signal before the Receive/Received handshake has completed. | ||
| - | What about the timing of the parityErr signal? When a parity error | + | /*What about the timing of the parityErr signal? When a parity error |
| occurs, raise the parityErr signal while the Receive signal is being | occurs, raise the parityErr signal while the Receive signal is being | ||
| - | raised and lower it when the Receive signal is lowered. | + | raised and lower it when the Receive signal is lowered. */ |
| **Exercise 1 Pass-off:** Using Zoom, discuss with a TA the state graph of your state | **Exercise 1 Pass-off:** Using Zoom, discuss with a TA the state graph of your state | ||
| Line 102: | Line 102: | ||
| After creating your rx module, create a TCL file and simulate | After creating your rx module, create a TCL file and simulate | ||
| - | your receiver module to make sure that there are no major errors. Then simulate | + | your receiver module to make sure that there are no major errors. |
| + | |||
| + | <color red> Attach a copy of your Tcl file and a | ||
| + | screenshot of your working simulation to Learning Suite.</color>\\ \\ | ||
| + | |||
| + | Then simulate | ||
| your module with the following testbench file: | your module with the following testbench file: | ||
| {{ :labs:tb_rx.sv |}} | {{ :labs:tb_rx.sv |}} | ||
| - | <color red>Attach a copy of the console output from the testbench simulation in your lab report</color> | + | <color red>Attach a copy of your receiver design's SystemVerilog code to your lab report, in PDF.</color> |
| - | <color red>Include the SystemVerilog code for your receiver module in your report</color> | + | <color red>Attach a copy of the console output from the testbench simulation in your lab report, showing no errors.</color> |
| - | **Exercise 2 Pass-off:** <del>Show a TA your tcl script and your | ||
| - | testbench output.</del> Attach a copy of your Tcl file and a | ||
| - | screenshot of your working simulation to Learning Suite.\\ \\ | ||
| - | ==== Exercise #3 - Loop-Back Simulation Test ==== | ||
| - | In this exercise you are going to simulate a transmitter/receiver pair as shown in the figure below. | + | ==== Exercise #3 - Test It in hardware ==== |
| - | {{:labs:lab_11:img_0065.jpg?900|}} | + | In this exercise you are going to test your receiver in hardware. |
| + | |||
| + | /*{{:labs:lab_11:img_0065.jpg?900|}} | ||
| Here, there is a transmitter (with its host) located in Boston that is going to transmit bytes to a receiver (with its host) located in San Francisco. But, to mimic that you are going to put your transmitter from Lab 10 and your receiver from Lab 11 into the same top module. | Here, there is a transmitter (with its host) located in Boston that is going to transmit bytes to a receiver (with its host) located in San Francisco. But, to mimic that you are going to put your transmitter from Lab 10 and your receiver from Lab 11 into the same top module. | ||
| Line 126: | Line 129: | ||
| The actual serial data transmission, rather than actually traveling from Boston to San Franciso will travel a few nanometers on a wire inside the FPGA from the transmitter's output to the receiver's input. | The actual serial data transmission, rather than actually traveling from Boston to San Franciso will travel a few nanometers on a wire inside the FPGA from the transmitter's output to the receiver's input. | ||
| + | */ | ||
| Make a new top-level module with the following ports: | Make a new top-level module with the following ports: | ||
| - | ^ Module Name = uart_top ^^^^ | + | ^ Module Name = uart_rx_top ^^^^ |
| ^ Port Name ^ Direction ^ Width ^ Function ^ | ^ Port Name ^ Direction ^ Width ^ Function ^ | ||
| | clk | Input | 1 | 100 MHz System Clock | | | clk | Input | 1 | 100 MHz System Clock | | ||
| - | | reset | Input | 1 | Reset signal | | + | | reset | Input | 1 | Reset signal, wired to a button | |
| - | | txData | Input | 8 | Data to be transmitted | | + | | ser_in | Input | 1 | The serial signal coming from putty, wired to the receive rx_in signal on the FPGA | |
| - | | Send | Input | 1 | Transmit handshake: send character command signal | | + | | Receive | Output | 1 | Receive handshake: character has been received by UART, tied to an LED | |
| - | | Sent | Output | 1 | Transmit handshake: acknowledge character has been sent | | + | | Received | Input | 1 | Receive handshake: host acknowledge receipt of character, tied to a button | |
| - | | Receive | Output | 1 | Receive handshake: character has been received by UART | | + | | rxData | Output | 8 | Data that was received by receiver, wired to LEDs | |
| - | | rxData | Output | 8 | Data that was received by receiver | | + | | parityErr | Output | 1 | Parity error signal, wired out to an LED | |
| - | | Received | Input | 1 | Receive handshake: host acknowledge receipt of character | | + | |
| - | | parityErr | Output | 1 | Parity error signal | | + | |
| - | | serData | Output | 1 | The serial signal between xmit and rcv blocks. You are bringing it out as an output so you can easily see it in simulation. | | + | |
| - | Note that you are NOT going to map these I/O signals to board-level switches and led's. You are simply going to simulate this top level module. | + | /*Inside this module, instance both your tx and rx modules. Then, connect the serial out |
| - | + | ||
| - | Inside this module, instance both your tx and rx modules. Then, connect the serial out | + | |
| data signal of the transmitter to the serial in data signal of the | data signal of the transmitter to the serial in data signal of the | ||
| receiver. This is called a "loop back" and allows you to test your | receiver. This is called a "loop back" and allows you to test your | ||
| transmitter and receiver together - whatever the transmitter sends | transmitter and receiver together - whatever the transmitter sends | ||
| serially will be received by the receiver and presented back to the | serially will be received by the receiver and presented back to the | ||
| - | host as an 8-bit received data word. | + | host as an 8-bit received data word. &/ |
| + | */ | ||
| + | |||
| + | 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. | ||
| <color red>Include a copy of your top-level module in your laboratory | <color red>Include a copy of your top-level module in your laboratory | ||
| report</color> | report</color> | ||
| - | Now, write a Tcl file and do the simulation of your complete | + | |
| + | <color green> | ||
| + | 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). | ||
| + | </color> | ||
| + | |||
| + | /*Now, write a Tcl file and do the simulation of your complete | ||
| circuit. A complete transmission consists of applying txData and the | circuit. A complete transmission consists of applying txData and the | ||
| Send signal and waiting for a Sent signal to be returned and then | Send signal and waiting for a Sent signal to be returned and then | ||
| Line 167: | Line 182: | ||
| Your simulation should show that whatever byte was requested to be transmitted by your transmitter is what | Your simulation should show that whatever byte was requested to be transmitted by your transmitter is what | ||
| was received by your receiver. | was received by your receiver. | ||
| + | */ | ||
| + | /* | ||
| **Exercise 3 Pass-off:** <del>Show a TA your top level module and | **Exercise 3 Pass-off:** <del>Show a TA your top level module and | ||
| explain how we will know when the rx module has received a | explain how we will know when the rx module has received a | ||
| Line 189: | Line 206: | ||
| handshaking. | handshaking. | ||
| </color> | </color> | ||
| + | */ | ||
