ARM project: Week 3
Mouse interface in Verilog

Introduction

You may have noticed a few of the more interesting features on the Altera board. These include a VGA connector (used in the bonus track) and a PS/2 mouse or keyboard connector, which we are going to use now.

This week's task is to interface with a PS/2 serial mouse connected to the PS/2 connector on the Altera board and display the mouse status on the two 7-segment LEDs. In particular:

• Holding down the left or right button of the mouse must turn on the corresponding decimal point LED. (Obviously the dot must go off when the mouse button is released.)
• If button 1 of the Altera board is not pressed then the two digits must display, in hex, the 8 least significant bits of the absolute X position of the mouse.
• If button 1 is pressed, the digits must display the Y position instead.

Test your mouse hardware

To test your mouse hardware download mousetest.zip which contains mousetest.sof. This is the file normally produced by a successful compilation which the Programmer downloads to the board. To tell the Programmer to download mousetest.sof rather than the project you are working on, follow these steps:

1. If you have a project open, close it using File | Close Project
2. Open the Programmer, by choosing Tools | Programmer
3. If the hardware field does not read ByteBlaster MV [LTP1] use the procedure described in week 1 to add the ByteBlaster.
4. Click on "Add File", find mousetest.sof and add this file.
5. Select the Program/Configure option for mousetest.sof.
6. Click Start. This should download the data to the board, and the test will run. This test code indicates the direction that the mouse is traveling in on the LEDs. The decimal points on the LEDs indicate left and right mouse button presses. If your mouse doesn't appear to work then make sure that the mouse connector is firmly inserted and then download the test code again to reboot the mouse. If that doesn't fix it then please report the problem.
7. Once you have successfully run the test close the Programmer window and decline to save the settings when prompted.

Modules

• HexToLEDs.v, which you should be familiar with.
• ps2_mouse.v, which acts as a simple clocked serial input. It also contains some code which sends a byte out to the mouse when you download your program. This stream of pulses is required to initialize the mouse and tell it to send data normally. The signature is:
  module ps2_mouse(clock, mdata, mclock, data, receive_key);
  • input clock should be provided with the normal 25.175 MHz clock
  • inout mdata should be connected to the mouse data line
  • inout mclock should be connected to the mouse clock data line
  • output [7:0] data contains the latest byte to be read from the serial line
  • output receive_key changes state when a new byte is received on the serial line

Please note that the inout statement above are not input statements!

Mouse data format

The full details of the PS/2 mouse and keyboard protocol and of the PS/2 mouse and keyboard interface, as reverse-engineered and documented by Adam Chapweske, are very useful as a reference, but perhaps you'll appreciate a summary.

The mouse sends data to the "computer" (a.k.a. the Altera) in three bytes along the serial port.

• Byte 1 is the status byte, and has the structure:

  MSB 7	6	5	4	3	2	1	LSB 0
  Y Overflow	X Overflow	Y Sign	X Sign	1	Middle Button	Right Button	Left Button

• The sign and overflow bits in Byte 1 may be ignored for the purpose of this practical, but you'll need the button bits, and the 1 bit will be necessary to help make sure that your state machine is synchronized with the mouse.
• Byte 2 is the X change value. This is a signed eight-bit value representing the distance the mouse has moved since the last data packet.
• Byte 3 is the Y change value. This is a signed eight-bit value representing the distance the mouse has moved since the last data packet.

The project code

The core of your program should be a state machine with three states—one state for each byte input. The state machine should change state each time a new byte is received. Each state will deal with decoding the corresponding input byte. Note that the first byte has a valid bit and you should remain in the same state until this valid bit is set.

Project creation and new pin assignments

You haven't been given a .qsf file for this workshop, so you'll have to make one yourself. In fact, the .qsf file from week 1 will pretty much do, so download dice.qsf to this week's project directory, and rename it to mouse.qsf.

First open it using File | Open... (it is necessary to view "All Files (*.*)" before the .qsf will show up). One of the first things in the file (after Altera's copyright notice) is Verilog source file, but this mentions the dice.v file. Our file will be called mouse.v so change VERILOG_FILE dice.v to VERILOG_FILE mouse.v.

Further down the file the top level entity is identified as "dice". Corrent this by changing TOP_LEVEL_ENTITY dice to TOP_LEVEL_ENTITY mouse. Close the file.

Create a new 'mouse' project with the New Project Wizard. Provided the .qsf is located in your project directory it will be recognised and the pin assigments imported.

Use the Assignments | Assign Pins  dialog to add mclk on pin 30, and mdata on pin 31. Remember that they are actually bidirectional rather than just inputs.

If you experimented with the "testbed" module in week 1 you probably noticed how things can go subtly wrong (with little error reporting from the tools) when your pin assignments are incorrect. Therefore, before starting to program the mouse interface, it is a good idea to double-check that your pin assignments are correct. You may want to write a simple Verilog test program that exercises them: this would be laudable, but it is not a requirement. If you write such code, do not include it in your mini-report.

Tip of the day

You may find that the old compilations from previous workshops have consumed a lot of disk space with temporary files. It is safe to delete the files which you have not created (remember to keep .v, .qsf and .qpf files!).

Question 1

W3-Q1: What is the measured resolution of the particular mouse you are using, in the traditional barbarian unit of "dots per inch"?

Question 2

W3-Q2: Are the overflow flags ever set? (To answer this you will probably want to edit the verilog, for example to display something related to the flags rather than to X,Y; but you don't have to submit this modified code.)

Weekly mini-report

Submit your mini-report before the last timetabled session of this week according to the usual rules (live demo, email submission, paper submission).

Be sure to include the answers to the two questions in a comment at the end of your source.

Please don't leave submission to the last moment: expect queues for the demonstrators' attention during the last hour. If you haven't submitted by the end of the Thursday session, your next chance is on Monday, but with a penalty of 3 marks per weekday (i.e. 6 marks). Worth avoiding.