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 HDL coding knowledge and were unaware of how to build hardware in an FPGA or build a simple testbench. Over the course of this book, you’ve gone from simple logic functions utilizing switches to light LEDs to writing text out on a VGA screen.

In this chapter, we’ll investigate the Personal System/2 (PS/2) interface, which, although antiquated, 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 10, 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 that you can see how it operates. We’ll also adapt our temperature sensor to display on the VGA. Finally, we’ll take the audio...

Technical requirements

The technical requirements for this chapter are the same as those for Chapter 2, FPGA Programming Languages and Tools.

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/The-FPGA-Programming-Handbook-Second-Edition/tree/master/CH11.

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

The Nexys A7 only 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. The board uses a Programmable Interrupt Controllers (PIC) microcontroller, which handles the complexity of USB and converts the signaling to PS/2, which is a much older and simpler keyboard-and-mouse interface. The PIC source code for interfacing the USB to PS/2 is...

Investigating the keyboard interface

I’m sure you are familiar with computer keyboards as a user, but perhaps you don’t know 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 11.1: Keyboard matrix

The keyboard controller will apply a voltage across each input one at a time in our preceding example: in0, in1, in2, in3, and so on. With the voltage applied, it will monitor the outputs one at a time, out0, out1, out2, out3, and so on, to identify whether any key is pressed. In Figure 11.1, when the controller scans input 2, and the K key is depressed, output 2 will be active high.

Modern keyboards are a bit more complex than this, especially gaming keyboards...

Project 13 – Handling the keyboard

We’ve looked at what the PS/2 protocol 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 testbench so we can verify it. This cannot be built as is, but let’s look at it. Open up https://github.com/PacktPublishing/The-FPGA-Programming-Handbook-Second-Edition/blob/main/CH11/SystemVerilog/build/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:

SystemVerilog

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

Project 14 – 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 a 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 10, 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...

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 first, we will explore some more external interfaces using PMODs and then implement a Xilinx NIOS processor.

Questions

1. PS/2 keyboards use a two-wire interface consisting of:
   1. Keyup/keydown
   2. Clock/data
   3. Data in/data out
2. A scancode is generated whenever a key is:
   1. Pressed
   2. Released
   3. Held down
   4. All of the above
3. To display the scancodes on the VGA, we used:
   1. A hex-to-ASCII converter
   2. A shift register
   3. A BCD encoder
   4. (a) and (b)
4. To display audio data, how was the text state machine modified?
   1. It takes in 128 bits of graphical data and writes that to the correct address for that scan line using text_sm.
   2. The graphics are mapped to characters and we reuse the text_sm state variable.
   3. We created a new graphics state machine.
5. To trigger an audio update, we:
   1. Update on every sample captured
   2. Update every second
   3. Update on every vertical sync
   4. Update...

Answers

1. b
2. d
3. d
4. c
5. c

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

Join our community on Discord

Join our community’s Discord space for discussions with the authors and other readers:

https://packt.link/embedded