ARM project: Week 3
Mouse interface in Verilog

ARM project home | Tasks (weeks): 1 | 2 | 3 | 4


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:

Test your mouse hardware

To test your mouse hardware download 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.


There are several useful modules that you can use for this practical. These are:

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.

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.