ARM project: Week 4
Accessing the mouse from the ARM

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


This week concludes the project, so it's time to learn a bit about hardware/software codesign. Your task is to interface and access the mouse from the ARM. You will be writing a small program for the ARM as well as reusing and modifying some of the Verilog you have written for week 3. The work is split into two jobs to help you build up the hardware and software in stages.

Job 1 (ARM writing to FLEX)

Your first job is to interface the ARM to the 7-segment LEDs controlled by the FLEX chip on the Altera board. This will be used in job 2 to display mouse data, but for job 1 you could just display an incrementing number. The FLEX chip has been allocated a chunk of the ARM's address space and so it needs to act like an memory device to allow the ARM to write data to it. In job 2 the FLEX will also allow the ARM to read data from it.

You need to write some Verilog code for the FLEX to latch data written by the ARM, decode the data (using the HexToLEDs module you know and love) and output the hex digits on the LEDs.

To make the FLEX respond to write requests from the ARM, you will need to:

Pin definitions for the FLEX chip are in fullmouse.acf. To get you started with your Verilog, below is some suitable code for the top level module, including the mouse interface and data output bits needed for job 2 (which you can ignore for now) and the tristate buffer for nWAIT mentioned above.

module fullmouse(led1, led0, mdata, mclock, d, a, 
    XCLK, nCE2, nOE, nWE, INT4, nWAIT);

    output [7:0] led1, led0; // 8-bit outputs to LEDs
    inout mdata, mclock; // mouse serial interface
    inout [7:0] d; // bidirectional data bus
    input [7:0] a; // address bus
    input XCLK, nCE2, nOE, nWE; // clock and memory bus control
    output INT4; // interrupt 4 line
    inout  nWAIT; // bidirectional memory timing control

    TRI tbuf_for_nWAIT(1, 0, nWAIT); // make nWAIT be "z"
    // TUT: the tristate buffer takes (input, enable, output)

    wire [7:0] data_out = 0; // zero data output to ARM for now
    wire enable_data_out = 0; // don't output data to ARM for now
    TRI tbuf_for_D0(data_out[0], enable_data_out, d[0]);
    TRI tbuf_for_D1(data_out[1], enable_data_out, d[1]);
    TRI tbuf_for_D2(data_out[2], enable_data_out, d[2]);
    TRI tbuf_for_D3(data_out[3], enable_data_out, d[3]);
    TRI tbuf_for_D4(data_out[4], enable_data_out, d[4]);
    TRI tbuf_for_D5(data_out[5], enable_data_out, d[5]);
    TRI tbuf_for_D6(data_out[6], enable_data_out, d[6]);
    TRI tbuf_for_D7(data_out[7], enable_data_out, d[7]);
    assign INT4 = 0; // disable interrupts
    assign mdata = 1'bz; // don't use mouse data for now (tristate)
    assign mclock = 1'bz; // don't use mouse clock for now (tristate)

Write an accompanying piece of ARM assembler to write values to the LEDs. The ARM to FLEX data bus is just 8 bits wide so use the strb instruction to store a byte to the FLEX since a str instruction will result in 4 bytes being written. The FLEX chip is memory mapped onto the ARMs memory map over the area 0x08000000 to 0x0bffffff. Since the FLEX is only fed the first 8 address lines, only addresses 0x08000000 to 0x080000ff are useful, the higher addresses mapping onto the lower ones (e.g. 0x08000103 looks the same as 0x08000003 to the FLEX).

For more detail on the interface between the FLEX and the ARM, see memo 21.

Job 2 (Bringing it all together)

The task for this week, and in fact for the whole project, is to interface the mouse to the ARM in such a way that pressing either mouse button causes the ARM to print the current "position" of the mouse in the debugger. The position must be an (X, Y) pair where X and Y are both signed 16 bit numbers. The lower 8 bits of the X value must also be written back from the ARM to the 7-segment LEDs of the FLEX when a mouse button is pressed. If both mouse buttons are pressed simultaneously then the program must terminate. Pressing button 1 of the Altera board must reset the mouse position to (0,0)—this will be useful for testing.

