Laboratory III

This laboratory begins the process of developing a video display system using the RC200E touchscreen as the output device and the two RAM chips on the RC200E as a framebuffer. For this lab, you will learn to read information from the keyboard, to read and write RAM, and to write text messages on the screen.

Background

When you finish this project, you will have configured the RC200E to read text from the keyboard, store the text in one of the “ZBT SRAM” chips external to the FPGA, read the text back from the memory, and display it on the video screen. The memory can be read and written using standard PAL macros; it uses a one-stage pipeline for reading and writing, so it's called a “PL1RAM” in the PAL documentation. Reading from the keyboard andwriting text to the screen are also done using PAL macros, but these two sets of functions are documented in a separate manual (in the same directory as the PAL Reference Manual), called the PAL Cores Manual. Writing text to the screen is done using the PAL console core, which simulates a text window on a computer.

Because your projects for this lab will be using the video display, you will have to use the RC200E clock signal that is syncronized with the drawing speed of the touchscreen: 25.175MHz. For simulation, you will probably want to use a slower clock speed, such as 5MHz. This slower clock speed will make the Pal Virtual Console display only part of the screen image during simulation, but it should be enough to verify that your code works before you run it on the hardware.

Notes: The projects for this lab will take a relatively long time to compile and build. Don't be alarmed! Also, in lab on October 7, I mentioned to some of you that the times might be shortened if we turned off the hyperthreading feature of the CPUs. I did the experiment later in the day, and found that it made no difference. Project 2 took 4 minutes and 5 seconds to build for debug with hyperthreading enabled compared to 4 minutes and 4 seconds without it. The EDIF builds took 1:23 without and 1:21 with. A particularly frustrating scenario is when you accidentally start to compile a simulation and want to terminate it. If you click on the "stop build" icon, you get a message to wait -- and you have to wait just as long as if you hadn't tried to stop the compilation. In this case, you can start the Task Manager (Right click on the Task Bar), go to the Processes tab, find the cc1plus.exe process, and terminate it. You'll get a flurry of messages in the DK console, but no harm will be done.

Project 1: Read From Keyboard and Write to Seven Segment Display

Create a new workspace, Laboratory III, under your My Projects directory, and create a new project named something like ”Keyboard to Seven Segment Display,” and add a Handel-C source file with a meaningful name. In addition to the normal header files and libraries, you will need to #include the pal_keyboard.hch header file and the pal_keyboard.hcl library.

