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, and a PS/2 mouse or keyboard connector. We are not going to play with the VGA port in this workshop - it's definitely one of the more amusing ways of blowing up a monitor. However, the mouse port looks sufficiently fun, and relatively safe.

This week's task is to interface correctly with a PS/2 serial mouse connected to the PS/2 connector on the Altera board. You should be able to output to the LEDs the current absolute x position of the mouse pointer, and also the first two mouse buttons should be represented on the decimal point LEDs.

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. Open the Programmer, by choosing MAX+plus II | Programmer, or by clicking on the shortcut button, which looks like this:
    
2. Switch on JTAG | Multi-Device JTAG chain. Turning it on may open a dialogue box, otherwise open it yourself using JTAG | Multi-Device JTAG chain setup.
    
3. The white box in the centre of this dialogue box should be empty; if not, click on Delete All.
    
4. Now click on Select Programming File and find mousetest.sof.
    
5. Back in the Multi-Device JTAG chain setup dialogue box, click on Add to add the programming file to the list.
    
6. Click on Detect JTAG chain info. If the Altera board is plugged in, and you have set up the dialogue box correctly, you will get a message telling you so.
    
7. Close the dialogue box with OK, and click on Configure. 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.
    
8. Once you have successfully run a test don't forget to switch off JTAG | Multi-Device JTAG chain before continuing work on your project.

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.175MHz 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! If you get this wrong it frequently crashes the MAX+plus II (sigh!).

Mouse data format

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.

Pin assignments

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

First open it using File | Open.... The first thing in the file (after Altera's copyright notice) is the assignments, but they are all for a chip called "dice". Our new chip is going to be called "mouse", so indicate this by changing CHIP dice to CHIP mouse.

Now close the .acf file. Make sure you have the right project name set, and open Assign | Pin/Location/Chip....

To add an input, type the new name into Node Name, and the pin number into Pin. Then click on Add, and then OK. You will need to add mclk on pin 30, and mdata on pin 31. Remember that they are actually inouts rather than just inputs.

There is no facility to rename an input. If you need to do that, you must first delete the old one (select it from the list and click Delete) and then add the new one.

The practice we had in Week 1 with the "testbed" module should have taught you something about how things can go subtly wrong (with little error reporting from the tools) when your pin assignments are wrong. 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 your .v and .acf files!).

Question 1

W3-Q1: What is the resolution of the mouse?

Question 2

W3-Q2: Are the overflow flags ever set?

Weekly mini-report

Submit the following to one of the demonstrators before the end of the last session of this week on Thursday morning.

1. Your Verilog code must be cleanly formatted and commented.
2. The Verilog code must be strictly synchronous with all clocks coming from one of the two clock distribution networks. Derived clocks which are distributed over programmable wiring are dangerous because clock skew can vary widly.
3. You must give a live demonstration of your solution.
4. You must make good use of modular decomposition to ensure that no module is too complex.
5. Answers to the two questions for this week must be added to the end of your code. You will need to add some verilog code in order to answer the second question (i.e. to detect if the overflow flags are ever set).
6. The following header must be added to all code submitted:

   //////////////////////////////////////////////////////////////////////////////
   // ARM Project - Week 3
   //
   // Your name
   // Your college
   // date
   //////////////////////////////////////////////////////////////////////////////
   

7. Complete one of the supplied cover sheets and prepend it to the listing.