To do this you will need:

The program should only print the X and Y values when the buttons are first pressed, not while they are held down.

To allow the ARM to read data from the FLEX, you will need to do the following.

	assign enable_data_out = !nOE && (your equations here);

Note that the ARM is configured to treat this bus as 8 bits wide so if you use ldr to load a 32 bit word the ARM will do four 8 bit reads on your behalf.

Hint: to multiplex a set of buses together you can use the ?: operator multiple times, e.g.:

    assign data_out = (select_bus == 2'd0) ? bus0 :
        (select_bus == 2'd1) ? bus1 :
        (select_bus == 2'd2) ? bus2 : bus3;


To avoid confusion and misunderstanding over the requirements, let me point out some obvious things to which you should nevertheless pay attention.

Question 1

W4-Q1: the nWAIT line is being set to "z" in the supplied code, so basically we never drive it. Is there any difference between doing this and simply removing that line from both the Verilog and the .acf? Which is better? Explain your answer.

Question 2

W4-Q2: this week we use the XCLK on pin 211 instead of the usual clock on pin 91. Why? Could we have used the old one instead? Why? Could we have used the XCLK in previous weeks? If no, why? If yes, why didn't we?

Weekly mini-report

Submit your mini-report before 11:00 on Thursday according to the usual rules (live demo, email submission, paper submission). Please don't leave this to the last moment: expect queues for the demonstrators' attention during the last hour, and remember that there are no more sessions after that, so no more chances to submit later.

  1. Don't submit the code for job 1.
  2. Your Verilog and ARM code for job 2 must be cleanly formatted and commented. Use the Verilog and ARM templates from weeks 1 and 2, with the appropriate changes.
  3. 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 widely.
  4. You must make good use of modular decomposition to ensure that no module (whether hardware or software) is too complex.
  5. Be sure to include the answers to the two questions in a comment at the end of your Verilog source.

Final report

The spirit of the report is to explain to your readers what you gained, in all possible dimensions, from taking part in this project. This, of course, will be a reflection of how much you put in. The report should be a critical assessment of the work performed and the skills acquired, as opposed to a flat chronicle of what was done. Even when some of the weekly deliverables were poor or incomplete, the final report can stil get full marks if it shows that the author learnt something useful from the experience.

Keep the report between 6 and 10 sides of A4 or it will be penalized in the marking. The recommended format, which will help you produce a well structured report of the correct length, is as follows.

  1. Introduction. (0.5 to 1 page).
  2. Weekly tasks. Individual descriptions of the four weekly tasks, highlighting your "light bulb" moments (useful insights you got while performing that week's task, or moments when you got over a major stumbling block) and any significant design decisions you took (roughly 1 page per week, total 4).
  3. Debugging methodologies. What were the most useful techniques you adopted to identify and fix bugs in your Verilog and ARM code? (1 to 2 pages).
  4. Challenges and lessons learned. A commented list of the most interesting problems you encountered, the way you solved them, and the lessons you learned from your experience with this project. For items previously covered, mentioning the issue and referencing the relevant section is sufficient (about 1 page).
  5. Conclusions. (0.5 to 1 page).
  6. Appendix: your weekly mini-reports and their cover sheets (only the first three, since the last one will not have been returned to you by the time you submit the final report).
  7. Complete the last of your supplied cover sheets and prepend it to the report.
Having done this, submit the report.
  1. Email a PDF version of the final report as a file attachment to (not to my regular email address). Do not zip, tar, gzip etc: just send the raw PDF.
  2. Hand in a printed version of the final report, with your first three mini-reports as an appendix, to the Teaching Office.

Both of these must be received by 17:00 on Friday 6th June 2003 (last day of week 4 of the project, but not a timetabled session). This is the most serious deadline of the project: the department will grant no extensions to it.