User`s manual

deleting its contents, which the labkit automatically does when it is powered
on, the module also has a “reset disable” switch.
When in “write mode”, the labkit prepares itself to receive data from the usb
hardware, via the usb input module provided by the staff. Whenever usb input
indicates a new data sample is available, the “dowrite” input to the staff pro-
vided flash manager module is asserted to be true, in order to trigger the write
operation. The system continues in this cycle until the user’s computer indicates
all data has been transmitted, at which time he must exit write mode by manip-
ulating the switches to “read mode.” Due to the limitations of flash manager,
data must be written in one session - the user does not have the ability to leave
“write mode,” analyze the data on the flash memory, and re-enter “write mode”
to continue writing, without first resetting the flash and deleting all the data
it contains. As a result, this module inherits these limitations, and so a user
may have to manually disable the “reset disable” switch to trigger a reset if his
data transfer was to fail. When in “read mode” the flash memory’s contents
can be retrived one location at a time, by setting the read address parameter
“raddr”. We keep this value at address 0, until we receive the signal to begin
audio playback. Based on the percentage of pixels kept, an input signal to the
module, the sequence of audio tracks to be played is decided. For example, if
eighty-nine percent of pixels are used, four audio tracks are queued for playback:
“Eighty,” “Nine,” “Percent,” “Used.” In particular, the number eighty nine is
constructed out of two separate sequential tracks instead of a single recording.
This system allows us to save memory, reducing transfer time and accumulated
error, at the expense of additional complexity in the module.
Having decided what tracks are to be played back, playback begins by cal-
culating the address of the currently playing track, and retriving the contents
of that memory location. While many schemes may be used to calculate the
location of the track, we made our recording so that every track is exactly one
second long. We then used a simple multiplication of one second of samples by a
track index to calculate the track address. Based on the AC97’s external 48kHz
clock, we provided a new audio sample to the AC97 to acheive audio playback.
After one second of samples had been played back, we calculated the address of
the next track queued and began playback. A special end of playback marker
called “UNUSED TRACK” halted playback.
5.15 BCD (Shantanu)
This module converts from a binary representation to a decimal representation.
It was used within the audioManager module to convert the percentage of pix-
els kept from binary to a decimal representation in order to assign the tracks
to be played. This was necessary since digital systems naturally use binary
representations, but our audio output was necessarily in decimal.
Technically, we opted to implement this module as a look-up table that as-
signed the decimal ones and tens place based on the input value. The alternative
was to use a computational algorithm implemented in Verilog, which was widely
available. We used the look-up table because we thought it provided more clar-
21