User`s manual

low-level details of working with the flash. When the audio is triggered via an
external button input, audioManager handles queuing up the appropriate set
of tracks for sequential playback. The percentage of pixels used is an external
input to audioManager from the pixels kept module.
4 Design Decisions
There are several noteworthy design decisions.
4.1 Use of 640 × 480 @60 Hz VGA
The first of them is the use of a 640 × 480 @60 Hz VGA display. The use of
640 × 480 as opposed to the more common higher resolutions found today is
due to the memory and computational limitations of our FPGA kit. Initially,
we hoped that we could get away with generic code that does not explicitly tie
in heavily with the specific screen resolution. Unfortunately, this is not easy,
since the choice of resolution influences many different aspects. Chief among
these are the sizes of memory vs available memory trade-off, the bit widths
of x and y coordinates, the size of the accel lut ROM, and the bit widths of
numerous other quantities such as the dividers and the multipliers in pixel map
and perspective params respectively. The choice of 60 Hz was made on the
basis of its almost guaranteed availability: almost all VGA displays support
this refresh rate.
4.2 Use of NTSC Camera as Input
Also related to input/output is our decision to use an NTSC camera feed as
the input to the FPGA. Ideally, we would have liked to hook up a computer’s
VGA signal to the FPGA, so that we can demonstrate the correction system
in a more realistic setting. Unfortunately, the labkit in this course has only a
single VGA port, ruling out this option.
4.3 Choice of Memory Architecture
Another major design decision made is the choice of memory architecture. We
initially planned on using the available 36 Mbits of ZBT memory spread across 2
banks. This would allow us to store at least 4 frames at full 640 ×480 resolution
and 24 bit color (8 bit R, 8 bit G, 8 bit B). Unfortunately, it turns out that
ZBT memory is not dual-ported, so read and write on the same bank can’t be
achieved simultaneously. Since the perspective transform (operating pixel by
pixel) turns out to be a huge computational bottleneck, we did not want to waste
additional time waiting for read/write on ZBT. Moreover, coordination between
the memory banks storing processed and unprocessed data would require some
sort of arbiter, adding complexity to our project. Thus, we chose instead to go
with the block memory on the FPGA. This can be made into true dual-port
9