Introduction

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:

Use the 24 MHz ARM clock (pin 211 on the FLEX and called XCLK in
the ACF file) for your circuit, not the 25.175 MHz clock on the Altera
board so that the FLEX chip is synchronized with the signals from the
ARM.

You will see from the memory timing diagrams in
memo 21
that the ARM board provides the following signals to indicate memory
writes to the FLEX:

nCE2 is "not(chip enable 2)" from the
address decode circuitry on the ARM board used to indicate when the
FLEX is being accessed (low when ARM is accessing the FLEX)

nWE is "not(write enable)" from the ARM chip
(i.e. high for a read, low for a write)

So, the ARM board is
writing data to the FLEX when !nCE2 &&
!nWE.Hint. In job 1, the FLEX doesn't write to the bus, so enable_data_out can be kept inactive all the time. In
job 2, instead, the FLEX will also write. When you get to that stage,
note that you only need a combinational function (i.e. no
latches/registers required) between the nCE2 and
nWE wires and the enable_data_out wire (i.e. use continuous assignment).

The bidirectional data bus from the ARM (d[7:0]) will have data on it during write cycles
indicated by the above control signals.

The nWAIT line can be driven low by a
peripheral when that peripheral wants to introduce wait states while
being read or written by the ARM. For this workshop we don't need to
do this.

Finally, the MAX chip on the Altera board has been programmed to
act as a safe interface between the ARM and the FLEX chip. To enable
the MAX you need to push switch SW0 (see figure below) down which
should illuminate a decimal point on the other LED display. This LED
display will indicate and error ("Er") if you have programmed the FLEX
incorrectly. The "Er" will be cleared if you hit the "reset" button
on the ARM board. Reprogramming the FLEX may also do the trick.

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.

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 mouse interface that you wrote in week 3, extended to store
16 bit X and Y values.

Verilog which causes the FLEX to behave like an area of memory so
that the X, Y and mouse button bits can be read by the ARM, and so
that the low byte of X can be written back.

An ARM program which polls FLEX and responds accordingly.

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.

Decode the lower 8 bits of the address (a[7:0])
to select which data it should be outputting.

Data is output via the bidirectional data bus
(d[7:0]) which requires the use of tristate buffers,
e.g. for just the first bit of data use:

TRI tribuf0(my_data[0],enable_data_out,d[0]);

See Help | Primitives ... | TRI in MAX+Plus II for
a description of the TRI state module.

The nOE signal into the FLEX is "not(output
enable)" from the ARM chip, i.e. low when ARM wishes to read data from
the FLEX. Use it together with nWE and nCE2 to control when the tristate buffers are to be
enabled, i.e. your definition for enable_data_out
needs to be of the following form (get it right otherwise you risk
damaging the FLEX or the ARM if both try to drive data at the same
time):

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.:

Beware!

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

It is not sufficient to display some random numbers when you move
the mouse around and click it. The numbers also have to be
correct, incrementing smoothly as you go forward, and
decrementing smoothly as you go back. Hint: pay attention to
the top byte of the 16 bit position, which you did not have in week 3.

The low byte of X which appears on the FLEX display must be the
outcome of a round trip from FLEX to ARM to FLEX. It can't just come
directly from the FLEX register holding X.

The LED display of the FLEX should only be updated when the ARM
writes to it, not continuously as the mouse moves. This is different
from what happened in week 3.

Remember to include the reset functionality for button1 of the
FLEX.

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.

Don't submit the code for job 1.

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.

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.

You must make good use of modular decomposition to ensure that no
module (whether hardware or software) is too complex.

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

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.

Introduction. (0.5 to 1 page).

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).

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).

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).

Conclusions. (0.5 to 1 page).

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).

Complete the last of your supplied cover sheets and prepend it to
the report.

Having done this, submit the report.

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.

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.