In this laboratory you will create an asynchronous serial transmitter that will allow you to send ASCII characters from the NEXYS4 board to your computer.

• Learn how to implement state machines using behavioral SystemVerilog
• Understand how asynchronous communication works

Chapter 28 discusses the asynchronous transmitter in detail. You will want to review this chapter before beginning this lab and refer back to it when you have questions. Note that we will be using the method described in Section 28.3 (note there are at least two methods described in this section, we are doing the one reflected in Figures 28.8, 28.9, 28.11, 28.12, and programs 28.3.1).

In this lab we will operate the transmitter at a baud rate of 19,200 bits per second. We will transmit using odd parity and 8 bits of data.

How many clock cycles of the 100 MHz clock used on the FPGA board does it take to provide one bit of data using this baud rate?

How many bits are needed to count the clock cycles for each bit of data?

What is the maximum number of 8-bit ASCII characters that can be transmitted per second using your transmitter at a baud rate of 19,200? (make sure you consider the presence of the start bit, parity bit, and stop bit).

Begin your laboratory assignment by creating a module that has the following parameters and ports:

The transmitter consists of a control section and a data path section as shown in Figure 28.9 of the text. The code for the data path is given in Program 28.3.1.

The control section is outlined in Figure 28.11. As you can see, it requires two counters - one to time each bit period and one to count the bits.

Baud Rate Timer

Your transmitter will need a counter that counts the number of clock cycles needed for a single baud period. Create a counter using behavioral SystemVerilog with the following specifications:

• The size of the counter (in bits) is based on the baud rate and your system's 100MHz clock rate. The counter must have enough bits to represent the largest count value as determined by your calculations above.

The counter has an output signal that indicates when the counter has reached the last clock cycle of the baud period ('timerDone' in the system diagram). This signal is used as an input in the FSM. When the timer reaches this point, it must roll over to 0; the state machine design relies upon this.

Parity Generator

The parity calculation is actually embedded in the code of Program 28.3.1 - can you see where it is being done and how it is being done? Make sure you understand this.

Bit Counter

Create the Bit Counter which is responsible for counting the number of bits that have been transmitted. You can see in Figure 28.11 what signals the state machine uses to interact with the bit counter.

Datapath

Note that the data path outputs the correct bits needed in response to state machine outputs. Note that it is an always_ff block to ensure that the final output signal (sout) is registered to avoid glitching. The datapath code is outlined in Program 28.3.1.

FSM

Create the FSM as outlined in Figure 28.12 .

Use the following TCL script to simulate your tx module:

restart
 
# Start clock
add_force clk {0} {1 5} -repeat_every 10
run 10ns
 
# Reset design
add_force Reset 1
run 10ns
add_force Reset 0
run 10ns
 
# Run for some time
run 50us
 
# Send a byte
add_force -radix hex Din 47
add_force Send 1
run 10ns
add_force Send 0
run 1ms
 
# Send another byte
add_force -radix hex Din 4F
add_force Send 1
run 10ns
add_force Send 0
run 1ms

Look at the waveform and make sure your module is operating correctly. Check the simulation that:

• For each byte sent, the 8 data bits are output correctly in the correct order.
• Check that the parity output is correct.
• Check that the start and stop output is correct.
• Check that both of your timers are operating correctly; that they reset and increment in the correct conditions.

Exercise 1 Pass-off: Show a TA your waveform and discuss how the waveform demonstrates the above points.

When it looks like your tx module is working properly use the following testbench file to test it.

tb_tx.sv

Include a copy of the simulation console in your laboratory report when your simulation passes the testbench with no errors

Exercise 2 Pass-off: You don't need a TA to pass of this exercise, but make sure the testbench is working before moving on.

After simulating your module and verifying it operates, begin a new top-level module with the following ports:

Instance your tx module and make the following connections to your tx module:

• Connect the sout output of your tx module to your top-level tx_out output
• Connect the sout output of your tx module to your top-level tx_debug output (yes, the same signal)
• Connect an unused signal to the 'sent' signal of your tx module (while we will not use it, the sent signal is normally important for handshaking protocol)
• Connect the 8 switches to the 'din' input of your tx module
• Connect the top-level clock to the clk input of your tx module
• Create a signal named 'send' and attach it to the 'send' input of your tx module. We will discuss what logic will be used to drive this input later.
• Create a signal named 'reset' and attach it to the 'reset' input of your tx module. This will be created the same way as the 'send' signal.

Instance your seven segment display controller and connect the inputs to your controller as follows:

• Attach the 8 switches to the lower 8-bits of the data in of the seven-segment controller. Assign the upper 24 bits of the data in to '0'.
• Only display the bottom two digits of the seven segment display
• Do not use any of the digit points
• Attach the anode and segment signals of the controller to the top-level outputs of the top-level module

Create debounced 'send' and 'reset' signals as follows:

• Using the debouncer done in a previous lab, debounce the 'btnc' input to create the 'send' signal and feed into your design.
• Using another debouncer instance, debounce the 'btnd' input to create the 'reset' signal.

Exercise 3 Pass-off: Show a TA your top level module and explain why we need to debounce the button inputs.

Before synthesizing your design, you will need to create an .xdc file that contains the pin locations of each port in your design. Most of the pins used in this design are the same as pins used in previous designs (buttons, switches, seven-segment display, etc.). However, you will be using a new FPGA pin to connect to the UART/USB transciever and the debug port.

The following example code demonstrates how these I/O pins can be attached to your top-level FPGA pins:

set_property -dict { PACKAGE_PIN D4    IOSTANDARD LVCMOS33 } [get_ports { tx_out }]; #IO_L11N_T1_SRCC_35 Sch=uart_rxd_out
set_property -dict { PACKAGE_PIN C17   IOSTANDARD LVCMOS33 } [get_ports { tx_debug }]; #IO_L20N_T3_A19_15 Sch=ja[1]

After completing your .xdc file, proceed with the synthesis of your design.

Provide a summary of your synthesis warnings.

After successfully synthesizing your design, proceed with the implementation and bitstream generation of your design. Indicate the number of Look-up Tables (LUT) and Input/Output (I/O) pins for your design.

Exercise 4 Pass-off: There is no pass-off for this exercise.

Once the bitstream has been generated, download your bitstream to the FPGA. To test the transmitter, you will need to run a program called “PuTTY” that is installed on your computer. Follow the PuTTY tutorial to set it up.

If your PuTTY terminal is configured properly you should be able to send characters to the terminal by selecting the ASCII value of the character to send on the switches and pressing the center button.

Interesting control commands:

• 8'h07 - Bell (a sound, not a character)
• 8'h09 - Tab
• 8'h0C - Clear screen
• 8'h0A - Move cursor down (Line Feed)
• 8'h0D - Carriage Return

To pass off this laboratory, demonstrate to the TA the following:

• Pass-offs for Exercises 1, 2, and 3
• Your working top-level transmitter circuit (the TA will test your transmitter with several characters)

How many hours did you work on the lab?

Please provide any suggestions for improving this lab in the future.

Submit your SystemVerilog modules using the code submission on Learning Suite. (Make sure your SystemVerilog conforms to the lab SystemVerilog coding standards).

Here are some ideas for personal exploration in this laboratory:

• Experiment with different baud rates and see if you can communicate with the PC at a different baud rate.
• Augment your design to support either even or odd parity.
• Send a variety of interesting characters over the terminal and see how they respond.
• Hook up the tx debug signal to the oscilliscope and view the transfer of an 8-bit character.

Describe your personal exploration activities

TA Notes and Feedback