User`s manual

uses the par to ser and ser to par modules to initialize the accelerometer and
fetch x and y acceleration readings from it in a loop, averaging them using the
moving avg module.
3.2 Perspective transformation
The perspective transformation component is where all core computations are
performed. The accel lut module accepts the accelerometer readings from the
accelerometer as an index into a ROM (read-only memory) containing coordi-
nates of four coordinates of a quadrilateral. The corners of the quadrilateral
(after multiplexing with manual override parameters) are fed into the perspec-
tive params module, which computes necessary perspective transformation pa-
rameters. The perspective parameters are then fed into pixel map, which maps
the screen rectangle onto the quadrilateral described above via a perspective
transformation. The pixels kept module is a side module that accepts the cor-
ners of the quadrilateral, and computes the percentage of pixels kept during the
transformation. This is of use in the audio system.
3.3 I/O (Input/Output) interface
The input/output interface to various buttons/switches is contained in the top-
level labkit.v file. Here, the hardware of the labkit is mapped to the mod-
ules, and the functional components are connected together. The relevant but-
tons/switches are passed to move cursor module, which manipulates the corners
of the quadrilateral when the user wishes to manually adjust the correction. The
bram module implements a very simple 2 port block memory on the FPGA. Two
instances of this are created, one called ntsc buf storing the camera input, and
one called vga buf containing the processed output (from the perspective trans-
formation). Essentially, we have a pipeline formed: input camera writes to
ntsc buf, perspective transformation reads from ntsc buf and writes to vga buf,
and the output VGA signal is formed by looping over the vga buf.
3.4 Audio system
The audio system is responsible for receiving, saving, and playing back audio.
This requires interacting with several different pieces of hardware and external
modules. The top-level module of this functional component is audioManager.
When triggered by a switch setting, audioManager prepares itself for receiving
the audio tracks as a continuous stream of data from the external USB input
hardware. Because of the difficult-to-implement timing requirements of the
external hardware, we use the 6.111 staff provided usb input module to simplify
receiving data over USB. As audio data is being received over USB, it is written
to the labkit’s on-board flash memory. Flash memory is also difficult to use,
since a time-sensitive start up sequence needs to be followed to enable proper
use of the flash hardware. We made use of the staff provided flash manager,
test fsm, and flash int modules. This set of modules greatly abstracts away the
8