User`s manual

For us, this was of use in generating a clock with a frequency on the order
of a Hz for synchronizing the quadrilateral corner locations and perspective
transform parameters. It was also of use in generating a clock signal that met the
manufacturer specs for the accelerometer (see the acc section). It is implemented
by having a looping counter that would result in an inversion of the clock signal
every time the counter hit a certain number of “ticks”. Note that this method
is not a robust way of generating an in-phase clock with no skew. It is, however,
quite well suited for the task of generating much lower frequency clocks, such as
a 1000 times lower frequency. For other applications, such as dividing a clock
frequency by a factor of 2, we used Xilinx’s DCM (Digital Clock Manager)
instead.
5.10 move cursor (Ganesh)
The move cursor module is a user interface module for manipulating the four
corners of a quadrilateral. It allows one to move the four corners of a quadri-
lateral by pressing the four arrow keys and selecting the corner index through
the switches on the labkit. To avoid accidental manual adjustment of keystone
correction, the movement can only be done when an override switch is on. This
module is very similar to the controls used to move the paddle in the Pong game
that we designed for Lab 3, and no tricky debugging was needed for this.
5.11 perspective params (Ganesh)
The perspective params module lies at the very heart of this project. It accepts
a list of the four corners of the quadrilateral (x
1
, y
1
), (x
2
, y
2
), (x
3
, y
3
), (x
4
, y
4
)
and finds the parameters p
i
, 1 ≤ i ≤ 9 such that the general perspective trans-
formation:
(x, y) →

p
1
x + p
2
y + p
3
p
7
x + p
8
y + p
9
,
p
4
x + p
5
y + p
6
p
7
x + p
8
y + p
9

(2)
maps the outer coordinates of the screen (0, 0), (0, 480), (640, 480), (640, 0) onto
(x
1
, y
1
), (x
2
, y
2
), (x
3
, y
3
), (x
4
, y
4
) respectively. The module also computes the
coefficients pinv
i
of the inverse mapping, which is also a perspective transfor-
mation (due to the algebraic group structure of perspective transformations
which can be checked by direct calculation). The reason for computing the
pinv
i
is mainly due to our initial goal of having a “memory-less” output trans-
formation, in the sense that given the desired VGA coordinate, we can compute
the pre-image of that point. This in turn was due to an inadequate under-
standing of the FPGA memory and VGA behavior. For instance, we assumed
that the VGA frame rate can be controlled simply by adjusting the VGA clock,
an assumption that is incorrect. This lack of understanding at one point al-
most threatened the successful completion of our project, and thus we strongly
recommend future 6.111 students to think and discuss very hard the hardware
limitations before starting actual implementation work. We were fortunately
able to come up with the BRAM design, which although suffers from poorer
image quality, nevertheless demonstrates the soundness of our algorithm. It
16