Chapter 10: Bringing It All Together

Take a deep breath and reflect on what you've accomplished in getting to this point in the book. You started the journey with little or no SystemVerilog knowledge and were unaware of how to build hardware in an FPGA. Over the course of this book, you've gone from simple logic functions utilizing switches to light LEDs to as far as writing text out on a VGA screen.

In this chapter, we'll investigate the PS/2 interface, which is a way of communicating with a keyboard or mouse that Digilent has chosen to use. We'll then be taking our VGA from Chapter 9, A Better Way to Display – VGA, and adapting it to display more data than the resolution we currently have selected. We'll use it to output scan codes from the keyboard so you can see how it operates. We'll also adapt our temperature sensor to display on the VGA. Finally, we'll take the audio captured by the PDM microphone and display it as a waveform on the...

Technical requirements

The technical requirements for this chapter are the same as those for Chapter 1, Introduction to FPGA Architectures and Xilinx Vivado.

To follow along with the examples and the project, you can find the code files for this chapter at the following repository on GitHub: https://github.com/PacktPublishing/Learn-FPGA-Programming/tree/master/CH10.

If you want to implement the project on the board, you'll require a VGA-capable monitor, cable, and USB keyboard.

Important note

The Nexys A7 supports a USB keyboard capable of supporting PS/2 BIOS modes. While writing this chapter, I was only able to find one older keyboard that worked 100%. This is a limitation of the Digilent board as the PIC source code for interfacing the USB to PS/2 is closed source. If you can't find a compatible keyboard or don't want to buy one, you can still view the PS/2 output in the Integrate Logic Analyzer (ILA). Here is one keyboard that is known to work: https...

Investigating the keyboard interface

I'm sure you are familiar with computer keyboards as a user, but perhaps not how keyboards are physically implemented.

Keyboards consist of a matrix of switches. When you depress a key, you close a circuit. A keyboard controller activates one line at a time and checks to see which lines are connected, which will identify a unique key (assuming only one key is pressed). It will also detect when a key is released:

Figure 10.1 – Keyboard matrix

The keyboard controller will apply a voltage across each input one at a time. With the voltage applied, it will look at the outputs to identify whether any key is pressed. In Figure 10.1, when the controller scans input 2, and key K is depressed, output 2 will be active high.

When IBM introduced the PS/2 computer, they introduced a new keyboard and mouse standard. The keyboard pulled the matrix decoder into the keyboard and simplified the interface to two wires. The...

Project 12 – keyboard handling

We've looked at what the PS/2 interface looks like. Let's now put together a simple interface so that we can test our knowledge before we move on to our design integration. The first step is that we need to debounce our PS/2 signals. I've put together a debounce circuit and test bench so we can verify it. This cannot be built as is, but let's look at it. Open up https://github.com/PacktPublishing/Learn-FPGA-Programming/blob/master/CH10/build/debounce/debounce.xpr. This version of the code will act as a reusable core. We want to make sure that we only change state after we've seen the CYCLES number of the same value. This will act as our debouncing circuit.

The interface is straightforward, as we can see in the following code:

module debounce
  #(parameter   CYCLES = 16)
  (input wire   clk,
   input wire   sig_in,
   output...

Project 13 – bringing it all together

You should take a moment to consider the path you've taken over the course of the book. In the beginning, you toggled some switches and lit some lights. You've built some simple designs, such as a calculator and traffic light controller. You've captured and converted temperature sensor information, captured audio data, and displayed data on a VGA monitor.

Now we'll look back on these projects to gather a few of them and combine them into a final design. The base will be the VGA we created in Chapter 9, A Better Way to Display – VGA. This will allow us to easily display text or graphics. In the previous section, we simulated the PS/2. However, we haven't seen it in operation. Luckily, every keypress generates at least 3 bytes, 1 byte for keydown and 2 bytes for keyup for most keys. We can come up with a clever way of displaying this to the screen. Finally, we can look at the audio data. We can see the data...

Summary

In this chapter, we've explored the PS/2 keyboard interface by creating an interface that can write to and receive data from the keyboard. With the PS/2 ready to use, we've then taken pieces from the last few chapters: the VGA to display our data, the temperature sensor to provide some numerical output, and the PDM interface so we can add something more graphics-oriented. You've now completed the journey from basic logic gates to coding something that can display text and graphics on the screen. It's possible to go much further with writing pure SystemVerilog, but looking at a soft processor is a good next step.

There is one final chapter containing some more advanced constructs that can help in your design and simulation and then you'll be ready to tackle your own design challenges.

Questions

1. PS/2 keyboards use a two-wire interface consisting of:

   a) Keyup/keydown

   b) Clock/data

   c) Data in/data out

2. A scancode is generated whenever a key is:

   a) Pressed

   b) Released

   c) Held down

   d) All of the above

3. To display the scancodes on the VGA, we used:

   a) A hex to ASCII converter

   b) A shift register

   c) A BCD encoder

   d) (a) and (b)

4. To display audio data, how was the text state machine modified?

   a) It takes in 128 bits of graphical data and writes that to the correct address for that scanline using text_sm.

   b) The graphics are mapped to characters and we reuse the text_sm state variable.

   c) We created a new graphics state machine.

5. To trigger an audio update, we:

   a) Update on every sample captured

   b) Update every second

   c) Update on every vertical sync

   d) Update whenever nothing else is going on

Challenge

Usually, audio data is displayed horizontally. Can you modify the code to create a horizontal display? This is a challenging problem and could take a little while to get right. Here are a couple of hints:

• You may want to clear the area and then simply plot the dots that need to be set.
• You may want to buffer up 128 bits of each scanline and use the existing FIFO interface to display the data.

There are a bunch of ways to accomplish this, but you should be able to find one that works.

Further reading

For more information about what was covered in this chapter, please refer to the following link:

• https://www.avrfreaks.net/sites/default/files/PS2%20Keyboard.pdf