Be sure to define the proper values for PAL_TARGET_CLOCK_RATE for Debug and EDIF as described above. (Aside: You can use the Build -> Configurations menu to delete the configurations you don't need: Generic, Verilog, VHDL, SystemC, and Release. This can make managing the project a little easier.)

Use the Pal Cores manual to find out how to read ASCII characters from the keyboard. There is sample code in the manual that you can use as a model. You don't need to use a macro proc for your "UserCode," but you do need to follow the rest of the model quite precisely to get the timing right. Code your Handel-C program so that it reads characters and displays their hexadecimal code on the seven segment displays. First test the code using the simulator, which you will find very entertaining. The Pal console will show two panels for the keyboard: the left one is for input from the keyboard, and the right one is for output to the keyboard. (What gets output to a keyboard?) The input to the keyboard has to be given as scan codes, which are the numbers that get sent from the keyboard to identify every key press and release. The top part of the left panel lets you browse to a file that will be used for simulated input (a plain text file such as your .hcc file will work), but the bottom part is where you get to enter scan codes one at a time to make sure the hex display is correct. Try these codes to get you started: 28 (scan code for pressing the A key), 240, 28 (the two-byte sequence of scan codes for releasing the A key). You should see the hexadecimal representation of the ASCII code for 'a' in the seven segment display: 0x61. Now try entering the scan code for pressing the left shift key, 18, followed by the scan code for pressing the A key again. Now you should see the ASCII code for 'A': 0x41. You will find you can probably cheat a little and simulate pressing a key twice without releasing in. (What does 28, 18, 28, 240, 18, 28 produce?) There is a copy of Microsoft's scan code information you can look at to find out more than you are probably interested in knowing about this topic. (What is the scan code for the character B? What character has a scan code of 29?)

After you have simulated this project successfully, generate a bit file and test the code on an RC200E. Be sure to plug a keyboard into the PS2 connector next to the expansion header!

Project 2. Read from Keyboard and Write to Console

Create a second project in your Laboratory III workspace with a name like “Keyboard to Console”. Set it up as you did the first project, but add pal_console.hch to your includes and pal_console.hcl to your list of library files. You may cut and paste your code from the first project into your source file for this one to get started.

Use the Pal Cores manual to see how to use the Pal Console macros. Augment your previous code so that you display each ASCII character on the screen as it is typed (PalConsolePutChar()). The simulation will work differently now. In addition to the Keyboard Port tab in the virtual console, there will be a VGA tab that will show the video output, and which will also include a place on the top right where you can enter keyboard characters directly. (You can still do the scan code thing on the other tab if you prefer.) Note that the video display will be only a narrow slice of what would actually appear on the touchscreen. If you use a simulated clock speed of 5MHz you will see the leftmost 5/25th of the screen. Increase the clock rate to 10MHz, and you will see over a third of the screen, but the simulation will go slower.

Generate the bit file and verify that the code works the same way on the actual hardware.

Project 3. Keyboard to RAM and Back

For this project, start by looking at the PAL macros for one-stage pipelined RAM (PL1RAM) in section 4.3.9 of the regular Pal Manual (not the Pal Cores manual). There is no sample code to work from, but by now you should see how the PAL works: Do a PalPL1RAMRequire() to be sure the platform will support your project. (There are two RAM chips on the RC200E; we'll use just one for this project.) A call to PalPL1RAMRun() has to be initiated in parallel with everything else (this call never returns). A single call to PalPL1RAMEnable() has to precede all other calls. Then you can do reads and writes using the macros PalPL1RAMSetReadAddress(), PalPL1RAMRead(), PalPL1RAMSetWriteAddress(), and PalPL1RAMWrite().

The PL1RAM macros include operations for determining the number of bits in a memory address and the number of bits in an addressable unit of memory. Normally, we might ignore these since we know the properties of the RAM chips on our target platform: both consist of chips with 1024K 36-bit words. The simulator, however, simulates 2048K 32-bit words. So any variables that are going to hold addresses have to use PalPL1RAMGetMaxAddressWidth() to set their widths, and any variables that are going to hold data have to use PalPL1RAMGetMaxDataWidthCT() to set their widths.

Note: To write information into RAM, you must use PalPL1RAMSetWriteAddress() and PalPL1RAMWrite() on successive clock pulses. For example, the following code writes the data value 0x1234567 into memory location 5 and 0x89ABCDEF into memory location 3 on two successive clock pulses:

Sample Code

seq { PalPL1RAMSetWriteAddress(PalPL1RAMCT(0), 5); par { PalPL1RAMWrite(PalPL1RAMCT(0), 0x1234567; PalPL1RAMSetWriteAddress(PalPL1RAMCT(0), 3); } PalPL1RAMWrite(PalPL1RAMCT(0), 0x89ABCDEF); }

For this project, you are to store the characters that you read from the keyboard into successive RAM locations in addition to writing them to the Console and displaying their hex values on the seven segment displays. Any time the user presses one button, the console clears and the current contents of RAM are displayed. Pressing the other button clears the console display and clears the RAM.

Notes: i. Use two variables to hold the current and ending addresses in memory. Clearing the RAM consists simply of setting these two addresses to zero. ii. Trying to access RAM twice in the same clock cyle is an undefined operation, so use a semaphore to make reads and writes mutually exclusive operations.

There are three versions of this project for you to try in sequence. It's satisfactory to complete just the first version, but the other two are instructive if you have time to work on them:

1. Store one character in each word of RAM. This will limit your project to storage of a maximum of 1 million characters in an RC200E RAM chip or 2 million characters using the simulator.
2. Instead of just displaying the characters on the screen when reading back from memory, display memory as a hex dump like what you see in the simulator. If you haven't noticed it yet, the simulator's memory dump includes the representation of the characters to the right of the hex representation of the bytes. Your dump has to work within the output limit of 80 characters per line. Something like the following could be used to show the contents of 16 bytes of memory on a line, where 'aaaaaa' is the hexadecimal representation of the address of the first byte on the line, 'xx' is the hexadecimal representation of one byte of memory, and 'c' is the character represented by a byte of memory (or a dot if the byte doesn't contain an ASCII character code):
   Sample Output Line

   aaaaaa xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx cccccccccccccccc
   For you to decide: how to manage scrolling the output when there is too much to fit on the screen.
3. Store four characters in each word of RAM. Worse yet, try storing 4.5 characters in each word of RAM on the RC200E and 4.0 characters per word using the simulator.

Due Date: October 18

Starting with the third project, you are to document your Handel-C programs according to the Coding Guidelines for this course.

Use a word processor to prepare a report that summarizes your lab procedures and results. I prefer receiving PDF files, but MS Word documents and other formats are fine too. (All computers in the lab have Microsoft Office installed so you can use Word. Some have Macromedia Studio 8 installed, which adds a "Save as PDF" option to Word.)

When everything is ready, put a copy of your report in your Laboratory III directory and send me an email telling me the project is ready for grading.