Final Report

Michelle BergerJohn CurtinTrey GriffinAaron King

Mike NordfeltJeffrey Whitted

CPSC 483 – 502Spring 1999

Dr. Mahapatra

Abstract - PDACS is our acronym for Portable Digital Audio CoDec System. Our vision is to create a portable, hand-held device that will input an analog signal from an external microphone, convert it to a digital signal, compress the digitized audio real-time, and store it in serial flash memory. The user can then choose to upload his recording onto his personal PC, or play it back immediately using the internal speaker. The intended use of this product is for professors to tape their lectures and then upload them to the Internet to provide another study aid for students.

2

The PDACS Group would like to thank the following for their help with this project:

Scott Wadsworth, Undisputed Ruler of Room 218 Dr. Rabi Mahaptara, Visiting Assistant Professor

Dr. Jose Pineda de Gyvez, Associate Professor of Electrical EngineeringDr. Costas Georghiades, Jr. Professor of Electrical Engineering

Shanti GaviniDr. Pierce Cantrell, Associate Professor of Electrical Engineering

3

ABSTRACT………………………………………………………………………………………………….1

INTRODUCTION..........................................................................................................................................6

AUDIO SUBSYSTEM....................................................................................................................................8

Microphone Jack/Microphone Amplifier..................................................................................................9DC Offset/Inverter...................................................................................................................................10Input Filter..............................................................................................................................................11A/D Converter.........................................................................................................................................12D/A Converter.........................................................................................................................................13Inverter....................................................................................................................................................14Output Filter...........................................................................................................................................14Output Amplifier/Speaker.......................................................................................................................15Problems Encountered............................................................................................................................16Testing.....................................................................................................................................................18

COMPRESSION – THE SUBSYSTEM THAT ALMOST WAS............................................................21

Run Length Encoding..............................................................................................................................21Companding............................................................................................................................................21Vector Encoding......................................................................................................................................22DCT.........................................................................................................................................................22

MEMORY SUBSYSTEM............................................................................................................................24

The Write Operation...............................................................................................................................25The Read Operation................................................................................................................................26

SERIAL SUBSYSTEM................................................................................................................................30

MAX232 Driver/Receiver........................................................................................................................31PC16550D UART with FIFOs................................................................................................................31Connecting the Pieces.............................................................................................................................32Control Module.......................................................................................................................................33RS-232 Standard.....................................................................................................................................35

APPLICATION............................................................................................................................................38

Sister applications...................................................................................................................................40

SYSTEM INTEGRATION..........................................................................................................................42

CONCLUSION.............................................................................................................................................46

APPENDIX A – SOURCE CODE..............................................................................................................48

Audio Input Sampling Module...............................................................................................................48Memory Access Control Module............................................................................................................50Audio Output Module.............................................................................................................................51HEX-to-seven-segment decoder.............................................................................................................53Bar Graph Module..................................................................................................................................54Main Control Module..............................................................................................................................55Memory Control Module........................................................................................................................59Serial Module..........................................................................................................................................62Main App code........................................................................................................................................70Serial App code.......................................................................................................................................80Audio App...............................................................................................................................................83Initial attempt at Verilog DCT................................................................................................................85Run Length Decoding Compression.......................................................................................................93Run Length Encoding Algorithm............................................................................................................94DCT Example Test Code........................................................................................................................95DCT Compression Code.........................................................................................................................97DCT Decompression Code...................................................................................................................103

APPENDIX B – DATA SHEETS..............................................................................................................109

4

APPENDIX C - REFERENCES...............................................................................................................110

APPENDIX D – WAVE FILE FORMAT................................................................................................111

APPENDIX E – LOG FILE.......................................................................................................................114

5

Introduction

So in our quest to help both students and professors alike, we began the journey that would eventually lead to a functional tapeless recording device. Our initial step was to define what it was we wished to create, in the form of a list of objectives and deliverables. These defined what the final project would be able to do and gave our team a set of benchmarks by which we could compare our progress. What follows is a brief summary of what the final PDACS product was intended to accomplish:

1. Real time compression of 8-bit, 8Khz speech2. Storage and retrieval of the compressed sound in an affordable non-volatile memory.3. Decompression and Playback of stored audio though a built-in speaker or headphone

jack4. Serial interface with a PC for retrieval, archiving and distribution of the compressed

audio.5. An application that facilitates easy retrieval from the device as well as management

and organization of the different files.6. Built in controls on the device for Playing, Recording, and deletion of the sound file

Once our initial goals were outlined, we next took care of some practical matters that would facilitate the sharing of information within our group. This step was especially important since we had the largest group assembled in the lab. A major decision made early in our design process involved cataloguing our progress as a group. Leaving a spiral notebook by our workstation was suggested in class. Instead, our group constructed a web page on which we kept a log file of our work activities, an expenditures log of current costs incurred, previous deliverable reports, and other useful links or information. This site is located at http://www.cs.tamu.edu/people/mab5298. Setting this web page up took a few hours of work, but maintaining takes only a few extra minutes at the end of each work session. The benefits of being able to keep each other updated from anywhere without requiring meetings far outweighed the little time it took to maintain the site.

Before we began the daunting task of building this Portable Digital Audio CODEC System, we chose to employ a divide-and-conquer methodology, and divided the project up into a series of complementary subsystems. These different subsystems were tackled individually, and then recombined after each subsystem was proven to work sufficiently. Each of these subsystems was placed on a separate board, to allow for a parallel work structure and individual testing. So to subdivide this project into an approachable form, these different subsystems were assigned to various members of the group:

Audio Subsystem Compression Subsystem Memory Subsystem Serial Subsystem GUI Application

6

Next, these individual subsystems were addressed individually. When they were recombined at the end of the project, they came together to form a complete subsystem as demonstrated in Figure 1 below. This is a very high-level description of what is happening in PDACS, and the organization of how all the different subsystems fit together. We will next explore the intricacies of each of these individual subsystems.

Figure 1: PDACS General System Overview

7

Audio Subsystem

The purpose of the audio subsystem was to deliver telephone quality audio in digital form to the Xilinx and then playback that audio from the Xilinx through a speaker. From our research into audio recording, the concept of “telephone quality” can be defined as 8-bit, about 3kHz, mono speech. Nyquist’s theorem states that sampling rate must be 2 times the signal frequency in order to accurately reproduce a waveform. Since Nyquist’s theorem is a best case scenario, the audio was sampled and played back at 8 kHz. The 8-bits allow sound to be represented as one of 256 possible values along the input voltage range of 0 to 5V. This leads to step function of approximately 0.02V / bit.

The audio subsystem consists of two distinct systems: audio input (analog-digital conversion) and audio output (digital-analog conversion). During recording, audio is input via a microphone, amplified, filtered, digitized, and sent to the Xilinx. During playback, audio is converted back to analog, filtered, amplified, and output via the speaker. Figure 2.1 is a high-level flowchart of how the entire audio system works.

Figure 2.1: Audio Subsystem Flowchart

The following components were used to create the audio subsystem: 1: PC Microphone (3 band jack) 1: Microphone Jack 2: Linear Technologies LTC1062 5th Order Low-Pass Filters 1: Harris Semiconductor ADC0804 8-bit Analog-Digital Converter

8

Mic JackMic

Amp

Analog/DigitalConverter

Digital/AnalogConverter

FilterClock

Spkr

Input Filter(buffered output,

3 kHz LP)

Output Filter(3kHz LP)

InverterOutput Amp

8-bit bus

Bus Interface to Xilinx (8kHz sampling)

Chip Select

8-bit bus

DC Offset

AUDIO IN

AUDIO OUT

8-bit, 8kHz, Mono

1: Texas Instruments TLC7524 8-bit Digital-Analog Converter 1: 8 Ohm speaker 4: 741 OpAmps (used for various amplification circuits) 2: 351 High Speed OpAmps (used for various amplification circuits) 1: LF386 Audio Amplifier 1: 4MHz Crystal Oscillator 1: 74LS93 (4-bit Counter) 1: 74LS08 (2-input AND gate) Numerous passive components (resistors, potentiometers, capacitors)

Each circuit stage that appears in the flowchart will be discussed in detail. In addition to any discrete components that appear in the diagrams for each stage, numerous electrolytic and ceramic capacitors were placed between power and ground (+ end to power) to act as decouplers and reduce noise from the power supply. The values for these capacitors ranged from 0.1F to 10F.

Microphone Jack/Microphone Amplifier

The first stage consists of two components: the microphone jack and its amplifier. The microphone has two inputs (power and ground), and one output that is the signal generated from the microphone. The power supplied to the microphone jack is 5V. The other two pins on the microphone jack are not connected. Obtaining the pinout for the microphone jack was not an easy task; it actually proved to be impossible. Instead, the schematic in Figure 2.2 was used to determine which pins handled what function.

Figure 2.2: Schematic of Microphone Plug

Figure 2.3 details the connection of the microphone jack and amplifier.

9

Figure 2.3: Schematic for Microphone Jack and Microphone Amp

The output of the microphone is tied to a 351 opamp in an inverting configuration. The parallel combination of 470k and 330k resistors creates a gain of approximately 193V/V. It is important to note that, since this opamp is used in an inverting configuration, the output from this stage is actually an inverted, amplified signal. The gain level of 193V/V on the opamp is tuned to provide the desired voltage range (0 to 5V) from the microphone signal at a distance of about a foot. This distance works well with the microphone clipped to the shirt collar, which is how a professor would be most likely to use it. The gain on this stage can be increased or decreased to allow for the mike to be farther or closer to the source. However, gain on speech at a normal volume level should not rise far above 5V or fall far below 0V. The filter and A/D converter in later stages will not be able to handle anything outside of this range.

DC Offset/Inverter

The second stage consists of a single opamp that performs two functions: Invert and DC offset. Figure 2.4 details the configuration that accomplishes this. Inverting the signal is required because the previous stage used an opamp in an inverting configuration. A unity-gain inverter returns the signal to its original form.

Figure 2.4: Schematic of DC Offset/Unity Gain Inverter

The audio signal requires DC offset because the output voltage from the microphone has both positive and negative values and the filter and the A/D converter can only handle voltages from 0 to 5V. The resistors at the positive input of the opamp create an offset voltage of about 1V, which translates into a DC offset of about 2V at the output. Originally, we assumed that the range of values from the microphone would be symmetric about the offset point; this proved to be an invalid assumption. Careful analysis of recordings showed that the average value was slightly above the offset, which meant that more positive voltages were generated. To increase our ability to amplify, we moved the DC offset down to 2V.

Input Filter

10

The third input stage is a Linear Technologies 5th order Butterworth low-pass filter in an 8-pin dip package. As stated in the introduction to the audio subsystem, telephone quality speech includes frequencies up to about 3kHz. The mixing of analog and digital components creates spurious frequencies. These frequencies are not related to the audio but are easily heard. The digital signals from the A/D outputs and the D/A inputs switch from ‘0’ to ‘1’ in a very short time frame, creating unwanted ‘aliasing’ frequencies. In order to control the frequencies that were sampled, this low pass filter was used as an anti-aliasing agent.

If a signal frequency close to the ideal Nyquist rate is to be achieved, anti-aliasing filters are required to have a rolloff with very steep slope. A simple first-order active filter doesn’t measure up in this respect. Even filters as high as the 5th order switched-capacitor type used in this stage still have less than desirable rolloff. To compensate for this fact, the signal is ‘oversampled’. The corner for the low-pass filter in this stage is set at 3.33 kHz. Thus, the 6.66 kHz minimum sampling rate is comfortably under the 8 kHz sampling rate used in the audio subsystem.

Figure 2.5 details the setup of the low pass filter.Figure 2.5: Schematic for Low-Pass Filter

Three separate voltages were required to power the low-pass filter. In addition to GND, V+ was set at 5V and V- was set at –5V. In this configuration, the input of the filter accepts values only on the range of 0 to 5V. As discussed previously, the corner of the low-pass filter was set at 3.33kHz. To accomplish this, two things were necessary. The LTC1062 has a clock-definable cut-off frequency, which is input at COSC (pin 5). Also, external circuitry composed of resistors, capacitors, and a buffer were added to control the cutoff frequency.

The cutoff frequency is determined based on a ratio of 100:DIVDER RATIO (pin 4). Pin 4 at 5V results in 100:1, GND corresponds to 100:2, and –5V results in 100:4. This implementation of the low-pass filter used a 100:1 ratio. With input from the clock divider stage at fCLK = 333.33kHz, the corner was set at 3.33kHz. The external RC circuitry was used as an additional filter stage that also cornered at 3.33kHz. The values

11

for R were determined experimentally using the only values of C that we had in a ratio of 100:1.

In addition to the circuitry in the diagram, we also buffered the filter from the load of the A/D converter at the next stage. The buffer was a simple voltage follower built using a 741 opamp. Without this buffer, the filter would not corner correctly. The buffer output was then tied to the next stage – the A/D converter.

A/D Converter

The final input stage is the Harris Semiconductor ADC0804 A/D converter. The purpose of the A/D converter is to take analog input in the range of 0 to 5V and digitize it into 8-bits to be sent to the Xilinx. Though the ADC0804 is designed with clock inputs for a synchronous connection to a microprocessor, it is used in free-running mode in the PDACS audio subsystem. Figure 2.6 details the configuration of the ADC0804 in free-running mode.

Figure 2.6: Schematic for A/D Converter in Free-Running Mode

To configure the ADC0804 to run in free-running mode, CS* and RD* are grounded and WR* and INTR* are tied together. The N.O. on the WR* and INTR* pins stands for normally open. When the A/D is first turned on, the WR* and INTR* must be momentarily grounded. CLK R is tied back to CLK IN. V+

(VREF) is set as 5V and allowable determines the input voltage range. AGND and DGND are tied together on the same ground plane. In this mode, the A/D will convert its input at pin 6 to the outputs DB0-DB7 at a rate of 8888 conv/s.

The beauty of the ADC0804 in free-running mode is in its simplistic elegance. The conversion rate of 8888 samples per second is comfortably above the Xilinx sampling

12

rate of 8000 samples per second. In free running mode, only 8 pins are connected to the Xilinx, freeing up pins that would have been used for clocking, chip select, etc, for use in other modules. In addition, free-running mode eliminates complicated synchronization and timing issues with the Xilinx that would have existed to run the chip at another sampling rate.

D/A Converter

The first output stage is the Texas Instruments TLC7524 8-bit D/A converter. As a compliment to the A/D converter, the D/A converter’s purpose is to take 8-bit digitized audio from the Xilinx and output an analog signal in the range of 0 to 5V. The input sampling rate dictates that the Xilinx should also set the output sampling rate to the D/A at 8000 samples per second. Like the ADC0804, the TLC 7524 is also designed with clock inputs to be tied to a microprocessor. Again, the configuration used in the audio subsystem sets the D/A in unipolar free-running mode. Figure 2.7 details the setup of the D/A converter in unipolar free-running mode.

Figure 2.7: Schematic for A/D Converter in Unipolar Free-Running Mode

The voltage supplied to the TLC7524 is 5V for VREF and VDD. To configure the TLC 7524 for free-running mode, CS* and WR* are both tied low. However, unlike the A/D, CS* is connected to an output pin of the Xilinx. Using this control bit, the D/A analog output can be turned on or off to prevent unwanted signals from being sent to the speaker when the device is not in playback mode.

The D/A converter outputs current, not voltage, so it is necessary to attach an opamp to server as a buffered current-to-voltage converter. The LF351 was chosen because of its high slew rate. The 351 is otherwise very similar to the 741 opamp. OUT1 (pin 1) from the D/A is tied to the negative terminal of the 351, while OUT2 is effectively ignored by connecting it to ground at the positive terminal of the 351. The TLC7524 includes an

13

internal feedback resistor (pin 16) that is connected inside the chip back to pin 1. The output of the 351 (pin 6) is connected to this RFB pin for gain control. Forcing OUT2 to ground sets the output in unipolar mode, meaning it will be on the range of 0 to -VREF (5V). The advantage of unipolar mode is that the magnitude of the output signal is already in the correct range for the output filter. However, the disadvantage is that the sign is negative. This problem will be addressed in the next output stage.

In free-running mode, the D/A acts transparently, converting the digital values on its inputs to analog output as fast as possible. This conversion typically takes about 100ns. This conversion time translates into 10,000,000 conversions per second, which is more than fast enough to handle the 8000 samples per second from the Xilinx. The D/A benefits from the same advantages as the A/D while operating in free-running mode: low pin usage (8 bits plus 1 for CS*) and elimination of timing considerations.

Inverter

The second output stage is a simple unity-gain inverter using a 741 opamp. Since the unipolar operation of the D/A outputs 0 to –5V, the opamp in this stage inverts the signal, returning it to its original 0 to 5V. Figure 2.8 details the setup of the 741 in unity gain inverting mode.

Figure 2.8: Unity Gain Inverter

Output Filter

The third output stage is another Linear Technologies 5th order low-pass filter. The output filter is configured exactly as the input filter, as Figure 2.9 shows. The corner frequency, clock divider, voltage inputs, and buffered outputs are all identical. However, the output filter serves an additional purpose.

14

Figure 2.9: Schematic of Output Filter

While the input filter exists primarily to remove aliasing frequencies, the output filter is also charged with the task of recreating a continuous waveform from output that is not continuous. While the D/A converter works at an extremely fast rate, its speed is not infinite, which results in an output waveform that is not continuous. The output from the D/A is similar to a step function in that it is in reality a series or horizontal samples strung together to recreate the waveform. As in digital logic, jumps from step to step create unwanted frequencies. The output filter thus serves two purposes:

Like the input filter, unwanted high frequencies are eliminated. The output filter also attempts to smooth the output of the D/A into a more

continuous waveform. This waveform is then passed to the next output stage – the speaker amplifier.

Output Amplifier/Speaker

The fourth and final output stage consists of the speaker amplifier and the speaker. The purpose of the speaker amplifier is simple; it provides enough gain in the signal to produce output on the speaker. The speaker itself is an ordinary 8Ohm speaker. An LF386 Audio Amplifier handles the amplification duties. Figure 2.10 shows how the 386 is connected to the speaker through a de-coupling capacitor.

Figure 2.10: Schematic of Speaker Amplifier and Speaker

15

A 10k potentiometer serves as volume control for the circuit, although at present the circuit doesn’t allow a very wide range of volume adjustment. The 386 operates on just one power supply (about 10V). From the 386, the signal is sent to the speaker and sound is produced.

Problems Encountered

Over the course of the semester, the area that created the most headaches was easily the audio subsystem. Initially, the schedule called for audio to be completed in just a couple of weeks. This goal was furthered by the fact that the A/D test circuit was working after the first day of working on the project. However, this would be the last time that any real progress was made in a single day until late into the semester (though it wasn’t from a lack of effort.) The problems encountered are too numerous to list in their entirety; the log file included in Appendix E can be consulted for a more complete listing of problems encountered. Eight of the major problems are discussed blow in paragraph format.

Originally, the D/A chip was the DAC0830, which was extremely easy to set up. However, this chip did not have a fast enough conversion time for the PDACS application. The next D/A chip tried was the DAC0800, which had a faster conversion time but proved to be very problematic. Numerous test circuits included in the data sheets for this chip were implemented, but to no avail. The chip would not produce correct output. After approximately four weeks of testing the DAC0800, a new D/A was found – the Texas Instruments TLC7524. The test circuit for this chip was very similar to the DAC0830. It took only twenty minutes to set up and the problem was solved.

Another problem encountered involved the Harris ADC0804, which had been working since our first day of project work. For some unknown and unapparent reason, the chip started overheating and stopped working. After one frustrating week, the problem turned out to be two pins (WR* and INTR*) which were originally grounded permanently, but actually needed to be connected through a normally open switch to ground. The switch should close when the circuit is powered up, then open immediately. Sometimes this pin can be permanently grounded, other times the switch can be implemented as in the test circuit, but the chip still fails occasionally. Essentially, when the chip begins to overheat, the normally open switch can be used as a way to reset the chip back to run normally again.

After both the A/D and D/A converters were operational and wired together successfully, a speaker was hooked up to the output of the D/A. While sound was produced, the signal was barely audible. The output from the A/D needed an amplification stage. After consulting a schematic for a Xilinx demo board that used audio and a booklet on opamp IC circuits, it was determined that an LF386 audio amplifier and a potientiometer would be used for gain/volume control.

Originally the audio circuit did not include input or output filters. Research into audio principles indicated that the presence of anti-aliasing filters was a necessity in mixed-signal applications. When these low-pass filters were included, the output was much

16

cleaner. This aspect could still be improved, though, as discussed later in the future improvements section.

A characteristic of the microphone that was overlooked was the range of output voltages produced. While the microphone output was being amplified, the amplification was so small and the circuit load so large that voltage levels never strayed far above 1VPP, effectively limiting the quality audio to just 1/5 of the possible values, or about 2 bits. Also, the microphone had to be held directly to the mouth to pick up any input, introducing a lot of noise from breathing into the microphone. After visiting with Dr. Jose Pineda De Gyvez, Associate Professor of Electrical Engineering, the gain on the input amplifier circuit was increased from about 3V/V to over 190V/V. This increased the voltage range to cover the entire 0 to 5V while the microphone was about a foot away.

Another characteristic of the microphone that was not considered is that its output contains both positive and negative voltages. Since the DC offset was set at 0V, and the A/D only translated values from 0 to 5V, the audio input system was only digitizing positive voltages from the microphone. This error produced a scratchy, noisy effect in the output. Dr. Costas N. Georgehidas, Jr. Professor of Electrical Engineering and Head of the Telecommunications and Signal Processing group, pointed out this error in the audio input system. Once the DC offset was set at 2V, the audio quality increased dramatically.

Although the data sheets for the low-pass filters indicated that buffers were necessary on the output of the filter to prevent affecting the corner frequency, these were not implemented since the outputs were tied to opamps. It was assumed that these would function as buffers. However, this did not prove to be a correct assumption. The output voltage from the filters was being cut off by a constant amount in the passband. Buffers (simple voltage followers) were introduced at each filter output, and this problem was corrected.

Although ELEN 325 prepared the group somewhat for the analog circuitry, it was not enough background information. The main reason the audio subsystem was behind schedule is because of the group’s general lack of knowledge about audio signal theory. Several problems were solved by enlisting the help of Electrical Engineering professors who could provide a better understanding of audio properties.

Testing

Once we finalized our Audio circuit, we needed to test it. We performed several tests, including: Using the function generator as input, we recorded sine waves and played them back

with PDACS. Recording speech with PDACS and playing back with PDACS. Recording speech with PDACS, uploading and playing back on the PC. Downloading .wav files to the memory chip and playing them with PDACS in

comparison to playback with the PC.

17

Recording the same speech with both PDACS and the PC and quantitatively comparing the results.

Each set of testing revealed a new set of problems, which is why this subsystem took longer and is much more complicated than we had planned. The help of several professors outside of the Computer Science Department was enlisted to solve some of our analog problems.

Initial testing involved using the function generator to input a sinusoidal wave to the circuit. By varying the frequency and amplitude, the tone and volume of the output at the speaker could be varied. The oscilloscope was also used to easily examine the input versus the output of the circuit. This type of testing allowed for isolation of noise sources to better eliminate them. The oscilloscope was also useful in testing the DC offset and gain of various stages in the circuit.

The next tests used human speech as input to PDACS. The first set of tests produced barely understandable output, but it was a start. These tests led to the conclusion that the gain of our input circuit should be increased, and we were on to playing the recorded speech on the PC. Once the audio was played back on the PC and the raw speech files were viewed, it was determined that the A/D was not producing output over the entire spectrum of possible values. The gain of the input was increased again to better cover the 256 possible voltage levels, and the audio quality improved greatly.

The last set of tests involved recording the same speech sample with both PDACS and the PC sound system. The PDACS Audio Information Application was then used to generate data showing the range of values in the raw files. The histograms produced from this data are shown below, in Figures 2.11 and 2.12.

18

Figure 2.11: Data from PC recording

Figure 2.12: Data from PDACS recording

This data confirms what would be expected: the audio quality of the PC is better than that of PDACS. While there is definitely room for improvement, PDACS results in a very reasonable reproduction of the audio sample. The PC does a much better job of filtering out spikes in the input. The PC sound system most likely uses in automatic gain

19

adjustment circuit on the microphone input, something that was too complicated for the scope of this project. Thus, the PDACS audio system performs well only at the specific microphone range for which the input gain is tuned. Despite not performing quite as well as the PC audio system, PDACS audio quality improved almost infinitely in the last two week of the semester. In addition to the samples shown above, three other sets of data were taken using different test subjects, but the results were the same as those above.

One noticeable difference in the two samples is that the PDACS sample has an average around 100, whereas the average value in the PC sample is closer to 128. This is due to the PDACS DC offset being set at 2 V, while the PC DC offset is set at 2.5 V. The PDACS offset was set lower after examining data from the microphone. For some unexplained reason, the microphone produced more positive voltage values than negative, and the positive values were larger in value than the negative values. Therefore we set our DC offset at 2 V to capture more positive values and thus have better overall use of the 256 possible voltage levels.

20

88886755544444432777777779923431155555788889

84617153463121789221311255718491

= 44 values

= 32 values

RLE

Compression – The Subsystem That Almost Was

Compression was initially intended to be one of the features of our application. Unfortunately this subsystem was limited by several factors, such as CLB count, Verilog limitations, and manpower (several members of the compression team were tied up with other subsystems). Due to these and many other reasons compression never made it to a working hardware implementation. Several variations of different algorithms were tested, some even coded in Verilog and simulated. This section will cover the different algorithms, their benefits, and how we could have integrated them into PDACS.

Run Length Encoding

This is one of the simplest compression algorithms, and possibly the riskiest. It operates by reading a value, determining the length of its “run” and storing the value as two numbers, the value, and then the length of its run. This is a very useful type of compression in cases where there are long runs of identical data, like images. This often translates into silence compression with sound files, since silence is usually the longest running stream of identical data in this type of file. RLE becomes dangerous if there are no long runs of data, in a worst case situation in which every data value is different from the one next to it RLE can more than double the file size. Our sound files were very susceptible to this swelling of files size when run length encoding was applied. It is better used after Discrete Cosine Transform is applied, creating a more repetitive set of data streams. (See Appendix A for the C code.)

Companding

Companding is a lossy compression algorithm with several benefits. First, it is very fast as both the compression and decompression take place via lookup table. Second, the compression ratio is known in advance since it does not vary based on the input data. Lastly, you can tune the algorithm to whatever compression ratio you desire, although quality degrades as the compression ratio increases. We experimented in Verilog with companding code, and were able to achieve a compression ratio of 8:6, which is not wonderful. But when combined with lossless algorithms, companding can be a good compression algorithm choice.

21

The algorithm works by using a formula to find the output value based on the input. The formula can vary based on what your data looks like. The telecommunication industry uses an exponential formula, while normal ADC equipment found in desktop computers uses a linear scheme. The algorithm we implemented used a linear scheme, but before doing this we examined our data to see where it was concentrated, and cut out any outliers. (See Appendix A for the Verilog code.)

Vector Encoding

This is a form of difference encoding. It is a lossless algorithm, and if you limit the amount of the difference allowed between data samples, it can be a very effective algorithm. We implemented vector encoding in Verilog and performed compression on data that had a maximum jump of 10 between samples. This data was first compressed using companding, so we were able to achieve a total compression ratio of 8:3 with the two algorithms in use together.

Instead of storing consecutive values, vector encoding works by storing the differences between consecutive values. In a data sample where the difference is limited (like natural speech) this becomes a very cost effective means of lossless compression. For example we can store consecutive values in 8-bit samples. If the difference between samples is limited to a difference of two (not unusual for speech with a high sampling rate) we only need two bits per sample for vector encoding; one bit for the amplitude and one for the sign. A file that was once 64K (8-bits per sample * 8000 samples) becomes about 16K (8 bits for the first sample plus 7999 * 2-bits for the differences). We would see a huge reduction in file size without any loss in quality. (See Appendix A for the Verilog code.)

DCT

When we first began to work on our project at the beginning of the semester, Dr. Mahapatra suggested that we look into using the Discrete Cosine Transform as the basis for our compression and decompression subsystem. Our investigation into DCT was based on these two equations:

DCT:

IDCT:

For:

22

After obtaining the DCT of a range of our samples, we would run those through some type of end length encoding. We did get an initial version of the DCT entered in Verilog. However, it was so large that it would no be able to fit on the 4k10 with all of the other components. For this reason we did not pursue refining the verilog DCT, entering the IDCT, or entering end length encoding in Verilog. The Verilog code that we did get started with for the DCT can be found in Appendix A.

Even though a hardware implementation never saw the light of day, we did do simulation of DCT in software. First we began with example code and modified it so that we would take our input from a file, in groups of eight bytes at a time. We perfom DCT, divide by the quantitization matrix(usually the elements index plus one) and then write the results out to a file. This output file contains a lot of zeroes and is then vunerable to run length encoding. See Appendix A for examples of the code. Since our data is taken in eight bit samples, and the results of DCT are integers (4 bytes) the file sizes grew instead of shrank, but when implemented in Verilog with custom data types, we would have much better performance.

23

Memory Subsystem

Once the audio data was read in and converted to digital values it had to be stored somewhere for later retrieval. This was the purpose of the memory subsystem, which could store a large amount of data for playback on the device at a later time, or for download on the PC. The memory subsystem consisted of sixteen mega-bits of non-volatile memory provided by the ATMEL AT45D161 serial data flash memory. This device is capable of holding up to two mega-bytes of data and was used for long term storage of the stored data.

Components

ATMEL AT45D161 Flash memory

Figure 4.1 - ATMEL AT45D161 Flash Memory

This chip was selected for a variety of reasons. First, since it stored sixteen mega-bits of information, we calculated that it could hold approximately four minutes of uncompressed speech. A production model would have even more memory to store up to an hour or more. For the purpose of this demo, the 2 mega-bytes are sufficient. Its low voltage requirement meant that we could power the memory form a 5V source, just like the majority of our other discrete components. The most important factor though was the serial nature of the chip. With a 16550 UART connected along with analog to digital and digital to analog systems, I/O pins on the Xilinx chip where at a premium. Because we use the PLCC-84 package of the FPGA, we only have about 55 I/O pins. A sizable amount of regular memory would have required many more pins than what we had available. While the use of serial memory allowed us to proceed, it was more complicated to interface with. The pin count from the Xilinx to the memory chip was reduced to six pins. The six pins on the ATMEL AT45D161 Flash memory required for connection to the Xilinx FPGA are listed below in Figure 4.2.

24

Signal Abbreviation

Signal Name Signal Description

SO Serial Output Data Output pin from the memory chipSCK Serial Clock Control signal from Xilinx to the memory chip

SI Serial Input Input pin to the memory chip (used for commands and data)

CS* Chip Select An active low signal that enables the memory to be read from or written to

RESET* Chip Reset An active low signal that will terminate the operation in progress and reset the internal state machine to an idle state

WP* Hardware Page Write Protect Pin

An active low signal that forbids the first 256 pages of main memory to be reprogrammed when asserted

Figure 4.2 - Memory Pins Used

Since the entire system revolves around the memory, the first major Verilog module written was the module that would control memory. Our first decision was what operations we desired this controller to perform. We concluded that the controller should only be in charge of instructing the memory when to read and write. We also concluded that it was necessary to reduce the complexity of the other three modules that would be interfacing with memory. To do this, we wanted to keep other module from having to keep track of the memory page and byte for the chip. If all of the other modules have to contain this information, we would be wasting a large amount of space on the chip. This is valid only due to the fact that our application is centered on streaming audio in and back out. This means that random access is not required.

The Write Operation

For the write operation, the Atmel AT45D161 provides two 528 byte internal buffers to accommodate real-time input streams of data. By utilizing these two buffers, we read in our serial input into the first buffer until it was full. Once we completely filled this first buffer, we manually transferred our serial input to the second buffer, or else the data at the beginning of buffer 1 would be overwritten. This was done as soon as buffer 1 was full, not on the next write cycle, for that lead to grave timing errors. At the same time that data was being streamed into buffer 2, the data in buffer 1 was being transferred to a page in memory, effectively allowing no break in the continuous input stream. When buffer two became full, we switched back to buffer one, and wrote the contents of buffer two to memory. This process continued until no more data is available on the serial input port. The only restraint on this is that we must not be able to fill a buffer faster than the 20ms it takes to program the other buffer to the main memory array. Operation of the two internal buffers can be seen in Figure 4.3 below.

25

Figure 4.3 - Internal Diagram of ATD45D041

The Read Operation

Similarly, next came the implementation of the read operation in Verilog. Although we employed the buffers for the write operation, it did not appear that they were necessary for the read operation, since we simply wanted to read a page at a time from memory. The memory does not require the same amount of time when reading main memory as when writing to it. It seemed we could just use the read byte from main memory command, and ignore the buffers completely. This fact lead to a Verilog implementation that could be integrated with the write operation easily.

The internal workings of the serial flash memory are very complex. In order to implement our Read and write functions, we used some of the internal operations provided by the chip. The three instructions that we used were:

Main Memory Page Read (opcode - 52H)- Allows the user to read data directly from one of the 4096 pages in main

memory, bypassing both the data buffers and leaving the contents of the buffer unchanged.

26

Opcode Page address Byte address Don’t Care [X](10 bits) (12 bits) (10 bits) (32 bits)

Buffer Write(opcode buffer 1 - 84H, opcode buffer 2 - 87H)- Allows data to be shifted from the SI pin into either buffer 1 or buffer 2. If the

end of the buffer is reached, it will begin overwriting data at the beginning of the buffer.

Buffer to Main Memory Page Program with Built-In Erase(opcode buffer 1 - 83H, opcode buffer 2 – 86H) - Allows data written into either buffer 1 or buffer 2 to be programmed into main

memory. It actually has an 8-bit opcode followed by 2 reserved bits. This command will first erase the selected page in main memory to all 1s and then program the data stored in the buffer to the specified page in main memory.

27

Opcode Don’t Care [X] Buffer address (10 bits) (12 bits) (10 bits)

Opcode Page address Don’t Care [X](10 bits) (12 bits) (10 bits)

In integrating the read and write operations, we implemented an event triggered while loop to minimize the CLB count. Before entering the loops, we first determined whether a read, a buffer write, or main memory program was desired, and set the matching opcode. The while loop clocked in the necessary number of bits based on the operation. Each individual bit was clocked in one at a time. The buffer write operation required 32 setup bits followed by the 8 data bits of the input byte. The buffer to main memory program requires just 32 control bits. The read operation requires 32 setup bits followed by 32 don’t care bits. After these don’t care bits are clocked in, data can be pulled off of the SO pin on bit at a time by pulsing the SCK pin. After the while loop exits, we update the control variables and test the edge conditions. The memory chip does not send any notification that the end of a page has been reached or that the end of memory has been reached. Therefore, our control module must check for all of these conditions each time through. If, after completing a buffer write, we see that we are at the end of a page, the control for the main memory page program command will be set. To guarantee that no samples are lost, the module must run fast enough that the worst case of a buffer write and a main memory page program command can be issued between 8kHz samples. The memory module can be seen in Appendix A – Memory Control Module.

In order to test the memory module, a simple Verilog module was used to read and the write specific known values to the memory. To do this, we implemented a counter from 00-FF (hex) in Verilog, and wrote this over and over again into memory. To see if our read and write operations were working correctly, we implemented another Verilog module to pull values out of memory, one byte at a time as specified by the user. We could then display each half of the byte on an 7 segment LED. If memory worked as it should, each page in memory should just contain a sequence of numbers repeated. The code to test the read and write from memory can also be viewed in Appendix A. Now the memory is prepared for integration with the different subsystems.

There are several problems one most be aware of when dealing with the ATMEL AT45D161 Serial Memory chip. These are a few of the more drastic problems we encountered that impeded our progress. It might be a good idea to be aware of these problems.

1. Initially we approached the problem by constructing a state machine that would react to the input signals and then clock the necessary output to the memory chip. This state machine became extremely large and complex. After viewing the Verilog programming guide on the Xilinx web site we found an edge triggered while loop that fit our purposes nicely.

28

always begin @(posedge clk)…while ( counter < end ) begin

@(posedge clk); { set your data }@(posedge clk); { clock the SCK pin up }@(posedge clk); { clock the SCK pin down and

increase the counter }end…

end

The ‘@(posedge clk);’ lines are called event triggered and will the module will wait until a posedge clk to execute the statement that follows it. Hence this while loop clocks in one value to the chip. The counter established the length of the string to be clocked into the chip.

2. The reason the memory module is so large is the need to keep track of so many values. The chip does not send any kind of signal when the end of a buffer has been reached, it just starts over writing at the beginning of the buffer. Hence we must keep track of the number of bytes as we write them in. This takes 10 bits for the data. When we do reach the end of the buffer, we must write it to a page in the main memory array and count how many memory pages we have gone through so that we know when we have reached the end of memory. This requires another 12 bits of storage.

3. The last major problem we ran into was determining the behavior of the SCK pin early on. The data sheet was not very specific when describing how this pin affected the timing of the device. If the SCK pin was necessary to drive internal operations such as a main memory page program, then we would need to run the module at an extremely high clock rate and make the algorithm somewhat more complex. We ran a few quick tests using the memory busy pin on the memory chip to determine if the internal operations were truly internally timed independent of the SCK pin. With this information, we were able to proceed with the above design as planned.

29

Serial Subsystem

Interface the Xilinx chip to the serial port requires two chips to allow communication to commence. The data and control lines coming from the serial port follow the RS-232 standard that is described in more detail below. This standard requires entirely different voltages than the TTL logic levels used by the Xilinx and other components. To convert the –3 to –25 volts and +3 to +25 volts of serial communication to the TTL 0 to 5 volts requires a chip such as the Maxim RS-232 Driver/Receiver. The MAX232 chip can also perform conversion from TTL voltage levels back to RS-232 voltage levels. Once these conversions are made the necessary lines can be passed on to the Universal Asynchronous Receiver/Transmitter (UART). The 16550 UART performs the serial-to-parallel conversion on data characters received from the PC and will conversely perform parallel-to-serial conversion on data characters received from the Xilinx FPGA destined for the PC. Through the UART, the Xilinx chip is able to read the complete status of transfer operations. Control lines as well as any error conditions are monitored and changed by accessing registers within the UART. A layout of the components is shown in Figure 5.1.

Figure 5.1 – Serial Overview

A more detailed visual is shown below in Figure 5.2 demonstrating the relationship between the UART, RS-232 converter, and the serial port jack.

30

Figure 5.2 – Detailed Serial Description

MAX232 Driver/Receiver

To convert signals using RS-232 voltage levels so TTL compatible devices like the XILINX FPGA and other components within the project can use them a level converter is needed. The MAX232 is a typical chip for this application because it performs conversions in both receive and transmit directions and has two lines for each direction. Other drivers often times only convert one way or only consist of one transmission line. Also, unlike many other line drivers, the MAX232 chip includes a charge pump that generates +10 and –10 volts from a single 5-volt power supply. Many others require 12 volts.

PC16550D UART with FIFOs

The Universal Asynchronous Receiver/Transmitter performs the “overhead” tasks necessary for asynchronous serial communication. The particular 16550 contains an internal FIFO which allows 16 bytes to be stored in both receive and transmit modes. All the logic is on the chip to minimize system overhead and maximize system efficiency. Probably the most important function of the UART is performing serial-to-parallel and parallel-to-serial conversion on data characters received from a peripheral device or from

31

the Xilinx FPGA. This allows for much less handling performed by the Xilinx on the data. The UART is also responsible for adding and deleting standard asynchronous communication bits such as the start bit, stop bit, and parity bit to and from the data. Again, this makes things much simpler from the software side because data can be sent directly into the UART and everything else is taken care of. To control the data the UART allows access to the control lines of serial communication. CTS, RTS, DSR, DTR, RI, and DCD are all connected to the UART and affect the registers within. A very useful function the chip provides on the software side is an interrupt pin that is fully programmable. It can be set to sound an interrupt for receiver error, received data available, timeout when in FIFO mode, transmitter holding register empty, and any change in the control lines. To obtain the correct baud rate, this UART includes a programmable baud generator that is capable of dividing the timing reference clock input by divisors of 1 to (216-1), and producing a 16 X clock for driving the internal transmitter logic. The divisor is calculated by taking the crystal frequency / 16 / baud rate. This takes away the need for an external baud generator needed in previous UARTs.

Much more detailed information about the different registers, setup, and control of the UART is available in easy to read format in the 16550 UART data sheets.

Connecting the Pieces

The MAX232 and the 16550 UART were connected as shown in datasheets and other application notes found on the Internet. Signals that needed to be connected to the Xilinx from the UART were data lines, address lines, write signal, read signal, receive ready signal, transmit ready signal, master reset, and the DSR from the serial port. Using these 17 lines full serial communication is implemented. The UART needs an external crystal to generate the correct baud rate. An 18.432MHz crystal is used and integer divisors are possible from 110bps up to 1.152Mbps. Also added to the schematic were LEDs to signal power, characters being transmitted, characters being received, and the DSR (DTR on computer). This last LED indicates a working connection with the PC. A full schematic is shown below in Figure 5.3.

32

Figure 5.3 – Full Connection Diagram

Control Module

The final serial control module interacts with memory and the PC to form a robust module. The entire module was written in a Verilog state machine to ensure proper delays between signal assertions. Initially the state machine was designed using the

33

graphical state machine editor but almost none of the state machines produced worked as expected. This led to the eventual switch to using straight Verilog. A state machine was developed that worked every once in a while, but it went off into nonexistent state quite often. In an environment where memory can be overwritten if something this bogus happens this could not be allowed. After much struggling and searching for working state machine code it seemed like nothing was going to work correctly. Finally, the idea was brought up by Scott Wadsworth to latch the inputs. This would mean there was no way for the conditional variables and basically any inputs could change while operations were being performed on them. These variables could only change at a positive edge of the clock resulting in an instantly stable machine. After this there was never a problem with going into nonexistent states or jumping around within the states.

For the final serial module there were 46 states. The main sections include initialization, receiving characters, sending memory to PC, end of memory, and writing data from PC to memory.

To begin doing anything in the state machine the DSR must be active. If at anytime the DSR goes inactive the essential variables are reset and nothing else can happen until the DSR is active again.

The initialization section consists of initial setup of variables after a reset to ensure we have control of the UART. The UART is reset to a state at which all registers are known. This master reset signal is held for a minimum of 5000ns to ensure a proper reset. The baud rate is set to 115.2kpbs by setting the least significant byte of the divisor latch to 10 and the most significant byte to zero. The line is then setup to operate at 8 data bits, no parity bit, and one stop bit by setting the line control register. The FIFOs within the UART are turned on and reset by writing to the FIFO control register.

The section that receives characters waits for a character to be received and reads it from the UART data lines. Based on this character determines what will happen next. If an “a” is received a variable is set indicating one “a” has been received. If another one is received then we move to the sending memory to PC section. If a “b” is received another variable is set indicating one “b” has been received. If another one is received then we move to the writing data form PC to memory section. If any other character is received then these variables are reset and we wait for the proper control characters.

The memory to PC section first checks to make sure it is not at the end of memory. If not then it checks to see if memory is busy. If memory is not busy then data is read from memory. The byte read is sent over to the PC. During this section a check for 32 consecutive 0xFF characters is made. If this sequence is encountered, then this is the end of the current sample.

The PC to memory section checks to see if there is a character to be received. If there is the data is read and the end of memory signal is checked. If we aren’t at the end of memory the data is written to memory. This process continues until 1) the end of memory is reached or 2) the PC makes the DSR inactive.

34

When the end of memory is reached the DTR is set active and held for at least 67ms by using a 15Hz clock. The module sets the DTR and waits for a high, low, then high before the DTR is set back inactive.

RS-232 Standard

Due to its relative simplicity and low hardware overhead serial communications is used extensively within the electronics industry. Today, the most popular serial communications standard in use is RS-232E. The official name of the RS-232 standard is “Interface Between Data Terminal Equipment and Data Circuit-Termination Equipment Employing Serial Binary Data Interchange”. Although the name may sound intimidating, the standard is simply concerned with serial data communications between a host system (Data Terminal Equipment, or “DTE”) and a peripheral system (Data Circuit-Terminating Equipment, or “DCE”).

RS-232 is a “complete” standard. It sets out to ensure compatibility between the host and peripheral systems by specifying common voltage and signal levels, common pin wiring configurations, and a minimal amount of control information between the host and peripheral systems.

When the standard was initially defined, it was before the days of TTL logic so the standard does not use 5 volt and ground logic levels. Instead, a high level for the driver output is defined as being +3 to +25 volts and a low level is –3 to –25 volts. For RS-232 communication, a low level (-3 to -25 volts) is defined as logic 1 and is historically referred to as “marking”. Likewise a high level (+3 to +25 volts) is defined as logic 0 and is referred to as “spacing”. The regions between –3 and +3 volts is undefined.

Signals are also defined by the RS-232 standard. This project only used four signals marked with asterisks but the most common eight are described below. A chart showing the signals along with abbreviations and descriptions is show in Figure 5.4.

35

Signal Abbreviation

Signal Name Signal Description

TD* Transmit Data This signal is generated by the DTE and received by the DCE (serial data output).

RD* Receive Data The signal is generated by the DCE and received by the DTE (serial data input).

RTS Request to Sent When the host system (DTE) is ready to transmit data to the peripheral system (DCE), RTS is turned ON. In duplex systems, this condition maintains the DCE in receive mode. The OFF condition maintains the DCE in transmit mode.

CTS Clear to Send Used along with RTS to provide handshaking between the DTW and the DCE.

DSR* Data Set Ready This signal is turned on by the DCE to indicate that it is connected to the telecommunications line.

DCD Data Carrier Detect

This signal is turned ON when the DCE is receiving a signal from a remote DCE that meets its suitable signal criteria.

DTR* Data Terminal Ready

Indicates the readiness of the DTW. This signal is turned ON by the DTE when it is ready to transmit or receive data from the DCE.

RI Ring Indicator When asserted, indicates that a ringing signal is being received on the communications channel.

Figure 5.4 – RS232 Signal Description

Serial ports come in two different “sizes”, a D-Type 25 pin connector and the D-Type 9 pin connector. The pin numbers for the necessary pins are shown below in Figure 5.5. This project used the D-Type 9 pin connector.

D-Type 25 Pin No. D-Type 9 Pin No. Abbreviation Full NamePin 2 Pin 3 TD Transmit DataPin 3 Pin 2 RD Receive DataPin 4 Pin 7 RTS Request to SendPin 5 Pin 8 CTS Clear to SendPin 6 Pin 6 DSR Data Set ReadyPin 8 Pin 1 DCD Data Carrier DetectPin 20 Pin 4 DTR Data Terminal ReadyPin 22 Pin 9 RI Ring IndicatorPin 7 Pin 5 SG Signal Ground

Figure 5.5 – RS232 Pin Description

36

An actual pinout of the D-Type 9 pin connector that we used is shown in Figure 5.6.

Figure 5.6 – 9-pin Connector Layout

To perform RS-232 communications properly the computer and the peripheral device need to be set to the same specification so that the information will make sense to either side. RS-232 typically involves sending a required start bit followed by either 6, 7 or 8 data bits, followed by an optional parity bit, and ending with a required stop bit(s). A more detailed explanation follows in Figure 5.7.

Start bit The start bit is required and is a signal to the receiving device that communication has begun. Before communication takes place theTransmission line is high. The start bit drives the transmission line low to signal a start.

Data bit The data bits contain the information that is to be transmitted. 6, 7 or 8 data bits can be chosen. When sending data for our application 8 bits will be used.

Parity bit Parity bits are optional and are only required if increased transmission reliability is needed, or if there is tendency for noise in the transmission lines. Parity can be set for even, odd, or none. In our application no parity bit will be used.

Stop bit Stop bits are a requirement and signal the receiving device that the frame is complete. The stop bits can be set for 1, 1.5 or 2 bits. Our application uses one stop bit.

Figure 5.7 – Serial Packet Structure

Along with these four parameters, the transmission rate needs to be coordinated. Our application uses a baud rate of 115.2kbps.

37

GUI Application

The GUI application allows a user to connect PDACS to his or her PC and transfer files between the PC and the device. A serial port interface on the device and a standard serial port on the PC provide connection between the GUI and PDACS. A null modem cable is used as the medium for the data transfer.

Visual Basic was chosen as the development language for the GUI. Factors that played into that decision were:Visual Basic allowed development of a Fully functioning windows application in short period of time, most of the time spent on development was with the functionality of the app, not in making it a GUI.Visual Basic included a Communications library that already contained many routines for working with the serial port. This included an interrupt driven function that allowed us to determine what occurred when the status of the many pins changed.

Weak spots in the Visual Basic Language included:

1. The fact that low-level access to the port was not allowed, we had to use the pre-defined Visual Basic libraries.

2. The maximum speed of the UART chips on the PC is 961 Kbps, the Visual Basic communication libraries limited us to 115.2 Kbps

3. The code is not portable.

Development of the GUI corresponded closely with development of the serial subsystem, as communication between the two would be vital for the success of their respective subsystems. Below is a communications diagram showing different states in communication between the MAX RS-232, the UART, and the GUI on the PC for downloading a file.

Later the ability to upload files to the device was added. The following diagram shows the states that exist during the upload of a file from the PC to the PDACS device.

Functionality of the GUI Download a file from the device Upload a file to the device Convert a compressed PDACS file to a .wav file. Play back a compressed file Play back a wave file

Functions in the GUI:

Form_Load : Called when the program is first started. Assigns variables for initialization and makes sure everything is correct.

38

Form_Unload : Called when the program is shut down, either by hitting the exit button from the menu bar or by clicking the closing ‘x’.

FileDownload_Click : Called when the user clicks on ‘Download a file’ from the menu bar. Initiates a download from the PDACS device by first getting a filename to download to, opening the port, setting the DTR active, and sending the characters ‘aa’ which starts the process on the Xilinx side. The rest of the download is handled by the different MSComm events of receive and DSR.

FileUpload_Click : Called when the user clicks on ‘Upload a file’ from the menu bar. This gets the filename that will be sent over to the PDACS device, opens the serial port, and sets up the PDACS device by setting the DTR active and sending the control sequence ‘bb’. The function then reads the first 16 bytes of the file and sends them out to the device. A timer is then started that will signal an event every 10ms so there will be some wait between each burst of 16 bytes.

Timer1_Timer : Used for the upload procedure and is called once every 10ms while the timer is active. This function handles sending out the entire chosen raw file and then sends 600 0xFF characters. These characters are used to signify the end of a sample and this large number is needed to ensure a page is written in memory containing these values. If at any time the end of file is gotten the function begins sending this ending character, still with the 10ms delays.

FileConvert_Click : Called when the user clicks on ‘Convert Raw to Wave’ from themenu bar. The filenames are initially gotten for the raw file and wave file

to be converted to and then the conversion is made. The actual conversion code is in RawToWav.

FilePlay_Click : When the user attempts to play a raw file, this is the function called. The filename of the raw file to be played is gotten through a dialog box and a temporary wave file is made. The raw file is then converted to this wave filename through the use of RawToWav.

SetPortset_Click : Called when the user wants to change setting of the serial port. This option is really not useful unless the serial port is wrong. The defaults are set at the beginning of the code and the only way to change these settings on the PDACS side is manually editing Verilog code.

helpAbout_Click : When the user clicks on the ‘About’ button this function is called.

exit_Click : Called when ‘Exit’ is clicked on the menu bar.

MSComm1_OnComm : Handles all events generated by the serial port. The events used heavily for PDACS are comEvReceive for downloading and comEvDSR for downloading as well. In the receive section the buffer is read that contains characters received by the PDACS device and are written to the log file. The

39

DSR event signals the end of a download. The files and port are shut down accordingly. If any errors occur with the serial communications then operations halt and a dialog box appears stating the error.

RawToWav : Called by other functions to perform the actual conversion between raw and wave files. The initial code forms the correct header for a wave file. Then

the entire raw file is copied over to the wave file.

PlayWav : Called by other functions to actually setup and play a way file. The multimedia controls are setup and the wave file is sent to the control to be

played.

ClosePort : Used by other function to close the serial port and update the status bar.

writefile : Used by download procedure and called from comEvReceive to actually write the bytes received from the serial port to the log file.

Command1_Click : Called when the user clicks on the button to close the multimedia playback controls. This function takes care of closing down the file, closing the controls, and deleting the temporary file if there is one.

FileWave_Click : Called when the user clicks on ‘Play Wave File’ from the menu bar. This function gets the name of the wave file to be played and sends it to the PlayWav function.

Sister applications

The main PDACS application was not the only one developed. During the time spent making the device several sister applications were developed, they include the serial testing application, and the PDACS audio file information application. Their functionality is as follows:

Serial Testing Application

The test serial application was written in Visual Basic and was used when testing serial communication with the Xilinx serial module. This proved to be an extremely useful tool because it allows sending of character by just typing them in the transmit window, receiving of characters in the receive window, changing of the DTR by a clickable check box, and status of the DSR in a status bar. This application could easily be used for testing of any serial communications.

PDACS Audio Information Application This application takes one of our .RAW files and returns the following information on it:Low Value High Value

40

Average Value

It will also generate a text file in the following formatValue, # of occurrencesThis file can be used to generate histograms for analysis of the files content. This is extremely useful for determining cutoff values for compression.

41

System Integration

Now that the individual subsystems are all complete, now comes the time to integrate them all together. But before that can be done, it must first be decided which subsystem gets which pins on the Xilinx chip. To facilitate integration, Figure 7.1 shows all of the Xilinx pins and the subsystems to which they are assigned. These are not the only possible pin assignments, but we found them to be the most convenient.

75TDO

77STXRDY*

79SRXRDY*

81A/DD0

83A/DD2

1GND

3A/DD4

5A/DD6

7D/AD0

9D/AD2

11VCC

74VCC

76GND

78D/ACS

80SRD*

82A/DD1

84A/DD3

2VCC

4A/DD5

6A/DD7

8D/AD1

10D/AD3

13CLK

12GND

72SD0

73CCLK

15TDI

14D/AD4

70SWR*

71DIN

BOTTOM VIEW 17TMS

16TCK

68SMR

69SD1

4 0 1 0 K 19D/AD6

18D/AD5

66SA0

67SD2

X I L I N X 21GND

20D/AD7

64GND

65SD3

23BTN1

22VCC

62SA1

63VCC

25SW1

24BTN2

60SA2

61SD4

27SW3

26SW2

58SDSR

59SD5

29SW5

28SW4

56INIT

57SD6

31GND

30RD,M1

54VCC

55PROG

52GND

50MWP*

48MCS*

46MSCK

44LEDdec

42VCC

40LEDUL

38LEDL

36LEDUR

34M2

32RT,M0

53DONE

51SD7

49MRST*

47MSI

45MSO

43GND

41LEDMID

39LEDLL

37LEDLR

35LEDT

33VCC

Figure 7.1 – Xilinx XC4010E Pin Assignments

42

Memory: Serial: LED:Signal Pin Signal Pin Signal Pin Signal Pin Signal Pin

SO 45 D7 51 DSR 58 A0 66 Top 35SCK 46 D6 57 MR 68 A1 62 Up Right 36SI 47 D5 59 WR* 70 A2 60 Low Rt. 37CS* 48 D4 61 TXRDY* 77 Bottom 38RESET* 49 D3 65 RXRDY* 79 Low Left 39WP* 50 D2 67 RD* 80 Up Left 40

D1 69 Middle 41D0 72 Decimal 44

A/D: D/A: Switches Buttons:Signal Pin Signal Pin Signal Pin Signal Pin

D0 81 D0 7 Switch 1 25 Button1 23D1 82 D1 8 Switch 2 26 Button 2 24D2 83 D2 9 Switch 3 27D3 84 D3 10 Switch 4 28D4 3 D4 14 Switch 5 29D5 4 D5 18D6 5 D6 19D7 6 D7 20

In order to combine the four major modules of our system, several controls were needed. The four major modules are the:

Memory module Serial module A/D sampling module D/A output module

The last three all must access memory, and be prevented from doing it at the same time.

Another function of the control modules is that of providing a user interface for our product. When the user depresses the play button, the system should start playing whatever is in memory. Likewise, if the play button is pressed again while playing, it should stop the playing. The same goes for the record button, one press starts recording and a second stops recording.

The master control module (see Main Control Module in Appendix A) manages the reset lines to all of the other modules. It does have a reset state of it's own which is controlled by a switch. When the system is activated (by flipping the switch), the control module goes straight to the default state. In the default state, only the serial module is out of its reset state. This is done to allow the PC to retrieve or upload data to PDACS at any time, as long as neither a play nor a record is in progress.

Out of the default state, three things can happen. One is to start recording. This is accomplished when the user presses the record button once. The control module will

43

then put the serial module in a reset state, take the memory out of its reset state, and take the A/D sampling module out of its reset state. This will start a recording at the beginning of memory. If the record button is pressed again before the end of memory is reached, a signal is sent to the A/D sampling module that tells it to stop sampling from the audio subsystem and put the stop characters in memory. These stop characters will tell other modules where to stop when they are streaming through memory. This is necessary since no record is kept of the stopping point. After recording has stopped (from either end of memory or user intervention), the master control module returns to the default state mentioned above.

A second action out of the default state is playing the contents of memory. When the play button is pressed while the control module is in the default state, several things happen. First, the serial module is put in its reset state. Second, the memory reset is sent low to allow memory reads. Last the D/A output module is taken out of its reset to start reading from memory. It will continue to read from memory and output the samples at 8 kHz until it either reaches the end of memory, the stop sequence, or the user intervenes. The user can stop the playback by pressing the play button a second time. An end of memory signal from the memory module indicates that the entire contents have been streamed out. If the D/A output module encounters the 'FF's stop sequence, it will assert the master control module done signal which will cause a return to the default state where the D/A and memory module are reset.

The final path out of the default state is a serial transfer of some type. The serial module is not reset in the default state. Therefore, the user can request to download or upload a file at any time that the audio is not playing or recording. Once the serial module receives a valid command from the computer, it will assert a serial start signal in the master control module. This will cause the control module to leave the default state and move to the serial transfer mode state where the memory module will be taken out of its reset state. While a serial transfer is taking place, neither a play nor a record action can be started. When the serial module reaches the end of the transfer, it asserts the serial stop signal in the control module, which causes a return to the default state after going through the stop state.

The second major control module is the access control module. The access control module controls access to the memory signals. Its inputs are the read line, write line, and data bus from both the audio and serial systems. The outputs are a read line, write line, and data bus to the memory module. It keys off of a serial active line, which comes from the master control module. If this line is high, the serial read line, write line, and data bus are passed through to the outputs to the memory module. On the other hand, if it is low, the audio read line, write line, and data bus are passed through. Any change in either read lines, either write lines, or the serial transfer line will cause the outputs to be updated again. The memory output bus does not go through the access control module because it is not an input and it does not matter if multiple modules have its data.

A high level review of this sort of integration can be very helpful. With this in mind, Figure 7.2 shows a high level chart of subsystem integration. The areas that have been

44

grayed out represent subsystems that are not fully operational, namely the compression subsystem. But this diagram does give a high-level view of what is going in PDACS.

45

Conclusion

Since its inception over 13 weeks ago, PDACS has made incredible progress, thanks mainly in part to the tireless dedication of Group 5. We laid out a set f goals we wished to accomplish o long ago, and we have come very close. Although we have come very close to realizing this dream, there are certain aspects of this project that unfortunately must be sacrificed. Here is a list of features we initially desired to implement, but later abandoned.

1. The device is no longer portable. Although we planned for it to be so initially, our op amps require positive and negative 9 volts, while all of our other components require positive or negative 5 volts. Since the op amps are integral to the circuit, we scrapped the power subsystem and decided to obtain the necessary voltage from the stationary power supply.

2. The compression subsystem never realized complete implementation. Although we discovered and implemented several clever algorithms in Verilog, they all took up too many CLBs, and eventually had to be removed altogether. We implemented a DCT algorithm and a Companding algorithm in Verilog, but compression in hardware was not to be. This was a featured part of project, but practical considerations forced us to scrap it. But we still did a great deal of research on the topic, and actually had two working implementations in Verilog, although they were not included in our final product.

3. We had initially hoped that we would achieve a very respectable compression ratio, anywhere from 6:1 to 4:1. But due to CLB constraints, we were forced to abandon our preferred compression algorithm, The Discrete Cosine Transform, and implement a strange meld of the Companding algorithm and the Vector Encoding algorithm. Unfortunately, our algorithm only yields approximately a 2:1 compression ratio, but requires a minimal number of CLBs.

4. We were also forced to give up the idea of a completely integrated finished product. We had hoped to be able to present a black box at the final hardware demonstration, but due to some unforeseen setbacks, we were unable to package our product up into a user-friendly bundle. The software interface is packaged rather nicely, but we were unable to do the same for the massive amounts of hardware that we used. So we do have a working demonstration, but we do not have a final product ready for commercial distribution.

And even though these features were not implemented, there are several others we would have liked to implement if we had another semester to tweak this project. Maybe these ideas will help someone expand this project in the future, or maybe it is just wishful thinking. Whichever the case may be, here are a few options we would have greatly enjoyed implementing had time allowed.

1. First and foremost, we would have liked to implement dual Xilinx XC4010E FPGAs so that we may implement DCT compression in hardware. Since this DCT algorithm took up approximately 300 CLBs by itself, the only way to accomplish compression in hardware is by adding another Xilinx chip. The lab staff scoffed at

46

this idea, so compression was neglected. But the major modification we would make to this project would be to add a second Xilinx FPGA in order to add compression in hardware.

2. While the audio circuit was troublesome for the majority of the semester, we would have enjoyed tinkering with this circuit even more to improve audio quality. The major modification we would make would be to change the two 5th Order Low Pass Filters into Band-Pass Filters, that passes only a specific range of frequencies, from about 80 Hz to 3 kHz. This would greatly improve our audio quality in theory as we were picking up noise from the 60 Hz power supply. But both time and monetary constraints kept us from installing these band-pass filters, even though they would be ideal for an application such as this.

3. We also wished we could experimented a bit more with the D/A circuit, from the Xilinx chip to the speaker. Since download to the PC was our primary function, we neglected the on-device playback until the waning days of the semester. Ideally, we would have liked another week or so to fine tune the D/A circuit for improved audio playback, such as amplifying our output, or implementing a reliable volume control.

4. If we had more time and more materials at our disposal, we might have tried to upgrade our 8-bit mono sound quality to 16-bit stereo quality. While we initially believed that 8-bit telephone quality would be sufficient, we rapidly discovered that our audio understandability was mediocre at best. The PC with which we experimented used 16-bit audio, and it was a significant improvement. Maybe in a later semester, someone could upgrade our audio quality to 16 bits.

So while we did not accomplish all that we specified in our initial proposal, what we did accomplish exceeded anything we could have imagined in our wildest dreams. We built, from the ground up, a device that could input analog audio from a microphone, convert it to digital data, store it in memory, and either download it to a PC or play it back on the device. By breaking this complex task into simpler subsystems and then integrating them at the end of the semester, we were able to give PDACS life. With a vision, a little teamwork, and a whole lot of dedication, Group 5 was able to conquer seemingly insurmountable odds. And for all these hours of work, we are now able to proudly demonstrate the fruits of our labors, a Portable Digital Audio CODEC System. We sincerely hope you have as much fun using this device as we did designing it.

47

Appendix A – Source Code

Audio Input Sampling Module//// ad2t samples from the 8-bit A/D at 8kHz and write // the samples to memory. When the system control module// signals to stop sampling, ad2t puts 'FF's in memory so// that other modules will know where to stop. If the end // of memory was reached then the 'FF's are not needed.//module ad2t( Reset, clk, DataIn, DataOut, MemEnd, Done, EndFill, Write );//// End of Memory indicator and End charactersinput clk, Reset, MemEnd, EndFill;//// Input bus from A/Dinput [7:0] DataIn;//// Write signal out to the access control module // which then sends it on to memory if allowed.// The Done signal is output after the module// has finished with the 'FF' indicators (if // they were necessary).//output Write, Done;//// Data ouput bus to the Access control moduleoutput [7:0] DataOut;//// registered variablesreg Write, Done;reg [1:0] Control;reg [7:0] DataIn, DataOut;reg [10:0] counter;//// stopPoint is the number of 'FF's that must be written in to verify a page write.//parameter stopPoint = 'd600;// always @( posedge clk ) begin // Reset condition block that resets all variables to initial conditons if ( Reset ) begin Write = 0; Control = 'b00; DataOut[7:0] = 'd0; Done = 0; counter = 0; // If we have the necessary number of 'FF's written, then we are Done end else if ( counter >= stopPoint ) begin Done = 1; // Else we want to test that the end of memory had not been reached and // we are still under the stop point. end else if ( ( MemEnd == 0 ) && ( counter < stopPoint ) ) begin case ( Control ) 'b00: begin // This first state sets the ouput bus to either // the input or the 'FF's if ( EndFill ) begin DataOut[7:0] = 'hFF; counter = counter + 1; end else begin DataOut[7:0] = DataIn[7:0]; counter = 0; end

48

Control = 'b01; end 'b01: begin // Now we want to start a write cycle Write = 1; Control = 'b10; end 'b10: begin // stop the write cycle pulse and start over at the top Write = 0; Control = 'b00; end endcase end end//endmodule

49

Memory Access Control Module//// Access Control determines which module has access to the // memory module. It takes Serial and Audio signals for the// Read, Write, and DataBus signals. The SerialActive signal// indicates whether or not a serial operation is in progress.// If one is, then those inputs will be redirected to the ouputs.// If there is no serial operation in progress, then Audio inputs// will be redirected to the output which then go on to memory.//module acc_con( SerialDataIn, // data input bus from the serial module SerialWrite, // write signal from the serial module SerialRead, // read signal from the serial module SerialActive, // indicates a serial operation AudioDataIn, // data input bus from the audio in module AudioWrite, // write signal from the audio in module AudioRead, // read input from the audio out module DataOut, // Output bus to memory Write, // Output write signal to memory Read // Output read signal to memory );//input [7:0] SerialDataIn, AudioDataIn;input SerialWrite, SerialRead, SerialActive;input AudioWrite, AudioRead;output [7:0] DataOut;output Write, Read;//// registered variablesreg [7:0] DataOut;reg Write, Read;//// The first always block re-assigns the write and data bus signals// based on a change in one of the write signals or the serial signal always @( SerialWrite or AudioWrite or SerialActive ) begin if ( SerialActive ) begin Write = SerialWrite; DataOut = SerialDataIn; end else begin Write = AudioWrite; DataOut = AudioDataIn; end end//// The second always block re-assigns the read line based on // a change in one of the read signals or the serial signal always @( SerialRead or AudioRead or SerialActive ) begin if ( SerialActive ) Read = SerialRead; else Read = AudioRead; end //endmodule

50

Audio Output Module//// da2t initiates a read from memory whenever it is not in// reset state or the end of memory. //module da2t( clk, Reset, DataIn, DataOut, // Input and output data buses Done, Read, // Done indicates that the 'FF's have been found // Read goes to Access control to start a read cycle Busy, MemEnd // Busy is an input from the memory which prevents // us from starting a read cycle before the first // has finished. Memend also comes from memory and // indicates that the end of memory has been streamed // through. );//input clk, Reset, Busy, MemEnd;input [7:0] DataIn;output Read, Done;output [7:0] DataOut;//// registered variablesreg Read, Done;reg [10:0] counter;reg [1:0] Control;reg [7:0] DataIn, DataOut;//// stop point for 'FF's in the stream parameter stopPoint = 'd32;// always @( posedge clk ) begin // Reset block that resets all variables to initial states if ( Reset ) begin Read = 0; Control = 0; DataOut = 'd0; counter = 0; Done = 0; end else if ( counter >= stopPoint ) begin Done = 1; end else if ( MemEnd == 0 ) begin case ( Control ) 'b00: begin // This first state clocks the read that // connects to access control. Read = 1; Control = 'b01; end 'b01: begin // Deasserts the read signal to access control Read = 0; Control = 'b10; end 'b10: begin // When the busy line goes low, the transfer // has been completed and the data is now // available if ( Busy == 0 ) begin if ( DataIn == 'hFF ) counter = counter + 1; else begin DataOut = DataIn; counter = 0; end Control = 'b00; end else Control = 'b10; end endcase end end//endmodule

51

Debouncer Module

module deb1M( button, clk, outclk );//// module to keep the button from being 'on' for too long//// connect the button input to the output of the // normal debouncer//// connect clk to the system clock that is faster// than the 15Hz used to debounce the button//// outclk will then only pulse for one cycle of // the clk input. after that the output will be low// input button, clk;output outclk;//reg button, clk;reg outclk;reg counter;//always @( posedge clk ) begin if ( button ) begin if ( counter == 0 ) begin outclk = 1; counter = 1; end else outclk = 0; end else begin outclk = 0; counter = 0; endend

endmodule

52

HEX-to-seven-segment decodermodule hex2led( HEX, LED );input [3:0] HEX;output [6:0] LED;reg [6:0] LED;//// segment encoding// 0// --- // 5 | | 1// --- <- 6// 4 | | 2// ---// 3

always @(HEX) begin case (HEX) 4'b0001 : LED = 7'b1111001; //1 4'b0010 : LED = 7'b0100100; //2 4'b0011 : LED = 7'b0110000; //3 4'b0100 : LED = 7'b0011001; //4 4'b0101 : LED = 7'b0010010; //5 4'b0110 : LED = 7'b0000010; //6 4'b0111 : LED = 7'b1111000; //7 4'b1000 : LED = 7'b0000000; //8 4'b1001 : LED = 7'b0010000; //9 4'b1010 : LED = 7'b0001000; //A 4'b1011 : LED = 7'b0000011; //b 4'b1100 : LED = 7'b1000110; //C 4'b1101 : LED = 7'b0100001; //d 4'b1110 : LED = 7'b0000110; //E 4'b1111 : LED = 7'b0001110; //F default : LED = 7'b1000000; //0 endcaseendendmodule

53

Bar Graph Module// the barled module runs the bar graph on the // protoboard. The bars go up and down with the// amplitude of the speaker's voice.//module barled( InLines, LinesOut );

input [3:0] InLines;output [2:0] LinesOut;reg [2:0] LinesOut;

always @(InLines) begin if ( InLines[3] ) LinesOut[2:0] = InLines[2:0]; else begin if ( InLines[2:0] == 'b111 ) LinesOut[2:0] = 'b000; else LinesOut[2:0] = (~InLines[2:0])-'d1; endend

endmodule

54

Main Control Module// Main.v is our master control module. It controls all of the reset // lines to the different modules. No two modules can access memory// at the same time because of Main.v...// // The module sets these reset lines according to the users action// on the play and record buttons. The serial module is defaulted to// 'not reset' so that the user on the computer can initiate a transfer// at any time. //// When the play button is pressed, the serial module goes into reset state // along with the A/D input module. The memory module and the D/A output// module are un-reset. The playing line is also asserted so that no other// operations can start.//// When the record button is pressed, the serial module goes into reset state// along with the D/A output module. The memory module and the A/D output// module are un-reset. The recording line is also asserted so that no other// operations can start.//// When a serial transfer is initiated, the serial transfer line goes high// and the memory module is taken out of reset state. Nothing else can be// started while a serial transfer is going.////module Control( Reset, clk, PlayButton, // line that receives pulse from play button RecordButton, // line that receives pulse from record button SerialStart, // line from the serial module that indicates // the start of a serial operation SerialStop, // line from the serial module that indicates // the stop of a serial operation MemoryReset, // reset line to the memory module MemoryChipReset, // line to the memory chip for hard reset SerialReset, // serial module reset line AComp_In_Reset, // audio input module reset line AComp_Out_Reset, // audio output module reset line EndFill, // tells the audio input module to // fill with 'FF's to indicate the // stopping point. SerialTrans, // line that indicates a serial operation is in // progress Done // input from various modules that tells when // things need to stop );// input Reset, clk, PlayButton, RecordButton, Done;input SerialStart, SerialStop;output MemoryReset, MemoryChipReset, SerialReset;output AComp_In_Reset, AComp_Out_Reset, EndFill;output SerialTrans;//// registered variablesreg MemoryReset, MemoryChipReset, SerialReset, AComp_In_Reset, AComp_Out_Reset, EndFill;reg Playing, Recording, SerialTrans;reg [3:0] State, NextState;//// state labelsparameter Play1 = 'b0000;parameter Play2 = 'b0001;parameter WaitP = 'b0010;parameter Stop = 'b0011;parameter Record1 = 'b0100;parameter Record2 = 'b0101;parameter WaitR = 'b0110;parameter Nothing = 'b0111;parameter Serial1 = 'b1000;parameter WaitS = 'b1001;parameter PreStop = 'b1010;//

55

always @(negedge clk) begin // reset block for resetting signals to default values if ( Reset ) begin MemoryReset = 1; MemoryChipReset = 0; SerialReset = 1; AComp_In_Reset = 1; AComp_Out_Reset = 1; Playing = 0; Recording = 0; SerialTrans = 0; EndFill = 0; NextState = Nothing; end else begin case ( State ) Play1: begin // start the playing state Playing = 1; Recording = 0; SerialTrans = 0; MemoryReset = 0; MemoryChipReset = 1; SerialReset = 1; AComp_In_Reset = 1; AComp_Out_Reset = 1; EndFill = 0; NextState = Play2; end Play2: begin // continue playing Playing = 1; Recording = 0; SerialTrans = 0; MemoryReset = 0; MemoryChipReset = 1; SerialReset = 1; AComp_In_Reset = 1; AComp_Out_Reset = 0; EndFill = 0; NextState = WaitP; end WaitP: begin // wait for the playing to stop Playing = 1; Recording = 0; SerialTrans = 0; MemoryReset = 0; MemoryChipReset = 1; SerialReset = 1; AComp_In_Reset = 1; AComp_Out_Reset = 0; EndFill = 0; if ( Done ) NextState = Stop; else NextState = WaitP; end Stop: begin // generic stop state that kills everything Playing = 0; Recording = 0; SerialTrans = 0; MemoryReset = 1; MemoryChipReset = 1; SerialReset = 1; AComp_In_Reset = 1; AComp_Out_Reset = 1; EndFill = 0; NextState = Nothing; end Record1: begin // start the recording Playing = 0; Recording = 1; SerialTrans = 0; MemoryReset = 0;

56

MemoryChipReset = 1; SerialReset = 1; AComp_In_Reset = 1; AComp_Out_Reset = 1; EndFill = 0; NextState = Record2; end Record2: begin // continue with recording Playing = 0; Recording = 1; SerialTrans = 0; MemoryReset = 0; MemoryChipReset = 1; SerialReset = 1; AComp_In_Reset = 0; AComp_Out_Reset = 1; EndFill = 0; NextState = WaitR; end WaitR: begin // wait for recording to stop Playing = 0; Recording = 1; SerialTrans = 0; MemoryReset = 0; MemoryChipReset = 1; SerialReset = 1; AComp_In_Reset = 0; AComp_Out_Reset = 1; EndFill = 0; if ( Done ) NextState = Stop; else NextState = WaitR; end PreStop: begin // when recording is ended before // end of memory, we must place the // 'FF's at the end to signify a finish. Playing = 0; Recording = 1; SerialTrans = 0; MemoryReset = 0; MemoryChipReset = 1; SerialReset = 1; AComp_In_Reset = 0; AComp_Out_Reset = 1; EndFill = 1; if ( Done ) NextState = Stop; else NextState = PreStop; end Nothing: begin // default nothing state that allows // for a serial transfer to start Playing = 0; Recording = 0; SerialTrans = 0; MemoryReset = 1; MemoryChipReset = 1; SerialReset = 0; AComp_In_Reset = 1; AComp_Out_Reset = 1; EndFill = 0; NextState = Nothing; end Serial1: begin // a serial transfer has been started Playing = 0; Recording = 0; SerialTrans = 1; MemoryReset = 0; MemoryChipReset = 1; SerialReset = 0;

57

AComp_In_Reset = 1; AComp_Out_Reset = 1; EndFill = 0; NextState = WaitS; end WaitS: begin // wait for a serial transfer to complete Playing = 0; Recording = 0; SerialTrans = 1; MemoryReset = 0; MemoryChipReset = 1; SerialReset = 0; AComp_In_Reset = 1; AComp_Out_Reset = 1; EndFill = 0; if ( SerialStop ) NextState = Stop; else NextState = WaitS; end endcase end end// always @( posedge clk ) begin // if nothing else is happening and the play button is pressed, start playing if ( PlayButton && !Playing && !Recording && !SerialTrans ) begin State = Play1; // if nothing else is happening and the record button is pressed, start recording end else if ( RecordButton && !Playing && !Recording && !SerialTrans ) begin State = Record1; // if we are playing and the play button is pressed, stop playing end else if ( PlayButton && Playing && !Recording && !SerialTrans ) begin State = Stop; // if we are recording and the record button is pressed, stop recording end else if ( RecordButton && !Playing && Recording && !SerialTrans ) begin State = PreStop; // if serialstart goes high, and we are in the 'nothing' state, start a transfer end else if ( SerialStart && !SerialReset ) begin State = Serial1; end else State = NextState; end// endmodule

58

Memory Control Modulemodule memory( Write, Read, Reset, clk, DataIn, DataOut, Busy, MemEnd, SCK, SI, SO, CS, MemoryPage );//// External interfaces//// Write write enable signal// Read read enable signal// Reset reset counter variables to zero// clk external clk for verilog module// DataIn 8-bit data input bus// DataOut 8-bit data output bus// SCK serial data clock// SI serial input line to chip// SO serial output line from chip// CS active low chip select to memory chip//input Write, Read, Reset, clk;input [7:0] DataIn;output [7:0] DataOut;output SCK, SI, MemEnd, Busy;input SO;output CS;output [11:0] MemoryPage;

reg [7:0] DataOut;reg MemEnd, Busy, SCK, SI, CS;//// Internal interfaces//// Byte value for byte number out of 528// counter loop counter// End tells the while loop when to stop// different for Buffer write, Main // Memory write, and Main Memory read// MemoryPage Memory chip page value// Buffer memory buffer value (0 or 1)// MMwrite Main Memory write// Bwrite Buffer write// MMread Main Memory read// Opcode Opcode for command to input to memory module//reg [9:0] Byte;reg [6:0] counter;reg [7:0] End;reg [11:0] MemoryPage;reg Buffer, MMwrite, Bwrite, MMread, Wait;reg [7:0] Opcode;//parameter maxByte = 'd527;parameter maxPage = 'd4095;parameter writeStr = 'd34;parameter MwriteStr = 'd42;parameter readStr = 'd1;parameter bwOpcode0 = 8'b10000100;parameter bwOpcode1 = 8'b10000111;parameter mwOpcode0 = 8'b10000011;parameter mwOpcode1 = 8'b10000110;parameter mrOpcode = 8'b01010010;// always begin @(posedge clk) // reset the module pointers if ( Reset ) begin Byte = 'd0;

59

MemoryPage = 0; Buffer = 0; MMwrite = 0; Bwrite = 0; MMread = 0; Busy = 0; MemEnd = 0; CS = 1; DataOut = 'd0; end else if ( Wait ) begin Wait = 0; end else begin // prevent activity End = 74; if ( MMwrite ) begin // check if Main Memory write is needed // and set the Opcode for that operation // and Buffer... if ( Buffer ) Opcode[7:0] = mwOpcode1; else Opcode[7:0] = mwOpcode0; End = MwriteStr; Busy = 1; CS = 0; end else if ( Write ) begin // else check to see if a buffer write is // necessary and set the Opcode for transfer // into memory... if ( Buffer ) Opcode[7:0] = bwOpcode1; else Opcode[7:0] = bwOpcode0; End = writeStr; Bwrite = 1; Busy = 1; CS = 0; end else if ( Read ) begin // else check to see if a main memory read // is starting and set the Opcode Opcode[7:0] = mrOpcode; End = readStr; MMread = 1; Busy = 1; CS = 0; end SCK = 0; counter = 73; while( counter >= End ) begin // while loop to feed in the data to the memory // and pull data out if necessary // // the @(posedge clk); statements are from the // Xilinx webpage and are used to get a // Foundation supported while loop. @(posedge clk); begin if ( ( counter >= 66 ) && ( counter <= 73 ) ) SI = Opcode[ counter - 66 ]; else if ( ( counter >= 64 ) && ( counter <= 65 ) ) SI = 0; else if ( ( counter >= 52 ) && ( counter <= 63 ) ) SI = MemoryPage[ counter - 52 ]; else if ( ( counter >= 42 ) && ( counter <= 51 ) ) SI = Byte[ counter - 42 ]; else if ( ( counter >= 34 ) && ( counter <= 41 ) ) SI = DataIn[ counter - 34 ]; else if ( ( counter >= 10 ) && ( counter <= 33 ) ) SI = 0; else if ( counter == 9 ) SI = 0; else if ( ( counter >= 1 ) && ( counter <= 8 ) )

60

DataOut[ counter - 1 ] = SO; end // now we have to clock the data on the SI or SO pins @(posedge clk); SCK = 1; // deassert the clock for another iteration @(posedge clk); begin SCK = 0; counter = counter - 1; end end if ( MMwrite == 1 ) begin // if a Main Memory write is completed, then // the buffer, byte, and page values must be // updated Buffer = ~Buffer; Byte = 0; if ( MemoryPage < maxPage ) MemoryPage = MemoryPage + 'd1; else MemEnd = 1; MMwrite = 0; Busy = 0; CS = 1; Wait = 1; end else if ( Bwrite == 1 ) begin // if a Buffer write is completed, then the // byte value should be incremented... unless // we have filled a page, in that case we need // to start a Main Memory write if( Byte == maxByte ) begin MMwrite = 1; end else begin Byte = Byte + 1; Busy = 0; end Bwrite = 0; CS = 1; Wait = 1; end else if ( MMread == 1 ) begin // if a read of 8-bits has been completed, then // we need to set the page and byte values to // match if( Byte == maxByte ) begin if ( MemoryPage < maxPage ) MemoryPage = MemoryPage + 'd1; else MemEnd = 1; Byte = 0; end else Byte = Byte + 1; MMread = 0; Busy = 0; CS = 1; Wait = 1; end end endendmodule

61

Serial Module// Interacts with memory and provides checking for a connection to the// PC through the DSR, (DTR on the computer), and then waits for // a character to be received. If two consecutive "a"'s are received // then the module starts attempting to read from memory. A byte is // output to the UART and if the memend signal isn't active it continues // to retrieve more data. If the memend signal goes active this process // will stop and the DTR, (DSR on the computer), will go active low, then // back high after sufficient time. If two consecutive "b"'s are received// then the module will attempt to receive characters from the PC and// write them to memory. Also, to allow for less than a full memory sample,// 32 'FF' characters can indicate the end of a transfer.

module sermach(clk, serrset, a, din, dout, mr, rd, wr, txrdy, rxrdy, memend, memrd, memwr, memdin, memdout, membusy, dsrclk, dsr, SerialStart, SerialStop); // Inputs - *'s are active lowinput clk; // clock for the moduleinput serrset; // reset variable for the moduleinput txrdy; //*from the UART -when low indicates there is room in TX FIFO // -when high indicates TX FIFO fullinput rxrdy; //*from the UART -when low indicates there is a char in the RX FIFO // -when high indicates nothing is in the RX FIFOinput memend; // from memory-indicates end of memory has been reachedinput membusy; // from memory-indicates memory is busyinput [7:0]memdin; // from memory-data input bus from meminput dsrclk; // clock so DTR can be held low for sufficient timeinput dsr; //*from PC - DTR on computer - indicates connectioninput [7:0]din; // data input bus from the UART

// variables used to latch inputsreg q_serrset;reg q_txrdy;reg q_rxrdy;reg q_memend;reg q_membusy;reg [7:0]q_memdin;reg q_dsrclk;reg q_dsr;reg [7:0]q_din;

// Outputs - *'s are active lowoutput [2:0]a; // address lines for the UARToutput mr; // master reset for the UARToutput rd; //*read signal going to the UARToutput wr; //*write signal going to the UARToutput memrd; // read signal to memory moduleoutput memwr; // write signal to memory moduleoutput [7:0]dout; // data output bus going to the UARToutput [7:0]memdout; //data output bus going to the memoryoutput SerialStart; // signal to the Master control module signaling startoutput SerialStop; // signal to the Master control module signaling stop

62

// Output Registersreg [2:0]a;reg mr;reg rd;reg wr;reg memrd;reg memwr;reg [7:0]dout;reg [7:0]memdout;reg SerialStart;reg SerialStop;

// State Symbolic Namesparameter INIT0 = 0, INIT1 = 1, INIT2 = 2, INIT3 = 3, INIT4 = 4, INIT5 = 5, INIT6 = 6, INIT7 = 7, INIT8 = 8, INIT9 = 9, INIT10 = 10, MRhold = 11, WRSEQ1 = 12, WRSEQ2 = 13, WAITRX = 15, RXCHAR1 = 20, RXCHAR2 = 21, RXCHAR3 = 22, RXCHAR4 = 23, SNDMEM1 = 25, SNDMEM2 = 26, SNDMEM3 = 27, SNDMEM4 = 28, SNDMEM5 = 29, SNDMEM6 = 30, SNDMEM7 = 31, SNDMEM8 = 32, SNDMEM9 = 33, ENDMEM1 = 35, ENDMEM2 = 36, ENDMEM3 = 37, ENDMEM4 = 38, ENDMEM5 = 39, WRMEM1 = 40, WRMEM2 = 41, WRMEM3 = 42, WRMEM4 = 43, WRMEM5 = 44, WRMEM6 = 45, WRMEM7 = 46, WRMEM8 = 47, WRMEM9 = 48, CONN = 60, NOTCONN0 = 61, NOTCONN = 62, ERRWRRD = 63;

// Internal Variablesreg [5:0] NEXTSTATE; // state to go to after completing write sequencereg [5:0] CS; // current statereg [5:0] NS; // next statereg [7:0] tempd; // storage of data from DINreg [4:0] counter; // counter to hold MR and for sending stream of datareg connected; // indicates a connection - used for following DSRreg gota; // got an "a" alreadyreg gotb; // got a "b" already

63

// First always block latches all inputs so they can't change during actual use// Special conditions are also checkedalways @ (posedge clk) begin q_serrset = serrset; q_txrdy = txrdy; q_rxrdy = rxrdy; q_memend = memend; q_membusy = membusy; q_memdin = memdin; q_dsrclk = dsrclk; q_dsr = dsr; q_din = din; if (q_serrset) // serial module reset CS = INIT0; else if (!rd && !wr) // read and write signals both asserted (very bad) CS = ERRWRRD; else if (q_dsr && connected) // got DSR inactive while connected CS = NOTCONN0; else if (q_dsr) // not connected to PC CS = NOTCONN; else if (!q_dsr && !connected) // initial connection to PC CS = CONN; else // defaultly go to next state CS = NS;end // first always

// Second always block "actually does something" with each statealways @ (negedge clk) begin case (CS) INIT0: begin // initial reset when first reset mr = 0; a = 0; dout = 0; rd = 1; wr = 1; connected = 0; tempd = 0; memrd = 0; memwr = 0; memdout = 0; gota = 0; gotb = 0; SerialStart = 0; SerialStop = 0; NEXTSTATE = INIT1; NS = INIT1; end INIT1: begin // clocking Master Reset of the UART // resets registers to specifications in data book mr = 1; a = 0; dout = 0; rd = 1; wr = 1; tempd = 0; counter = 0; memrd = 0; memwr = 0; memdout = 0; gota = 0; gotb = 0; NS = MRhold; end MRhold: begin // hold MR active high for at least 5000ns counter = counter + 1; if (counter > 'd22)

64

NS = INIT2; else NS = MRhold; end INIT2: begin counter = 0; mr = 0; NS = INIT3; end INIT3: begin // acessing LCR (Line Control Register) // setting DLAB (Divisor Latch Access Bit) to 1 a = 3; dout = 'd131; NEXTSTATE = INIT4; NS = WRSEQ1; end WRSEQ1: begin // sets write pin to active (low) wr = 0; NS = WRSEQ2; end WRSEQ2: begin // sets write pin to inactive (high) wr = 1; NS = NEXTSTATE; end INIT4: begin // set LSB of divisor latch // 18.432Mhz // 9600-120 14400-80 28800-40 57600-20 115200-10 a = 0; dout = 'd10; NEXTSTATE = INIT5; NS = WRSEQ1; end INIT5: begin // set MSB of divisor latch a = 1; dout = 0; NEXTSTATE = INIT6; NS = WRSEQ1; end INIT6: begin // acessing LCR (Line Control Register) // setting DLAB (Divisor Latch Access Bit) to 0 // setup communications to be 8N1 // 8 data bits - No parity - 1 stop bit a = 3; dout = 3; NEXTSTATE = INIT7; NS = WRSEQ1; end INIT7: begin // accessing MCR (Modem Control Register) // sets all contol lines to be inactive a = 4; dout = 0; NEXTSTATE = INIT8; NS = WRSEQ1; end INIT8: begin // accessing IER (Interrupt Enable Register) // turn off all interrupts a = 1; dout = 0; NEXTSTATE = INIT9; NS = WRSEQ1; end INIT9: begin // accessing FCR (FIFO Control Register)

65

// Enable and Reset FIFOs a = 2; dout = 'd15; NEXTSTATE = INIT10; NS = WRSEQ1; end INIT10: begin // if there's a character in RX FIFO flush it out // else go wait for a character if (!q_rxrdy) NS = INIT9; else NS = WAITRX; end WAITRX: begin // if character then start read process // else stay here a = 0; tempd = 0; counter = 0; if (!q_rxrdy) NS = RXCHAR1; else NS = WAITRX; end RXCHAR1: begin // set read pin active rd = 0; NS = RXCHAR2; end RXCHAR2: begin // get data off data input bus tempd = q_din; NS = RXCHAR3; end RXCHAR3: begin // set read pin inactive rd = 1; NS = RXCHAR4; end RXCHAR4: begin // parse control characters case (tempd) 'd97:begin // got "a" - read memory, send to PC if (gota) begin gota = 0; SerialStart = 1; // send start to main NS = SNDMEM1; end else begin gota = 1; gotb = 0; NS = WAITRX; end end 'd98:begin // got "b" - get data from PC, write memory if (gotb) begin gotb = 0; SerialStart = 1; // send start to main NS = WRMEM1; end else begin gotb = 1; gota = 0; NS = WAITRX; end end default:begin gota = 0; gotb = 0; NS = WAITRX;

66

end endcase end SNDMEM1: begin // if at the end of memory start end of memory process // else continue send process SerialStart = 0; // deassert start to main if (q_memend) NS = ENDMEM1; else NS = SNDMEM2; end SNDMEM2: begin // if memory is not busy then continue send process // else stay here if (!q_membusy) NS = SNDMEM3; else NS = SNDMEM2; end SNDMEM3: begin // set memory read pin active memrd = 1; NS = SNDMEM4; end SNDMEM4: begin // set memory read pin inactive memrd = 0; NS = SNDMEM5; end SNDMEM5: begin // if memory is not busy then continue send process // else stay here if (!q_membusy) NS = SNDMEM6; else NS = SNDMEM5; end SNDMEM6: begin // set address line // put data from memory on data out bus // check to see if byte is end character, increment counter a = 0; dout = q_memdin; if (q_memdin == 'hFF) counter = counter + 1; else counter = 0; NS = SNDMEM7; end SNDMEM7: begin // if room in TX FIFO continue with send process // else stay here till there is room if (!q_txrdy) NS = SNDMEM8; else NS = SNDMEM7; end SNDMEM8: begin // if gotten full end sequence stop // else go through write process and start over send if (counter == 'd31) // end of data sequence NEXTSTATE = ENDMEM1; else NEXTSTATE = SNDMEM1; NS = WRSEQ1; end ENDMEM1: begin // wait for high of dsr clock if (q_dsrclk) NS = ENDMEM2;

67

else NS = ENDMEM1; end ENDMEM2: begin // accessing MCR (Modem Control Register) // sets DTR to active a = 4; dout = 1; NEXTSTATE = ENDMEM3; NS = WRSEQ1; end ENDMEM3: begin // wait for low of dsr clock if (!q_dsrclk) NS = ENDMEM4; else NS = ENDMEM3; end ENDMEM4: begin // once high of dsr clock, then gauranteed at least // one full clock pulse with DTR active if (q_dsrclk) begin NS = ENDMEM5; SerialStop = 1; // send stop to main end else NS = ENDMEM4; end ENDMEM5: begin // accessing MCR (Modem Control Register) // sets DTR to inactive a = 4; dout = 0; SerialStop = 0; // deassert stop to main NEXTSTATE = WAITRX; NS = WRSEQ1; end WRMEM1: begin // wait for character to be received by UART SerialStart = 0; // deassert start to main a = 0; tempd = 0; if (!q_rxrdy) NS = WRMEM2; else NS = WRMEM1; end WRMEM2: begin // set read pin active, toggle LED rd = 0; NS = WRMEM3; end WRMEM3: begin // get data off data input bus tempd = q_din; NS = WRMEM4; end WRMEM4: begin // set read pin inactive rd = 1; NS = WRMEM5; end WRMEM5: begin // set memdout line and check if at end of memory memdout = tempd; if (q_memend) NS = ENDMEM1; else NS = WRMEM6; end

68

WRMEM6: begin // if memory is not busy then continue write mem process // else stay here if (!q_membusy) NS = WRMEM7; else NS = WRMEM6; end WRMEM7: begin // set memory write pin active memwr = 1; NS = WRMEM8; end WRMEM8: begin // set memory write pin inactive memwr = 0; NS = WRMEM9; end WRMEM9: begin // if memory is not busy then continue write mem process // else stay here if (!q_membusy) NS = WRMEM1; else NS = WRMEM9; end CONN: begin // go here when DSR initially goes active connected = 1; NS = INIT1; end NOTCONN0:begin // was connected but lost connection // reset important pins and send stop to main rd = 1; wr = 1; memwr = 0; memrd = 0; connected = 0; SerialStop = 1; NS = NOTCONN; end NOTCONN: begin // go here if DSR is inactive (no connection) // reset important pins and deassert stop to main rd = 1; wr = 1; memwr = 0; memrd = 0; connected = 0; SerialStop = 0; NS = NOTCONN; end ERRWRRD: begin // if here then both the read and write signals are asserted NS = INIT1; end default: begin // should never, ever be here end endcase end // alwaysendmodule // main state module

69

Main App code

Dim maincounter As Integer ' when writing to mem on device, counts end charsDim rawFileSize As Long ' Size of the Raw data fileDim hRawFile As Integer ' Handle for Raw sound fileDim hWavFile As Integer ' Handle for converted wave fileDim hCmpFile As Integer ' Handle for compressed sound fileDim hTmpFile As Integer ' Handle for temporary wave fileDim hLogFile As Integer ' Handle of open log file.

' This is the Subroutine that is called whenever the form is loaded.Private Sub Form_Load() App.Title = "PDACS User Application" 'Give our prog a name MSComm1.CommPort = 2 ' use Com port 2 MSComm1.Settings = "115200,N,8,1" MSComm1.InputLen = 0 ' read entire buffer when Input MSComm1.InBufferSize = 16384 MSComm1.RThreshold = 1024 ' after 1 char received, notify MSComm1.Handshaking = comNone ' no handshaking MSComm1.InputMode = comInputModeBinary ' input in binary mode ' initialize file handles hLogFile = 0 hWavFile = 0 hRawFile = 0 hCmpFile = 0 hTmpFile = 0 ' Set initial property values of the media device MMControl1.Notify = False MMControl1.Wait = True MMControl1.Shareable = False MMControl1.DeviceType = "Waveaudio" MMControl1.Visible = False ' Hide the multimedia controls Command1.Visible = False ' Hide the button to hide multimedia controls Call ClosePort ' Verify the comm port is already closed StatusBar1.Panels("Data").Text = "" ' We aren't doing anythingEnd Sub

' This is the procedure that is called when the form is closedPrivate Sub Form_Unload(Cancel As Integer) Call ClosePort 'Clean up any open files If hRawFile Then Close hRawFile hRawFile = 0 End If If hWavFile Then Close hWavFile hWavFile = 0 End If If hLogFile Then Close hLogFile hLogFile = 0 End IfEnd Sub

' This procedure is called when the user chooses the file download option' from the menu and wants to download a file from the PDACS device to the' PC over the serial portPrivate Sub FileDownload_Click() On Error GoTo errhandler 'In case the file dialog box cancel is called Call ClosePort

70

CommonDialog1.Flags = cdlOFNHideReadOnly CommonDialog1.Filter = "RAW Files (*.raw)|*.raw|All Files (*.*)|*.*" CommonDialog1.ShowSave ' Call the save file procedure ' If file exists ask to overwrite it Dim fs Set fs = CreateObject("Scripting.FileSystemObject") If fs.FileExists(CommonDialog1.FileName) Then If (MsgBox("File Exists, Overwrite?", vbYesNo) = vbYes) Then fs.deletefile (CommonDialog1.FileName) Else Exit Sub End If End If ' Open the log file hLogFile = FreeFile Open CommonDialog1.FileName For Binary Access Write As hLogFile If Not MSComm1.PortOpen Then 'Is port already open MSComm1.PortOpen = True StatusBar1.Panels("Status").Text = "Port Open" Else MSComm1.PortOpen = False MSComm1.PortOpen = True StatusBar1.Panels("Status").Text = "Port Open" End If ' Turn DTR on to initiate connection MSComm1.DTREnable = True ' Turn DTR on. MSComm1.Output = "aa" ' Send the device a character Exit Suberrhandler: ' if Cancel pressed then exit If Err = cdlCancel Then Exit Sub Else ' otherwise display error message MsgBox Error$, 48 Close hLogFile hLogFile = 0 End If Exit SubEnd Sub

' This subroutine opens up a raw file and transmits it to the device until' the device is full (signaling that through a DSR), or the end of the file' is reached, which is signaled by turning off the DTRPrivate Sub FileUpload_Click()

Dim counter As Integer ' forms 16 byte arrayDim temp As Byte ' read from file, output to portDim temparr(15) As Byte ' 16 byte array to send to serial portDim outbuf As Variant ' variant buffer to really send to port

On Error GoTo errhandler ' Initialize Call ClosePort maincounter = 0 counter = 0 hRawFile = 0 ' Get Raw filename CommonDialog2.Flags = cdlOFNHideReadOnly CommonDialog2.Filter = "RAW Files (*.raw)|*.raw|All Files (*.*)|*.*" CommonDialog2.ShowOpen ' Call the open file procedure ' Open Raw File

71

hRawFile = FreeFile Open CommonDialog2.FileName For Binary Access Read As hRawFile If Not MSComm1.PortOpen Then 'Is port already open MSComm1.PortOpen = True StatusBar1.Panels("Status").Text = "Port Open" Else MSComm1.PortOpen = False MSComm1.PortOpen = True StatusBar1.Panels("Status").Text = "Port Open" End If ' Turn DTR on to initiate connection MSComm1.DTREnable = True ' Turn DTR on MSComm1.Output = "bb" ' Send the device proper start characters StatusBar1.Panels("Data").Text = "Uploading Data"

' Read first 16 bytes from file counter = 0 Do Get hRawFile, , temp ' read byte If EOF(hRawFile) Then ' check if end of file StatusBar1.Panels("Data").Text = "" Close hRawFile ' if end of file close down hRawFile = 0 Exit Sub End If temparr(counter) = temp ' store byte in byte array counter = counter + 1 ' add to counter Loop Until (counter = 16) ' if gotten 16 bytes stop outbuf = temparr ' store byte array to variant MSComm1.Output = outbuf ' output buffer to serial port counter = 0 maincounter = 0 ' initialize main counter Timer1.Interval = 10 ' start timer to go off after 10ms Timer1.Enabled = True Exit Suberrhandler: If Err = cdlCancel Then Exit Sub Else MsgBox Error$, 48 Close hRawFile hRawFile = 0 End If Exit SubEnd Sub

' Go here once timer goes off' Allows wait time before sending another 16 bytesPrivate Sub Timer1_Timer()

Dim counter As Integer ' forms 16 byte arrayDim temp As Byte ' read from file, output to portDim temparr(15) As Byte ' 16 byte array to send to serial portDim outbuf As Variant ' variant buffer to really send to portDim GotEnd As Boolean ' indicates got end of fileDim i As Integer ' temp var

On Error GoTo errhandler ' checks to see if got to EOF and sent any 0xFF's, end char If (maincounter = 0) Then GotEnd = False counter = 0 Do Get hRawFile, , temp

72

If EOF(hRawFile) Then GotEnd = True Exit Do End If temparr(counter) = temp counter = counter + 1 Loop Until (counter >= 16) If (Not GotEnd) Then ' if not end of file outbuf = temparr ' output data MSComm1.Output = outbuf Else Close hRawFile ' got end of file so close file hRawFile = 0 maincounter = 1 End If Else ' need to send plenty of ending characters For counter = 0 To 15 ' fill array with 0xFF temparr(counter) = &HFF Next counter = 0 maincounter = maincounter + 16 ' increment counter outbuf = temparr ' output buffer of 0xFF MSComm1.Output = outbuf If (maincounter >= 600) Then ' send 600 0xFF's Call ClosePort ' if sent them all then stop StatusBar1.Panels("Data").Text = "" Timer1.Enabled = False maincounter = 0 ret = MsgBox("Upload Complete", vbOKOnly, "File Upload") End If End If Exit Suberrhandler: MsgBox Error$, 48 Close hRawFile hRawFile = 0 Exit SubEnd Sub

' This subroutine assigns the two file handles for the raw file to convert' and the wav file it will be converted to.Private Sub FileConvert_Click() On Error GoTo errhandler ' Get Raw filename CommonDialog2.Flags = cdlOFNHideReadOnly CommonDialog2.Filter = "RAW Files (*.raw)|*.raw|All Files (*.*)|*.*" CommonDialog2.ShowOpen ' Call the open file procedure ' Get Wav filename CommonDialog3.Flags = cdlOFNHideReadOnly CommonDialog3.Filter = "Wav Files (*.wav)|*.wav|All Files (*.*)|*.*" CommonDialog3.ShowSave ' Call the save file procedure hRawFile = FreeFile ' Get the Size of the RAW file for conversion Dim fs, f Set fs = CreateObject("Scripting.FileSystemObject") Set f = fs.GetFile(CommonDialog2.FileName) rawFileSize = f.Size ' Open Raw file Open CommonDialog2.FileName For Binary Access Read As hRawFile

73

' Check if file exists and ask to overwrite or not Dim fs1 Set fs1 = CreateObject("Scripting.FileSystemObject") If fs1.FileExists(CommonDialog3.FileName) Then If (MsgBox("File Exists, Overwrite?", vbYesNo) = vbYes) Then fs1.deletefile (CommonDialog3.FileName) Else Exit Sub End If End If ' Open Wave file hWavFile = FreeFile Open CommonDialog3.FileName For Binary Access Read Write As hWavFile StatusBar1.Panels("Data").Text = "Converting" ' Convert the raw file to a wav file RawToWav hRawFile, hWavFile ' Close the open files Close hRawFile Close hWavFile hRavFile = 0 hWavFile = 0 ' Signal Finished ret = MsgBox("Conversion complete", vbOKOnly, "File Conversion") StatusBar1.Panels("Data").Text = "" Exit Suberrhandler: If Err = cdlCancel Then Exit Sub Else MsgBox Error$, 48 Close hRawFile hRawFile = 0 Close hWavFile hWavFile = 0 End If Exit SubEnd Sub

' Go here when clicked on Play Raw FilePrivate Sub FilePlay_Click()

On Error GoTo errhandler

' Get Raw filename CommonDialog2.Flags = cdlOFNHideReadOnly 'hide that silly read only check box CommonDialog2.Filter = "RAW Files (*.raw)|*.raw|All Files (*.*)|*.*" CommonDialog2.ShowOpen ' Call the open file procedure ' Open Raw file hRawFile = FreeFile Open CommonDialog2.FileName For Binary Access Read As hRawFile ' Get the Size of the RAW file for conversion Dim fs, f Set fs = CreateObject("Scripting.FileSystemObject") Set f = fs.GetFile(CommonDialog2.FileName) rawFileSize = f.Size ' Create wave file handle ' Create the temporary wavfile in the application directory hWavFile = FreeFile Open "dac000.wav" For Binary Access Write As hWavFile StatusBar1.Panels("Data").Text = "Converting before Playing"

74

' Convert the raw file to a wav file RawToWav hRawFile, hWavFile StatusBar1.Panels("Data").Text = "" ' Close files Close hRawFile Close hWavFile hRawFile = 0 hWavFile = 0 ' Play the temporary wave file PlayWav "dac000.wav" Exit Suberrhandler: If Err = cdlCancel Then Exit Sub Else MsgBox Error$, 48 Close hRawFile hRawFile = 0 Close hWavFile hWavFile = 0 End If Exit SubEnd Sub

' Used for setting comm port propertiesPrivate Sub SetPortset_Click() frmProperties.ShowEnd Sub

' Shows the About formPrivate Sub helpAbout_Click() frmAbout.ShowEnd Sub

' When we want to exitPrivate Sub exit_Click() Unload Form1End Sub

' This function is an event handler for the MSComm object. It watches for' MSComm events and responds appropriately to each.Private Sub MSComm1_OnComm() Dim ERMsg$ Dim inData As String Select Case MSComm1.CommEvent ' Event Messages Case comEvReceive StatusBar1.Panels("Data").Text = "Receiving Data" ' Update status bar inData = MSComm1.Input ' Read data from serial port writeFile inData Case comEvSend Case comEvCTS Case comEvDSR If MSComm1.DSRHolding Then ret = MsgBox("Download Complete", vbOKOnly, "File Download") Else ret = MsgBox("Download Complete.", vbOKOnly, "File Download") End If StatusBar1.Panels("Data").Text = "" ' Update status bar inData = MSComm1.Input ' Read data from serial port writeFile inData If hLogFile Then Close hLogFile hLogFile = 0 End If

75

MSComm1.DTREnable = False Call ClosePort Case comEvCD ' Change in CD Detected Case comEvRing ' The Phone is Ringing Case comEvEOF ' End of File Detected

' Error messages. Case comBreak ERMsg$ = "Break Received" Case comCDTO ERMsg$ = "Carrier Detect Timeout" Case comCTSTO ERMsg$ = "CTS Timeout" Case comDCB ERMsg$ = "Error retrieving DCB" Case comDSRTO ERMsg$ = "DSR Timeout" Case comFrame ERMsg$ = "Framing Error" Case comOverrun ERMsg$ = "Overrun Error" Case comRxOver ERMsg$ = "Receive Buffer Overflow" Case comRxParity ERMsg$ = "Parity Error" Case comTxFull ERMsg$ = "Transmit Buffer Full" Case Else ERMsg$ = "Unknown error or event" End Select If Len(ERMsg$) Then ' Display error messages in an alert message box. Beep ret = MsgBox(ERMsg$, vbOKCancel, "Click Cancel to quit, OK to ignore.") ' If the user clicks Cancel... If ret = vbCancel Then Unload Form1 End If End IfEnd Sub

' This subroutine converts a Raw sound file to a windows .wav file' First it copies the appropriate header to the new file, and then' perfoms a binary byte by byte copy of the raw data to the end of the' .wav filePrivate Static Sub RawToWav(rawFile As Integer, wavFile As Integer)

Dim temp As Byte Dim tempSize As Long

rawFileSize = rawFileSize + 44 'Adjust for the new .wav header 'First add the string RIFF to the header of a file temp = 82 'R's value in decimal, 0x52 in hex Put wavFile, , temp temp = 73 'I's value in decimal, 0x49 Put wavFile, , temp temp = 70 'F's valu in decimal, 0x46 in hex Put wavFile, , temp Put wavFile, , temp ' Now write the file size -8 tempSize = rawFileSize - 8 Put wavFile, , tempSize 'Now write WAVEfmt_ temp = 87 'W Put wavFile, , temp temp = 65 'A

76

Put wavFile, , temp temp = 86 'V Put wavFile, , temp temp = 69 'E Put wavFile, , temp temp = 102 'f Put wavFile, , temp temp = 109 'm Put wavFile, , temp temp = 116 't Put wavFile, , temp temp = 32 '_ Put wavFile, , temp 'Size of fmt header 0x00000010 temp = 16 ' 16 in decimal, 0x10 in hex Put wavFile, , temp temp = 0 ' used for the leading zeroes Put wavFile, , temp Put wavFile, , temp Put wavFile, , temp 'fmt tag 0x0001= PCM temp = 1 Put wavFile, , temp temp = 0 Put wavFile, , temp '# of channels 0x0001 = mono temp = 1 Put wavFile, , temp temp = 0 Put wavFile, , temp 'Samples per second 8000 = 0x00001F40 temp = 64 ' 40h Put wavFile, , temp temp = 31 '1F Put wavFile, , temp temp = 0 Put wavFile, , temp temp = 0 Put wavFile, , temp 'Bytes per second 4 bytes = 0x00001F40 temp = 64 ' 40h Put wavFile, , temp temp = 31 '1F Put wavFile, , temp temp = 0 Put wavFile, , temp temp = 0 Put wavFile, , temp 'block align temp = 1 Put wavFile, , temp temp = 0 Put wavFile, , temp 'bits per sample temp = 8 Put wavFile, , temp temp = 0 Put wavFile, , temp 'data temp = 100 'd Put wavFile, , temp temp = 97 'a

77

Put wavFile, , temp temp = 116 'T Put wavFile, , temp temp = 97 'A Put wavFile, , temp 'length of a data block (i.e. file size - 44) tempSize = rawFileSize - 44 Put wavFile, , tempSize 'Copy the rest of the raw soundfile to the end of the wavefile Do Get rawFile, , temp If EOF(rawFile) Then Exit Do Else Put wavFile, , temp End If LoopEnd Sub

' Plays a wave file - Called by function to play wav or raw filePrivate Static Sub PlayWav(wavFile As String)

On Error GoTo errhandler

' Make controls visible MMControl1.Visible = True Command1.Visible = True

' Sets up multimedia control to open and play a wave file MMControl1.FileName = wavFile MMControl1.Command = "Open" MMControl1.Command = "Play"

' If error do a graceful shutdown If MMControl1.Error Then MsgBox MMControl1.ErrorMessage, vbCritical, "ErrorPlayWav" MMControl1.Visible = False MMControl1.Command = "Close" Command1.Visible = False End If

Exit Suberrhandler: MsgBox Error$, 48End Sub

' Checks to see if the port is open and then closes the port if it isPrivate Static Sub ClosePort() On Error GoTo errhandler If MSComm1.PortOpen Then MSComm1.PortOpen = False End If StatusBar1.Panels("Status").Text = "Port Closed" Exit Suberrhandler: MsgBox Error$, 48End Sub

' Writes a byte to the file - called from MSComm1.OnReceivePrivate Static Sub writeFile(inData As String)

Dim temp() As Byte

temp = inData ' Store input data to byte variable

78

Put hLogFile, , temp ' Write byte to fileEnd Sub

' This corresponds to the button used to control wheather or not the' multimedia controls are visible. This is used after a person is done' reviewing the open audio filePrivate Sub Command1_Click() MMControl1.Visible = False ' Hide multimedia controls Command1.Visible = False ' Hide itself ' Clean up the open files, especially the temporary one ' Close the open wavFile and free the file handle If hWavFile Then Close hWavFile hWavFile = 0 End If MMControl1.Command = "Close" ' Close the multimedia device ' Delete temporary file Dim fs Set fs = CreateObject("Scripting.FileSystemObject") If fs.FileExists("dac000.wav") Then fs.deletefile ("dac000.wav") End IfEnd Sub

' Called when click on Play wave filePrivate Sub FileWave_Click() On Error GoTo errhandler ' Get Wav filename CommonDialog2.FileName = "" CommonDialog2.Flags = cdlOFNHideReadOnly 'hide that silly read only check box CommonDialog2.Filter = "WAV Files (*.wav)|*.wav|All Files (*.*)|*.*" CommonDialog2.ShowOpen ' Call the open file procedure ' Play the wave file PlayWav CommonDialog2.FileName Exit Suberrhandler: If Err = cdlCancel Then Exit Sub Else MsgBox Error$, 48 End If Exit SubEnd Sub

79

Serial App code

Private Sub Form_Load() ' Make initial setting for communication to a serial port MSComm1.CommPort = 2 ' use Com port 2 MSComm1.Settings = "115200,N,8,1" MSComm1.InputLen = 0 ' read entire buffer when Input MSComm1.RThreshold = 1 ' after 1 char received, notify MSComm1.Handshaking = comNone ' no handshaking MSComm1.InputMode = comInputModeBinary ' input in binary mode If Not MSComm1.PortOpen Then MSComm1.PortOpen = True ' Open the port End If MSComm1.DTREnable = False ' Clear text boxes Text1.Text = "" Text2.Text = ""End Sub

' Called when window is closedPrivate Sub Form_Unload(Cancel As Integer) MSComm1.PortOpen = False 'Close the portEnd Sub

' Called when checkbox clicked onPrivate Sub SetDTR_Click() If MSComm1.DTREnable Then MSComm1.DTREnable = False Else MSComm1.DTREnable = True End IfEnd Sub

' Called when key pressed in transmit windowPrivate Sub Text2_KeyPress(KeyAscii As Integer) MSComm1.Output = Chr$(KeyAscii) ShowData Text2, Chr$(KeyAscii) KeyAscii = 0End Sub

' handles all mscomm eventsPrivate Sub MSComm1_OnComm() Dim ERMsg$ Dim inData As String Select Case MSComm1.CommEvent ' Event Messages Case comEvReceive inData = MSComm1.Input ' Read data from serial port ShowData Text1, (StrConv(inData, vbUnicode)) Case comEvSend Case comEvCTS Case comEvDSR If MSComm1.DSRHolding Then StatusBar1.Panels("DSR").Text = "DSR: True" ShowData Text2, "Got DSR TRUE" Else StatusBar1.Panels("DSR").Text = "DSR: False" ShowData Text2, "Got DSR FALSE" End If Case comEvCD ' Change in CD Detected Case comEvRing ' The Phone is Ringing Case comEvEOF ' End of File Detected

80

' Error messages. Case comBreak ERMsg$ = "Break Received" Case comCDTO ERMsg$ = "Carrier Detect Timeout" Case comCTSTO ERMsg$ = "CTS Timeout" Case comDCB ERMsg$ = "Error retrieving DCB" Case comDSRTO ERMsg$ = "DSR Timeout" Case comFrame ERMsg$ = "Framing Error" Case comOverrun ERMsg$ = "Overrun Error" Case comRxOver ERMsg$ = "Receive Buffer Overflow" Case comRxParity ERMsg$ = "Parity Error" Case comTxFull ERMsg$ = "Transmit Buffer Full" Case Else ERMsg$ = "Unknown error or event" End Select If Len(ERMsg$) Then ' Display error messages in an alert message box. Beep ret = MsgBox(ERMsg$, vbOKCancel, "Click Cancel to quit, OK to ignore.") ' If the user clicks Cancel... If ret = vbCancel Then Unload Form1 End If End IfEnd Sub

' Closes Serial PortPrivate Static Sub ClosePort() If MSComm1.PortOpen Then MSComm1.PortOpen = False End IfEnd Sub

' Clears windowPrivate Sub Command1_Click() Text2.Text = ""End Sub

' Clears windowPrivate Sub Command2_Click() Text1.Text = ""End Sub

' This procedure adds data to the Textbox. It also filters control' characters, such as BACKSPACE, carriage return, and line feeds.' BACKSPACE characters delete the character to the left, either in' the Text property, or the passed string. Line feed characters are' appended to all carriage returns. The size of the Text property is' also monitored so that it never exceeds MAXTERMSIZE characters.Private Static Sub ShowData(Term As Control, Data As String) On Error GoTo Handler Const MAXTERMSIZE = 16000 Dim TermSize As Long, i ' Make sure the existing text doesn't get too large. TermSize = Len(Term.Text) If TermSize > MAXTERMSIZE Then Term.Text = Mid$(Term.Text, 4097) TermSize = Len(Term.Text) End If

81

' Point to the end of Term's data. Term.SelStart = TermSize

' Filter/handle BACKSPACE characters. Do i = InStr(Data, Chr$(8)) If i Then If i = 1 Then Term.SelStart = TermSize - 1 Term.SelLength = 1 Data = Mid$(Data, i + 1) Else Data = Left$(Data, i - 2) & Mid$(Data, i + 1) End If End If Loop While i

' Eliminate line feeds. Do i = InStr(Data, Chr$(10)) If i Then Data = Left$(Data, i - 1) & Mid$(Data, i + 1) End If Loop While i

' Make sure all carriage returns have a line feed. i = 1 Do i = InStr(i, Data, Chr$(13)) If i Then Data = Left$(Data, i) & Chr$(10) & Mid$(Data, i + 1) i = i + 1 End If Loop While i

' Add the filtered data to the SelText property. Term.SelText = Data Term.SelStart = Len(Term.Text)Exit Sub

Handler: MsgBox Error$ Resume NextEnd Sub

82

Audio App

Dim hRawFile As Integer ' Handle for Raw sound fileDim hOutFile As Integer

' This is the Subroutine that is called whenever the form is loaded.Private Sub Form_Load() App.Title = "Audio Application" 'Give our prog a name hRawFile = 0End Sub

'This is the procedure that is called when the form is closedPrivate Sub Form_Unload(Cancel As Integer) 'Clean up any open files If hRawFile Then Close hRawFile hRawFile = 0 End IfEnd Sub

'When we want to exit.Private Sub exit_Click() Unload Form1End Sub ' When the user clicks on 'Get Data' from the main menu. High, Low, Mean, and' full histogram data is calculated for the raw file.Private Sub GetData_Click()Dim sum As LongDim count(255) As LongDim counter As LongDim high As ByteDim low As ByteDim temp As ByteDim avg As Long

On Error GoTo errhandler hRawFile = 0 hOutFile = 0 'Get Raw file (will eventually be a compressed file) CommonDialog2.Flags = cdlOFNHideReadOnly CommonDialog2.Filter = "RAW Files (*.raw)|*.raw|All Files (*.*)|*.*" CommonDialog2.ShowOpen ' Call the save file procedure hRawFile = FreeFile Open CommonDialog2.FileName For Binary Access Read As hRawFile CommonDialog2.Flags = cdlOFNHideReadOnly CommonDialog2.Filter = "HIS Files (*.his)|*.his|All Files (*.*)|*.*" CommonDialog2.ShowSave ' Call the save file procedure hOutFile = FreeFile Open CommonDialog2.FileName For Output As hOutFile sum = 0 counter = 0 temp = 0 high = 0 low = 0 Get hRawFile, , temp counter = counter + 1 sum = sum + temp high = &H0 low = &HFF

83

Do Get hRawFile, , temp count(temp) = count(temp) + 1 If EOF(hRawFile) Then Exit Do Else counter = counter + 1 sum = sum + temp If (temp <> &H0) Then If (temp <> &HFF) Then If (temp > high) Then high = temp End If If (temp < low) Then low = temp End If End If End If End If Loop avg = sum / counter Dim i As Integer For i = 0 To 255 Step 1 Write #hOutFile, i; count(i) Next i ret = MsgBox("High = " & Hex(high) & Chr(13) & "Low = " & Hex(low) & Chr(13) & "Average = " & Hex(avg), vbOKOnly, "Information Box")

Close hRawFileClose hOutFile

Exit Suberrhandler: If Err Then MsgBox Error$, 48 Close hRawFile hRawFile = 0 Close hOutFile hOutFile = 0 Exit Sub End IfEnd Sub

84

Initial attempt at Verilog DCT

module dct( clk, Reset, Busy, DataIn, DValid, DataOut, ALUstart, ALUint, ALUflt, ALUdone, ALUresult, DCTdone, Read, CONTROL, Results );

//input clk, ALUdone, DValid, Reset, Busy;input [63:0] DataIn;input [15:0] ALUresult;//output ALUstart, DCTdone;output [5:0] CONTROL;output [15:0] DataOut;output [7:0] ALUint, ALUflt;output Read;output [127:0] Results;//reg [15:0] DataOut;reg [3:0] n, k;reg [5:0] CONTROL, NEXT_K, NEXT_N, NEXT_M;reg [7:0] ALUint, ALUflt, temp2;reg ALUstart, DCTdone, ALUdone;reg Read;reg [23:0] temp;reg [14:0] temp3;reg [63:0] DataStore;reg [127:0] Results;//parameter N = 'd8;parameter const1 = 'b0100011;parameter const2 = 'b0110001;parameter const3 = 'b0101010;parameter const4 = 'b0011100;parameter const5 = 'b0001010;parameter const6 = 'b0101110;parameter const7 = 'b0010011;parameter START = 'b000000,

K0 = 'b000001,K1 = 'b000010,K2 = 'b000011,K3 = 'b000100,K4 = 'b000101,K5 = 'b000110,K6 = 'b000111,K7 = 'b001000,K_DONE = 'b001001,N0 = 'b001100,N1 = 'b001101,N2 = 'b001110,N3 = 'b001111,N4 = 'b010000,N5 = 'b010001,N6 = 'b010010,N7 = 'b010011,N_DONE = 'b010100,ALU_1 = 'b011000,ALU_2 = 'b011001,ALU_3 = 'b011010,ADD_1 = 'b011100,MEM_1 = 'b100000,MEM_2 = 'b100001,MEM_3 = 'b100010,MEM_4 = 'b100011,MEM_5 = 'b100100,MEM_6 = 'b100101,MEM_7 = 'b100110,MEM_8 = 'b100111,MEM_C1 = 'b110000,

85

MEM_C2 = 'b110001,MEM_DN = 'b110010;

//always @(posedge clk) begin

if ( Reset ) beginRead = 0;DataOut = 0;CONTROL = START;DataStore = DataIn;

end elsecase( CONTROL ) START: begin

if ( DValid ) beginCONTROL = K0;DataStore = DataIn;n = 0;k = 0;temp = 'd0;

end elseCONTROL = START;

endK0: begin

k = 0;DCTdone = 0;CONTROL = N0;NEXT_K = K1;

endK1: begin

Results[15:0] = temp[22:7];k = 1;CONTROL = N0;NEXT_K = K2;

endK2: begin

Results[31:16] = temp[22:7];k = 2;CONTROL = N0;NEXT_K = K3;

endK3: begin

Results[47:32] = temp[22:7];k = 3;CONTROL = N0;NEXT_K = K4;

endK4: begin

Results[63:48] = temp[22:7];k = 4;CONTROL = N0;NEXT_K = K5;

endK5: begin

Results[79:64] = temp[22:7];k = 5;CONTROL = N0;NEXT_K = K6;

endK6: begin

Results[95:80] = temp[22:7];k = 6;CONTROL = N0;NEXT_K = K7;

endK7: begin

Results[111:96] = temp[22:7];k = 7;CONTROL = N0;NEXT_K = K_DONE;

endK_DONE: begin

Results[127:112] = temp[22:7];

86

CONTROL = MEM_1;end

N0: begintemp = 'd0;ALUint[7:0] = DataStore[7:0];ALUflt[7] = 0;if ( k == 0 ) begin

ALUflt[6:0] = const1;end else if ( k == 1 ) begin

ALUflt[6:0] = const2;end else if ( k == 2 ) begin

ALUflt[6:0] = const6;end else if ( k == 3 ) begin

ALUflt[6:0] = const3;end else if ( k == 4 ) begin

ALUflt[6:0] = const1;end else if ( k == 5 ) begin

ALUflt[6:0] = const4;end else if ( k == 6 ) begin

ALUflt[6:0] = const7;end else if ( k == 7 ) begin

ALUflt[6:0] = const5;endCONTROL = ALU_1;NEXT_N = N1;

endN1: begin

ALUint[7:0] = DataStore[15:8];ALUflt[7] = 0;if ( k == 0 ) begin

ALUflt[6:0] = const1;end else if ( k == 1 ) begin

ALUflt[6:0] = const3;end else if ( k == 2 ) begin

ALUflt[6:0] = const7;end else if ( k == 3 ) begin

ALUflt[6:0] = const5;ALUflt[7] = 1;

end else if ( k == 4 ) beginALUflt[6:0] = const1;ALUflt[7] = 1;

end else if ( k == 5 ) beginALUflt[6:0] = const2;ALUflt[7] = 1;

end else if ( k == 6 ) beginALUflt[6:0] = const6;ALUflt[7] = 1;

end else if ( k == 7 ) beginALUflt[6:0] = const4;ALUflt[7] = 1;

endCONTROL = ALU_1;NEXT_N = N2;

endN2: begin

ALUint[7:0] = DataStore[23:16];ALUflt[7] = 0;if ( k == 0 ) begin

ALUflt[6:0] = const1;end else if ( k == 1 ) begin

ALUflt[6:0] = const4;end else if ( k == 2 ) begin

ALUflt[6:0] = const7;ALUflt[7] = 1;

end else if ( k == 3 ) beginALUflt[6:0] = const2;ALUflt[7] = 1;

end else if ( k == 4 ) beginALUflt[6:0] = const1;ALUflt[7] = 1;

end else if ( k == 5 ) begin

87

ALUflt[6:0] = const5;end else if ( k == 6 ) begin

ALUflt[6:0] = const6;end else if ( k == 7 ) begin

ALUflt[6:0] = const3;endCONTROL = ALU_1;NEXT_N = N3;

endN3: begin

ALUint[7:0] = DataStore[31:24];ALUflt[7] = 0;if ( k == 0 ) begin

ALUflt[6:0] = const1;end else if ( k == 1 ) begin

ALUflt[6:0] = const5;end else if ( k == 2 ) begin

ALUflt[6:0] = const6;ALUflt[7] = 1;

end else if ( k == 3 ) beginALUflt[6:0] = const4;ALUflt[7] = 1;

end else if ( k == 4 ) beginALUflt[6:0] = const1;

end else if ( k == 5 ) beginALUflt[6:0] = const3;

end else if ( k == 6 ) beginALUflt[6:0] = const7;ALUflt[7] = 1;

end else if ( k == 7 ) beginALUflt[6:0] = const2;ALUflt[7] = 1;

endCONTROL = ALU_1;NEXT_N = N4;

endN4: begin

ALUint[7:0] = DataStore[39:32];ALUflt[7] = 0;if ( k == 0 ) begin

ALUflt[6:0] = const1;end else if ( k == 1 ) begin

ALUflt[6:0] = const5;ALUflt[7] = 0;

end else if ( k == 2 ) beginALUflt[6:0] = const6;ALUflt[7] = 1;

end else if ( k == 3 ) beginALUflt[6:0] = const4;

end else if ( k == 4 ) beginALUflt[6:0] = const1;

end else if ( k == 5 ) beginALUflt[6:0] = const3;ALUflt[7] = 1;

end else if ( k == 6 ) beginALUflt[6:0] = const7;ALUflt[7] = 1;

end else if ( k == 7 ) beginALUflt[6:0] = const2;

endCONTROL = ALU_1;NEXT_N = N5;

endN5: begin

ALUint[7:0] = DataStore[47:40];ALUflt[7] = 0;if ( k == 0 ) begin

ALUflt[6:0] = const1;end else if ( k == 1 ) begin

ALUflt[6:0] = const4;ALUflt[7] = 1;

88

end else if ( k == 2 ) beginALUflt[6:0] = const7;ALUflt[7] = 1;

end else if ( k == 3 ) beginALUflt[6:0] = const2;

end else if ( k == 4 ) beginALUflt[6:0] = const1;ALUflt[7] = 1;

end else if ( k == 5 ) beginALUflt[6:0] = const5;ALUflt[1] = 1;

end else if ( k == 6 ) beginALUflt[6:0] = const6;

end else if ( k == 7 ) beginALUflt[6:0] = const3;ALUflt[7] = 1;

endCONTROL = ALU_1;NEXT_N = N6;

endN6: begin

ALUint[7:0] = DataStore[55:48];ALUflt[7] = 0;if ( k == 0 ) begin

ALUflt[6:0] = const1;end else if ( k == 1 ) begin

ALUflt[6:0] = const3;ALUflt[7] = 1;

end else if ( k == 2 ) beginALUflt[6:0] = const7;

end else if ( k == 3 ) beginALUflt[6:0] = const5;

end else if ( k == 4 ) beginALUflt[6:0] = const1;ALUflt[7] = 1;

end else if ( k == 5 ) beginALUflt[6:0] = const2;

end else if ( k == 6 ) beginALUflt[6:0] = const6;ALUflt[7] = 1;

end else if ( k == 7 ) beginALUflt[6:0] = const4;

endCONTROL = ALU_1;NEXT_N = N7;

endN7: begin

ALUint[7:0] = DataStore[63:56];ALUflt[7] = 0;if ( k == 0 ) begin

ALUflt[6:0] = const1;end else if ( k == 1 ) begin

ALUflt[6:0] = const2;ALUflt[7] = 1;

end else if ( k == 2 ) beginALUflt[6:0] = const6;

end else if ( k == 3 ) beginALUflt[6:0] = const3;ALUflt[7] = 1;

end else if ( k == 4 ) beginALUflt[6:0] = const1;

end else if ( k == 5 ) beginALUflt[6:0] = const4;ALUflt[7] = 1;

end else if ( k == 6 ) beginALUflt[6:0] = const7;

end else if ( k == 7 ) beginALUflt[6:0] = const5;ALUflt[7] = 1;

endCONTROL = ALU_1;

89

NEXT_N = N_DONE;end

N_DONE: beginn = 0;

// temp = 'd0;CONTROL = NEXT_K;

endALU_1: begin

ALUstart = 1;CONTROL = ALU_2;

endALU_2: begin

ALUstart = 0;CONTROL = ALU_3;

endALU_3: begin

if ( ALUdone ) beginCONTROL = ADD_1;

end elseCONTROL = ALU_3;

endADD_1: begin

if ( temp[23] == ALUresult[15] ) begintemp2[7:0] = temp[6:0] + ALUresult[6:0];temp[22:7] = temp[22:7] + ALUresult[14:7];if ( temp2[7:0] >= 'd100 ) begin

temp[6:0] = temp2[7:0] - 'd100;temp[22:8] = temp[22:8] + 'd1;

end else temp[6:0] = temp2[6:0];

temp[23] = temp[23] && ALUresult[15];end else if ( temp[23] ) begin

if( temp[22:7] > ALUresult[14:7] ) beginif( temp[6:0] < ALUresult[6:0] ) begin

temp[22:7] = temp[22:7] - 1;temp2[7:0] = temp[6:0] + 100;

end elsetemp2[7:0] = temp[6:0];

temp[6:0] = temp2[7:0] - ALUresult[6:0];temp[22:7] = temp[22:7] - ALUresult[14:7];

temp[23] = 1;end else begin

if ( ALUresult[6:0] < temp[6:0] ) begin temp3[14:0] = ALUresult[14:7] - 'd1; temp2[7:0] = ALUresult[6:0] + 'd100;end else

temp2[7:0] = ALUresult[6:0]; temp[6:0] = temp2[7:0] - temp[6:0]; temp[22:7] = temp3[14:0] - temp[22:7];

temp[23] = 0;end

end else if ( ALUresult[15] ) beginif ( ALUresult[14:7] > temp[22:7] ) begin

if ( ALUresult[6:0] < temp[6:0] ) begin temp3[14:0] = ALUresult[14:7] - 'd1; temp2[7:0] = ALUresult[6:0] + 'd100;end else

temp2[7:0] = ALUresult[6:0]; temp[6:0] = temp2[7:0] - temp[6:0]; temp[22:7] = temp3[14:0] - temp[22:7];

temp[23] = 1;end else begin

if( temp[6:0] < ALUresult[6:0] ) begin

temp[22:7] = temp[22:7] - 1;temp2[7:0] = temp[6:0] + 100;

end elsetemp2[7:0] = temp[6:0];

90

temp[6:0] = temp2[7:0] - ALUresult[6:0];temp[22:7] = temp[22:7] - ALUresult[14:7];temp[23] = 0;end

endCONTROL = NEXT_N;

endMEM_1: begin

if ( !Busy ) beginDataOut[15:0] = temp[15:0];NEXT_M = MEM_2;CONTROL = MEM_C1;

end elseCONTROL = MEM_1;

endMEM_2: begin

if ( !Busy ) beginDataOut[15:0] = Results[31:16];NEXT_M = MEM_3;CONTROL = MEM_C1;

end elseCONTROL = MEM_2;

endMEM_3: begin

if ( !Busy ) beginDataOut[15:0] = Results[47:32];NEXT_M = MEM_4;CONTROL = MEM_C1;

end elseCONTROL = MEM_3;

endMEM_4: begin

if ( !Busy ) beginDataOut[15:0] = Results[63:48];NEXT_M = MEM_5;CONTROL = MEM_C1;

end elseCONTROL = MEM_4;

endMEM_5: begin

if ( !Busy ) beginDataOut[15:0] = Results[79:64];NEXT_M = MEM_6;CONTROL = MEM_C1;

end elseCONTROL = MEM_5;

endMEM_6: begin

if ( !Busy ) beginDataOut[15:0] = Results[95:80];NEXT_M = MEM_7;CONTROL = MEM_C1;

end elseCONTROL = MEM_6;

endMEM_7: begin

if ( !Busy ) beginDataOut[15:0] = Results[111:96];NEXT_M = MEM_8;CONTROL = MEM_C1;

end elseCONTROL = MEM_7;

endMEM_8: begin

if ( !Busy ) beginDataOut[7:0] = Results[127:112];NEXT_M = MEM_DN;CONTROL = MEM_C1;

end elseCONTROL = MEM_8;

end

91

MEM_C1: beginRead = 1;CONTROL = MEM_C2;

endMEM_C2: begin

Read = 0;CONTROL = NEXT_M;

endMEM_DN: begin

CONTROL = START;DCTdone = 1;

endendcase

end//endmodule

92

Run Length Decoding Compression

#include <stdio.h>#include <stdlib.h>

#define STOPCHAR 255

int main(int argc, char **argv){

int i; char temp; unsigned char current,runLength; FILE *ranFile,*cmpFile; if(argc != 3){ printf("usage: rld compressedfile outputfile\n"); exit(1); }

cmpFile = fopen(argv[1],"rb"); ranFile = fopen(argv[2],"wb");

while (1){ fscanf(cmpFile,"%c",&temp); if (temp == EOF){ fprintf(ranFile,"%c",EOF); break; } current = (unsigned char)temp; fscanf(cmpFile,"%c",&runLength); for(i=0; i < runLength; i++){ fprintf(ranFile,"%c",current); }

} fclose(ranFile); fclose(cmpFile);

}

93

Run Length Encoding Algorithm

#include <stdio.h>#include <stdlib.h>

#define STOPCHAR 255

int main( int argc, char **argv ){

int bytesRead; unsigned char current,prev,runLength; char temp; FILE *ranFile,*hisFile,*cmpFile;

if (argc !=3){ printf("usage: rle inputfile outputfile\n"); exit(1); }

ranFile = fopen(argv[1],"rb"); cmpFile = fopen(argv[2],"wb");

runLength = 1; bytesRead = 1; fscanf(ranFile,"%c",&prev);

while (1){ fscanf(ranFile,"%c",&temp);

if( temp == EOF){ fprintf(cmpFile,"%c",prev); fprintf(cmpFile,"%c",runLength); fprintf(cmpFile,"%c",EOF); break; } current = (unsigned char)temp; if (prev == current){ runLength++; if (runLength == 255){ fprintf(cmpFile,"%c",prev); fprintf(cmpFile,"%c",runLength); runLength = 1; } } else{ fprintf(cmpFile,"%c",prev); fprintf(cmpFile,"%c",runLength); runLength = 1; } prev = current;

} fclose(cmpFile); fclose(ranFile);

}

94

DCT Example Test Code

#include <stdio.h>#include <math.h>#include <stdlib.h>

#define N 8#define PI 3.14159

void dct( double values[N] ) {

double temp[N];double sum, c;int k, n;

for ( k = 0; k <= N-1; k++ )temp[k] = values[k];

for( k = 0; k <= N-1; k++ ) {if ( k == 0 )

c = sqrt( 1/(double)N );else

c = sqrt( 2/(double)N );sum = 0;for ( n = 0; n <= N-1; n++ )

sum = sum + (temp[n] * cos((PI*(2*n+1)*k)/(2*N)));values[k] = c * sum;

}}

void idct( double values[N] ) {

double temp[N];double sum, c;int k, n;

for ( k = 0; k <= N-1; k++ ) temp[k] = values[k];

for( n = 0; n <= N-1; n++ ) {sum = 0;for ( k = 0; k <= N-1; k++ ) {

if ( k == 0 ) c = sqrt( 1/(double)N ); else c = sqrt( 2/(double)N ); sum = sum + (c * temp[k] * cos((PI*(2*n+1)*k)/(2*N)));

}values[n] = (int) sum;

}}

int main( void ) {

double valueArray[N];int crackArray[N];int counter;

printf( "size = %d\n", N );printf( "Before DCT the values are: \n" );valueArray[0] = 16;valueArray[1] = 17;valueArray[2] = 18;valueArray[3] = 19;valueArray[4] = 20;valueArray[5] = 21;valueArray[6] = 22;valueArray[7] = 23;crackArray[0] = 1;crackArray[1] = 1;crackArray[2] = 1;

95

crackArray[3] = 1;crackArray[4] = 1;crackArray[5] = 1;crackArray[6] = 1;crackArray[7] = 1;

for ( counter = 0; counter <= N-1; counter++ ) {/* valueArray[counter] = (56-(counter+29))*1.0; *//* valueArray[counter] = 255; */printf( "%4d : %f\n", counter+1, valueArray[counter] );

}dct( valueArray );printf( "After DCT function the values are: \n" );for ( counter = 0; counter <= N-1; counter++ ) {

printf( "%4d : %f\n", counter+1, valueArray[counter] );/* valueArray[counter] = valueArray[counter] / (counter+1); */valueArray[counter] = valueArray[counter] / crackArray[counter];if ( ( valueArray[counter] < 1.5 ) && ( valueArray[counter] > -1.5 ) )

valueArray[counter] = 0; valueArray[counter] = (int)valueArray[counter];

}printf( "After coeffecient divide the values are: \n" );for ( counter = 0; counter <= N-1; counter++ ) {

printf( "%4d : %f\n", counter+1, valueArray[counter] );/* valueArray[counter] = valueArray[counter] * (counter+1); */valueArray[counter] = valueArray[counter] * crackArray[counter];

}idct( valueArray );printf( "After the Inverse DCT, the values are: \n" );for ( counter = 0; counter <= N-1; counter++ ) {

printf( "%4d : %f\n", counter+1, valueArray[counter] ); }}

96

DCT Compression Code

#include <stdio.h>#include <math.h>#include <stdlib.h>

#define invroot2 0.7071067814#define NUMVALS 8

static void rarrwrt(double f[],int n){ int i;

for (i=0; i<=n-1; i++){printf("%4d : %f\n",i,f[i]);

}}

/* fast DCT based on IEEE signal proc, 1992 #8, yugoslavian authors. */

static int N=0;static int m=0;static double two_over_N=0;static double root2_over_rootN=0;static double *C=NULL;

static void bitrev(double *f, int len){ int i,j,m,halflen; double temp;

if (len<=2) return; /* No action necessary if n=1 or n=2 */ halflen = len>>1; j=1; for(i=1; i<=len; i++){ if(i<j){ temp=f[j-1]; f[j-1]=f[i-1]; f[i-1]=temp; } m = halflen; while(j>m){ j=j-m; m=(m+1)>>1; } j=j+m; }}

static void inv_sums(double *f){ int ii,stepsize,stage,curptr,nthreads,thread,step,nsteps;

for(stage=1; stage <=m-1; stage++){ nthreads = 1<<(stage-1); stepsize = nthreads<<1; nsteps = (1<<(m-stage)) - 1; for(thread=1; thread<=nthreads; thread++){ curptr=N-thread; for(step=1; step<=nsteps; step++){ f[curptr] += f[curptr-stepsize]; curptr -= stepsize; } } }}

static void fwd_sums(double *f)

97

{ int ii,stepsize,stage,curptr,nthreads,thread,step,nsteps;

for(stage=m-1; stage >=1; stage--){ nthreads = 1<<(stage-1); stepsize = nthreads<<1; nsteps = (1<<(m-stage)) - 1; for(thread=1; thread<=nthreads; thread++){ curptr=nthreads +thread-1; for(step=1; step<=nsteps; step++){

f[curptr] += f[curptr+stepsize];curptr += stepsize;

} } }}

static void scramble(double *f,int len){ double temp; int i,ii1,ii2,halflen,qtrlen;

halflen = len >> 1; qtrlen = halflen >> 1; bitrev(f,len); bitrev(&f[0], halflen); bitrev(&f[halflen], halflen); ii1=len-1; ii2=halflen; for(i=0; i<=qtrlen-1; i++){ temp = f[ii1]; f[ii1] = f[ii2]; f[ii2] = temp; ii1--; ii2++; }}

static void unscramble(double *f,int len){ double temp; int i,ii1,ii2,halflen,qtrlen;

halflen = len >> 1; qtrlen = halflen >> 1; ii1 = len-1; ii2 = halflen; for(i=0; i<=qtrlen-1; i++){ temp = f[ii1]; f[ii1] = f[ii2]; f[ii2] = temp; ii1--; ii2++; } bitrev(&f[0], halflen); bitrev(&f[halflen], halflen); bitrev(f,len);}

static void initcosarray(int length){ int i,group,base,item,nitems,halfN; double factor;

printf("FCT-- new N=%d\n",length); m = -1; do{ m++; N = 1<<m; if (N>length){ printf("ERROR in FCT-- length %d not a power of 2\n",length);

98

exit(1); } }while(N<length); if(C != NULL) free(C); C = (double *)calloc(N,sizeof(double)); if(C == NULL){ printf("Unable to allocate C array\n"); exit(1); } halfN=N/2; two_over_N = 2.0/(double)N; root2_over_rootN = sqrt(2.0/(double)N); for(i=0;i<=halfN-1;i++) C[halfN+i]=4*i+1; for(group=1;group<=m-1;group++){ base= 1<<(group-1); nitems=base; factor = 1.0*(1<<(m-group)); for(item=1; item<=nitems;item++) C[base+item-1]=factor*C[halfN+item-1]; }

//printf("before taking cos, C array =\n"); rarrwrt(C,N); for(i=1;i<=N-1;i++) C[i] = 1.0/(2.0*cos(C[i]*M_PI/(2.0*N))); //printf("After taking cos, Carray = \n"); rarrwrt(C,N);}

static void inv_butterflies(double *f){ int stage,ii1,ii2,butterfly,ngroups,group,wingspan,increment,baseptr; double Cfac,T;

for(stage=1; stage<=m;stage++){ ngroups=1<<(m-stage); wingspan=1<<(stage-1); increment=wingspan<<1; for(butterfly=1; butterfly<=wingspan; butterfly++){ Cfac = C[wingspan+butterfly-1]; baseptr=0; for(group=1; group<=ngroups; group++){

ii1=baseptr+butterfly-1;ii2=ii1+wingspan;T=Cfac * f[ii2];f[ii2]=f[ii1]-T;f[ii1]=f[ii1]+T;baseptr += increment;

} } }}

static void fwd_butterflies(double *f){ int stage,ii1,ii2,butterfly,ngroups,group,wingspan,increment,baseptr; double Cfac,T;

for(stage=m; stage>=1;stage--){ ngroups=1<<(m-stage); wingspan=1<<(stage-1); increment=wingspan<<1; for(butterfly=1; butterfly<=wingspan; butterfly++){ Cfac = C[wingspan+butterfly-1]; baseptr=0; for(group=1; group<=ngroups; group++){

ii1=baseptr+butterfly-1;ii2=ii1+wingspan;T= f[ii2];f[ii2]=Cfac *(f[ii1]-T);f[ii1]=f[ii1]+T;baseptr += increment;

} }

99

}}

static void ifct_noscale(double *f, int length){ if (length != N) initcosarray(length); f[0] *= invroot2; inv_sums(f); bitrev(f,N); inv_butterflies(f); unscramble(f,N);}

static void fct_noscale(double *f, int length){ if (length != N) initcosarray(length); scramble(f,N); fwd_butterflies(f); bitrev(f,N); fwd_sums(f); f[0] *= invroot2; }

static void ifct_defn_scaling(double *f, int length){ ifct_noscale(f,length);}

static void fct_defn_scaling(double *f, int length){ int i;

fct_noscale(f,length); for(i=0;i<=N-1;i++) f[i] *= two_over_N;}

void ifct(double *f, int length){/* CALL THIS FOR INVERSE 1D DCT DON-MONRO PREFERRED SCALING */ int i;

if (length != N) initcosarray(length); /* BGS patch June 1997 */ for(i=0;i<=N-1;i++) f[i] *= root2_over_rootN; ifct_noscale(f,length);}

void fct(double *f, int length){/* CALL THIS FOR FORWARD 1D DCT DON-MONRO PREFERRED SCALING */ int i;

fct_noscale(f,length); for(i=0;i<=N-1;i++) f[i] *= root2_over_rootN;}

/**************************************************************** 2D FAST DCT SECTION****************************************************************/

#define VERBOSE 0

static double *g = NULL;static double two_over_sqrtncolsnrows = 0.0;static int ncolsvalue = 0;static int nrowsvalue = 0;

static void initfct2d(int nrows, int ncols){ if(VERBOSE) printf("FCT2D -- Initialising for new nrows=%d\n",nrows); if ((nrows<=0)||(ncols<0)){ printf("FCT2D -- ncols=%d or nrows=%d is <=0\n",nrows,ncols); exit(1); } if(g != NULL) free(g); g = (double *)calloc(nrows,sizeof(double));

100

if(g == NULL){ printf("FCT2D -- Unable to allocate g array\n"); exit(1); } ncolsvalue = ncols; nrowsvalue = nrows; two_over_sqrtncolsnrows = 2.0/sqrt(ncols*1.0*nrows);}

void fct2d(double f[], int nrows, int ncols)/* CALL THIS FOR FORWARD 2d DCT DON-MONRO PREFERRED SCALING */{ int u,v;

if ((ncols!=ncolsvalue)||(nrows!=nrowsvalue)){ initfct2d(nrows,ncols); } for (u=0; u<=nrows-1; u++){ fct_noscale(&f[u*ncols],ncols); } for (v=0; v<=ncols-1; v++){ for (u=0; u<=nrows-1; u++){ g[u] = f[u*ncols+v]; } fct_noscale(g,nrows); for (u=0; u<=nrows-1; u++){ f[u*ncols+v] = g[u]*two_over_sqrtncolsnrows; } }}

void ifct2d(double f[], int nrows, int ncols)/* CALL THIS FOR INVERSE 2d DCT DON-MONRO PREFERRED SCALING */{ int u,v;

if ((ncols!=ncolsvalue)||(nrows!=nrowsvalue)){ initfct2d(nrows,ncols); } for (u=0; u<=nrows-1; u++){ ifct_noscale(&f[u*ncols],ncols); } for (v=0; v<=ncols-1; v++){ for (u=0; u<=nrows-1; u++){ g[u] = f[u*ncols+v]; } ifct_noscale(g,nrows); for (u=0; u<=nrows-1; u++){ f[u*ncols+v] = g[u]*two_over_sqrtncolsnrows; } }}

/***************************************************************** UNCOMMENT THIS SECTION TO TEST 1D FAST DCT *****************************************************************/

int main(int argc, char **argv){ double f[NUMVALS]; int i,done=0; int temp,sizeRead=0,its =0 ; int *tmpVal; char tempChar; FILE *inFile,*outFile;

if (argc != 3){ printf("Usage: dctc file_to_compress compressed_file\n");

101

exit(1); }

tmpVal = (int *)malloc(sizeof(int));

inFile = fopen(argv[1],"rb"); outFile = fopen(argv[2],"wb");

while(1){ for(i=0;i<NUMVALS;i++){ f[i] =0 ; } for(i=0; i < NUMVALS; i++){ fscanf(inFile,"%c",&tempChar); if(tempChar != EOF) { sizeRead++; f[i] = (double)(unsigned char)tempChar;

} else{ done = 1; break; }

//load as many vals as possible }

//perform DCT fct(f,NUMVALS); its++; //divide out by quantiitzaiton matixmatrix for(i=0; i < sizeRead; i++){ f[i] = f[i] / (i +1); }

for(i=0;i < sizeRead; i++){ temp = (int) f[i]; tmpVal = &temp; fwrite(tmpVal,sizeof(int),1,outFile); } sizeRead = 0;

if(done){ fprintf(outFile,"%c",EOF); break; } }

return(0); }

102

DCT Decompression Code

#include <stdio.h>#include <math.h>#include <stdlib.h>

#define invroot2 0.7071067814#define NUMVALS 8

static void rarrwrt(double f[],int n){ int i;

for (i=0; i<=n-1; i++){printf("%4d : %f\n",i,f[i]);

}}

/* fast DCT based on IEEE signal proc, 1992 #8, yugoslavian authors. */

static int N=0;static int m=0;static double two_over_N=0;static double root2_over_rootN=0;static double *C=NULL;

static void bitrev(double *f, int len){ int i,j,m,halflen; double temp;

if (len<=2) return; /* No action necessary if n=1 or n=2 */ halflen = len>>1; j=1; for(i=1; i<=len; i++){ if(i<j){ temp=f[j-1]; f[j-1]=f[i-1]; f[i-1]=temp; } m = halflen; while(j>m){ j=j-m; m=(m+1)>>1; } j=j+m; }}

static void inv_sums(double *f){ int ii,stepsize,stage,curptr,nthreads,thread,step,nsteps;

for(stage=1; stage <=m-1; stage++){ nthreads = 1<<(stage-1); stepsize = nthreads<<1; nsteps = (1<<(m-stage)) - 1; for(thread=1; thread<=nthreads; thread++){ curptr=N-thread; for(step=1; step<=nsteps; step++){ f[curptr] += f[curptr-stepsize]; curptr -= stepsize; } } }}

static void fwd_sums(double *f){

103

int ii,stepsize,stage,curptr,nthreads,thread,step,nsteps;

for(stage=m-1; stage >=1; stage--){ nthreads = 1<<(stage-1); stepsize = nthreads<<1; nsteps = (1<<(m-stage)) - 1; for(thread=1; thread<=nthreads; thread++){ curptr=nthreads +thread-1; for(step=1; step<=nsteps; step++){

f[curptr] += f[curptr+stepsize];curptr += stepsize;

} } }}

static void scramble(double *f,int len){ double temp; int i,ii1,ii2,halflen,qtrlen;

halflen = len >> 1; qtrlen = halflen >> 1; bitrev(f,len); bitrev(&f[0], halflen); bitrev(&f[halflen], halflen); ii1=len-1; ii2=halflen; for(i=0; i<=qtrlen-1; i++){ temp = f[ii1]; f[ii1] = f[ii2]; f[ii2] = temp; ii1--; ii2++; }}

static void unscramble(double *f,int len){ double temp; int i,ii1,ii2,halflen,qtrlen;

halflen = len >> 1; qtrlen = halflen >> 1; ii1 = len-1; ii2 = halflen; for(i=0; i<=qtrlen-1; i++){ temp = f[ii1]; f[ii1] = f[ii2]; f[ii2] = temp; ii1--; ii2++; } bitrev(&f[0], halflen); bitrev(&f[halflen], halflen); bitrev(f,len);}

static void initcosarray(int length){ int i,group,base,item,nitems,halfN; double factor;

printf("FCT-- new N=%d\n",length); m = -1; do{ m++; N = 1<<m; if (N>length){ printf("ERROR in FCT-- length %d not a power of 2\n",length); exit(1); }

104

}while(N<length); if(C != NULL) free(C); C = (double *)calloc(N,sizeof(double)); if(C == NULL){ printf("Unable to allocate C array\n"); exit(1); } halfN=N/2; two_over_N = 2.0/(double)N; root2_over_rootN = sqrt(2.0/(double)N); for(i=0;i<=halfN-1;i++) C[halfN+i]=4*i+1; for(group=1;group<=m-1;group++){ base= 1<<(group-1); nitems=base; factor = 1.0*(1<<(m-group)); for(item=1; item<=nitems;item++) C[base+item-1]=factor*C[halfN+item-1]; }

//printf("before taking cos, C array =\n"); rarrwrt(C,N); for(i=1;i<=N-1;i++) C[i] = 1.0/(2.0*cos(C[i]*M_PI/(2.0*N))); //printf("After taking cos, Carray = \n"); rarrwrt(C,N);}

static void inv_butterflies(double *f){ int stage,ii1,ii2,butterfly,ngroups,group,wingspan,increment,baseptr; double Cfac,T;

for(stage=1; stage<=m;stage++){ ngroups=1<<(m-stage); wingspan=1<<(stage-1); increment=wingspan<<1; for(butterfly=1; butterfly<=wingspan; butterfly++){ Cfac = C[wingspan+butterfly-1]; baseptr=0; for(group=1; group<=ngroups; group++){

ii1=baseptr+butterfly-1;ii2=ii1+wingspan;T=Cfac * f[ii2];f[ii2]=f[ii1]-T;f[ii1]=f[ii1]+T;baseptr += increment;

} } }}

static void fwd_butterflies(double *f){ int stage,ii1,ii2,butterfly,ngroups,group,wingspan,increment,baseptr; double Cfac,T;

for(stage=m; stage>=1;stage--){ ngroups=1<<(m-stage); wingspan=1<<(stage-1); increment=wingspan<<1; for(butterfly=1; butterfly<=wingspan; butterfly++){ Cfac = C[wingspan+butterfly-1]; baseptr=0; for(group=1; group<=ngroups; group++){

ii1=baseptr+butterfly-1;ii2=ii1+wingspan;T= f[ii2];f[ii2]=Cfac *(f[ii1]-T);f[ii1]=f[ii1]+T;baseptr += increment;

} } }}

105

static void ifct_noscale(double *f, int length){ if (length != N) initcosarray(length); f[0] *= invroot2; inv_sums(f); bitrev(f,N); inv_butterflies(f); unscramble(f,N);}

static void fct_noscale(double *f, int length){ if (length != N) initcosarray(length); scramble(f,N); fwd_butterflies(f); bitrev(f,N); fwd_sums(f); f[0] *= invroot2; }

static void ifct_defn_scaling(double *f, int length){ ifct_noscale(f,length);}

static void fct_defn_scaling(double *f, int length){ int i;

fct_noscale(f,length); for(i=0;i<=N-1;i++) f[i] *= two_over_N;}

void ifct(double *f, int length){/* CALL THIS FOR INVERSE 1D DCT DON-MONRO PREFERRED SCALING */ int i;

if (length != N) initcosarray(length); /* BGS patch June 1997 */ for(i=0;i<=N-1;i++) f[i] *= root2_over_rootN; ifct_noscale(f,length);}

void fct(double *f, int length){/* CALL THIS FOR FORWARD 1D DCT DON-MONRO PREFERRED SCALING */ int i;

fct_noscale(f,length); for(i=0;i<=N-1;i++) f[i] *= root2_over_rootN;}

/**************************************************************** 2D FAST DCT SECTION****************************************************************/

#define VERBOSE 0

static double *g = NULL;static double two_over_sqrtncolsnrows = 0.0;static int ncolsvalue = 0;static int nrowsvalue = 0;

static void initfct2d(int nrows, int ncols){ if(VERBOSE) printf("FCT2D -- Initialising for new nrows=%d\n",nrows); if ((nrows<=0)||(ncols<0)){ printf("FCT2D -- ncols=%d or nrows=%d is <=0\n",nrows,ncols); exit(1); } if(g != NULL) free(g); g = (double *)calloc(nrows,sizeof(double)); if(g == NULL){ printf("FCT2D -- Unable to allocate g array\n"); exit(1); }

106

ncolsvalue = ncols; nrowsvalue = nrows; two_over_sqrtncolsnrows = 2.0/sqrt(ncols*1.0*nrows);}

void fct2d(double f[], int nrows, int ncols)/* CALL THIS FOR FORWARD 2d DCT DON-MONRO PREFERRED SCALING */{ int u,v;

if ((ncols!=ncolsvalue)||(nrows!=nrowsvalue)){ initfct2d(nrows,ncols); } for (u=0; u<=nrows-1; u++){ fct_noscale(&f[u*ncols],ncols); } for (v=0; v<=ncols-1; v++){ for (u=0; u<=nrows-1; u++){ g[u] = f[u*ncols+v]; } fct_noscale(g,nrows); for (u=0; u<=nrows-1; u++){ f[u*ncols+v] = g[u]*two_over_sqrtncolsnrows; } }}

void ifct2d(double f[], int nrows, int ncols)/* CALL THIS FOR INVERSE 2d DCT DON-MONRO PREFERRED SCALING */{ int u,v;

if ((ncols!=ncolsvalue)||(nrows!=nrowsvalue)){ initfct2d(nrows,ncols); } for (u=0; u<=nrows-1; u++){ ifct_noscale(&f[u*ncols],ncols); } for (v=0; v<=ncols-1; v++){ for (u=0; u<=nrows-1; u++){ g[u] = f[u*ncols+v]; } ifct_noscale(g,nrows); for (u=0; u<=nrows-1; u++){ f[u*ncols+v] = g[u]*two_over_sqrtncolsnrows; } }}

/***************************************************************** UNCOMMENT THIS SECTION TO TEST 1D FAST DCT *****************************************************************/

int main(int argc, char **argv){ double f[NUMVALS]; int i,done=0; int temp,sizeRead=0,its = 0; int *tmpVal; unsigned char tempChar;

FILE *inFile,*outFile;

if (argc != 3){ printf("Usage: dctd compressed_file decompressed file\n"); exit(1); }

107

tmpVal = (int *)malloc(sizeof(int));

inFile = fopen(argv[1],"rb"); outFile = fopen(argv[2],"wb");

while(1){ for(i=0;i<NUMVALS;i++){ f[i] =0 ; } for(i=0; i < NUMVALS; i++){ if(fread(tmpVal,sizeof(int),1,inFile) == 1){

temp = *tmpVal; sizeRead++; f[i] = (double)temp;

} else{ done = 1; break; }

//load as many vals as possible }

//multiply by quantiitzaiton matixmatrix for(i=0; i < sizeRead; i++){ f[i] = f[i] * (i+1); } its++; //perform DCT ifct(f,NUMVALS);

//printf("Sizeread: %d\n",sizeRead); for(i=0;i < sizeRead; i++){ tempChar = (unsigned char) f[i]; //printf("%c\n",tempChar); fprintf(outFile,"%c",tempChar); } sizeRead = 0; if(done){ fprintf(outFile,"%c",EOF); break; } }

return(0); }

108

Appendix B – Data Sheets

109

Appendix C - References

The Programmable Logic Data Book 1998, Xilinx, Inc., 1997, 4-6 – 4-117.

Luther, Arch C. Principles of Digital Audio and Video, Artech House, Boston. 1997.

Ott, Henry W. Noise Reduction Techniques in Electronic Systems, Wiley & Sons, New York. 1976.

Nelson, Mark and Jean-Loup Gailly, The Data Compression Book, M&T Books. New York, New York. 1996.

Arrow/Zeus Electronics - www.arrowzeus.com (pricing)

Atmel - http://www.atmel.com

Craig Peacock’s Interfacing the PC - http://www.senet.com.au/~cpeacock/

Discrete Cosine Transform http://ikpe1101.ikp.kfajuelich.de/briefbook_data_analysis/node61.html

Fast MDCT Implementation - http://www-ccrma.stanford.edu/~bosse/proj/node28.html

Fast DCT Code - http://dmsun4.bath.ac.uk/dcts/fastct.c

GSM 06.10 lossy speech compression - http://kbs.cs.tu-berlin.de/~jutta/toast.html

The Hardware Book - http://www.sonic.net/~alanwall/hwb/hwb.html

Harris Semiconductor - http://www.semi.harris.com

The IMA ADPCM Compression Algorithm - http://www.wpi.edu/~murti/mqp/2_3_1.html

Maxim Integrated Products - http://www.maxim-ic.com

Microchip Technology - http://www.microchip.com

National Semiconductor - http://www.national.com/

Texas Instruments - http://www.ti.com

Tomi Engdahl's electronics info page - http://www.hut.fi/Misc/Electronics/

Xilinx Home Page - http://www.xilinx.com/

110

Appendix D – Wave File Format

This is information was taken from :

http://www.lightlink.com/tjweber/StripWav/Canon.htmlhttp://www.lightlink.com/tjweber/StripWav/WAVE.html

Introduction

The WAVE file format is a subset of Microsoft's RIFF spec, which can include lots of different kinds of data. It was originally intended for multimedia files, but the spec is open enough to allow pretty much anything to be placed in such a file, and ignored by programs that read the format correctly.

This description is not meant to be exhaustive, but to suggest simple ways of doing common tasks with waveform audio, and give some pointers to other sources of information.

Basics of digital audio and sound

First, some basics. Sound is air pressure fluctuation. Digitized sound is a graph of the change in air pressure over time. That's all there is to it.

For a good picture of this, open up Windows Sound Recorder and record a short sound, then look at the green bars it shows. When they're wide, there's a lot of air pressure, which your ear detects as a loud noise. When they're flat in the middle, there's no change in air pressure, which your ear detects as silence. The faster they go up and down, the higher the sound you hear.

When you record a sound, your microphone changes the air pressure fluctuations into electrical voltage fluctuations, which your sound card measures every so often and changes into numbers, called samples. When you play a sound back, the process is reversed, except that the voltage fluctuations go to your speakers instead of your microphone, and are converted back into air pressure by the speaker cone.

The speed with which your sound card samples the voltage is called the sample rate, and is expressed in kilohertz (kHz). One kHz is a thousand samples per second.

It's important to note that digitized audio stores nothing directly about a sound's frequency, pitch, or perceived loudness. You can run certain algorithms on the samples to determine these values approximately, but you can't just read them from the file.

What is RIFF?

RIFF is a file format for storing many kinds of data, primarily multimedia data like audio and video. It is based on chunks and sub-chunks. Each chunk has a type, represented by a four-character tag. This chunk type comes first in the file, followed by the size of the chunk, then the contents of the chunk.

The entire RIFF file is a big chunk that contains all the other chunks. The first thing in the contents of the RIFF chunk is the "form type," which describes the overall type of the file's contents. So the structure of a RIFF file looks like this:

Offset Contents (hex) 0000 'R', 'I', 'F', 'F' 0004 Length of the entire file - 8 (32-bit unsigned integer) 0008 form type (4 characters) 000B first chunk type (4 character)

111

0010 first chunk length (32-bit unsigned integer) 0014 first chunk's data ... ... All integers are stored in the Intel low-high byte ordering (usually referred to as "little-endian").A more detailed description of the RIFF format can be found in the Microsoft Win32 Multimedia API documentation, which is supplied as a Windows Help file with many Windows programming tools such as C++ compilers.

What is WAVE?

The WAVE format is a subset of RIFF used for storing digital audio. Its form type is "WAVE", and it requires two kinds of chunks:

the fmt chunk, which describes the sample rate, sample width, etc., and the data chunk, which contains the actual samples.

WAVE can also contain any other chunk type allowed by RIFF, including LIST chunks, which are used to contain optional kinds of data such as the copyright date, author's name, etc. Chunks can appear in any order.

The WAVE file is thus very powerful, but also not trivial to parse. For this reason, and also possibly because a simpler (or inaccurate?) description of the WAVE format was promulgated before the Win32 API was released, a lot of older programs read and write a subset of the WAVE format, which I refer to as the "canonical" WAVE format. This subset basically consists of only two chunks, the fmt and data chunks, in that order, with the sample data in PCM format. For a detailed description of what this format looks like, and a description of the contents of the fmt chunk, look here.

What kind of compression is used in WAVE files?

The WAVE specification supports a number of different compression algorithms. The format tag entry in the fmt chunk indicates the type of compression used. A value of 1 indicates Pulse Code Modulation (PCM), which is a "straight," or uncompressed encoding of the samples. Values other than 1 indicate some form of compression. For more information on the values supported and how to decode the samples, see the Microsoft Win32 Multimedia API documentation.

How can I write data to a WAVE file?

The simplest way to write data into WAVE files produced by your own programs is to use the canonical format. This will be compatible with any other program, even the older ones. You can also use my WAVE and RIFF C++ classes for this (see the next section).

How can I read sample data from a WAVE file?

There are four methods you could use to read the sample data from a WAVE file:

1. For the most flexibility, use the mmio* functions in the Win32 API. These allow you to navigate through the various chunks and subchunks in the RIFF file and find the ones you want. You'll also need to parse the fmt chunk to determine the sample rate, sample width, etc. 2. Another option is to only support the canonical format. This is especially useful if your program will be used in a limited environment, and you know the sample format ahead of time. In this case, you can simply read the sample data starting at offset 44 from the beginning of the file. If you want to support newer files and it's not a problem to run them through another program first, you can use my shareware StripWav program. 3. If you're using C++, you can use my classes for reading WAVE and RIFF files. Read the documentation for WAVE and RIFF to see if they'll do what you need; if so, download the source code.

112

4. There are also a number of other packages for dealing with audio around, that work with Delphi, ActiveX, etc. Probably one of them will help keep you from reinventing the wheel.

How can I record and play WAVE files under Windows?If all you want to do is play a WAVE file, use the Win32 function PlaySound(). If you're writing for 16-bit Windows, use sndPlaySound() instead. You can use either of these functions without knowing anything about the internal format of the file.

To give your users a little more control over pausing, stopping, and rewinding longer WAVE files, use the MCI functions or an MCI control provided by your programming language. You can also record audio using MCI.

For more precise control than the MCI functions provide, you'll need to either use the Microsoft Win32 Multimedia API (which should be documented with whatever programming language you're using), or find a commercial or shareware library for your language that does. If you find one you like, please let me know so I can list it here, since I'm often asked for advice on this!

I really need frequency (or pitch) information from the WAVE file. How do I get it?

One way is to use a Fast Fourier Transform. Other ways involve doing things like examining statistical correlations between samples at different offsets, to determine the full wavelength at a given timepoint. It's hairy stuff. I have seen some references here and there; maybe those ideas can help in your search.

113

Appendix E – Log File

Sunday, 5/21:00pm - 6:30pmAaronWorked with John to test big memory chip with Audio system. Worked on updating and finishing the audio circuit schematic for use in documentation. Worked on Audio portion of document. Saturday, 5/16:00pm - 9:00pmJohn, Aaron, and MichelleFinished integrating all of the system modules together in one Xilinx project. Also implemented a control module to allow two separate modules to access memory at different times. Tested the new and improved audio circuit with the 4k3 and then integrated it with the serial stuff on the 4k10 for a complete system. We just need to throw in compression/decompression and serial write to finish up the implementation. Before final test of audio on 4k3, Aaron and Michelle finished getting the DC offset (2.5V) to work. We moved the offset from the input amp to the input inverter (otherwise the offset was -2.5V DC). The quality is understandable at best, but we called it a moral victory for team D/A-A/D. Only minor modifications (if any) will be made to the audio subsystem from here on. 10:00am - 5:00pmJohnWorked on creating a master control module to control all of the reset line to each and every module on the system. It will prevent any dual activity. It is a state machine that records the current status of the system and decides whether or not to allow a requested action to proceed. For example, if the device is playing a press of the record button will be ignored because the record module will be in a reset state. No two modules that access memory will be out of the reset state at the same time. 10:00am - 1:30pmTreyWorked on modifying the application to handle uploads to the device. This proved to be quite a task with a lot of crap in Visual Basic. I got something that I think will work but because it's in a loop waiting for a condition, seems to take up like 100% of the CPU. So not really sure what to do about that. I put this "new" app on osano under gui/upapp because it's possible it won't get implemented in time. Mike, I also set up all the error trapping stuff correctly so you might take a look. This traps cancels and displays messages otherwise.

Friday, 4/303:30pm - 10:00pmJohn and TreyScratched a lot of the stuff done last night with keeping track of where recording to memory stopped. This took up 140 CLBs due to bus sizes and such. Instead implemented a feature such that when the stop button is pressed, memory writes 32 bytes of the character 'h69. The serial module can then detect the end of memory by an end of memory signal if the entire memory is full or 32 consecutive bytes of the stated character. Trey also worked on implementing the writing to memory from the PC. This module is done in the PC but hasn't been implemented in Visual Basic yet. The serial module will write each character received to memory and once 16 bytes are received, the computer will wait for an acknowledgement byte of 'h06 from Xilinx. Xilinx will send this byte once all 16 bytes have been successfully written to memory. When we get to the end of memory the DTR from the Xilinx will be set to signify memory is full. If the PC is not going to fill up memory it will need to send the 'h69 character to signify the end of memory before the PC sets its DTR. 2:30pm-6:30pmAaron and JeffreyWe worked on biasing the microphone input at 2.5 V so we are not clipping the negative voltages. We had a circuit built that worked correctly with the signal generator (used with values we thought appropriate to

114

simulate the mic), but when we hooked up the mic it did not work (no spkr output). Will look at it more tomorrow.

Thursday, 4/297:30pm - 1:30amJohn and TreyWorked on implementing the 'End' feature in the memory and serial modules. This feature will allow us to playback or download only the portion of memory that has been most recently recorded. Currently it is taking up a large number of CLBs. We also worked on a control module for the entire system. This module controls all of the other modules reset lines and prevents multiple things from accessing memory at the same time. 4:00pm-7:00pmAaron, Jeffrey, and MichelleThe professor J and A talked to today said that the mic gives both positive and negative voltages as output, something we had not considered at all. To allow for this, we will need to add a DC offset to the microphone input. Since the LP filters and A/D all work on 0 to 5V, we decided to set the offset at 2.5V. We tested some simple non-inverting and inverting op amp configurations to get a 2.5V DC offset at the output. Using a voltage divider, we got the Vos at pin 3 to be 1.25V, which gave us 2.5V output offset. We will be using this op amp and an inverter to bring it back to original AC signal.

Wednesday, 4/2810:00pm - 5:00amTrey & JohnWorked on getting the serial and memory working again. The modules quite working together in a very strange way. The communication worked perfectly except for some excess data at the beginning of the data file. It was narrowed down to be coming from the memory module, but this same module was behaving correctly under other similar conditions. The combination of the memory module and serial module just caused problems. 10:00pm - 3:30amAaronWorked on the schematics for the Audio system. I am made bitmaps for each component and then placed them in a PowerPoint file. Very tedious but I think it will produce the best results with the tools we have available. All of the audio subsystems are complete except for schematics for the clock system and the microphone jack. 2:30pm - 6:00pmGroup Time for LabA/D and D/A was recorded to memory and played back with the mic today. The circuit had no problems working, but audio playback is still not quite as good as we had hoped. There are two solutions being looked at. One is to correct the values as they come in (limiting the change to no more than 10 (out of 256) to remove any hissing or popping). The second is to improve the amplifier for the mic to improve the range of voltage levels we are getting to the A/D. Jeffrey and Aaron will talk to the professor in the morning about this. One test we need to do when the audio team can get time on the Xilinx is to hook the speaker up to the waveform generator and then put it up to the mic and see what it sounds like. We will do this test at 500 Hz, 1kHz, and 1.5kHz. Aaron and Jeffrey and Michelle worked on the schematics for the Audio system. Aaron will try to finish them tonight before the morning meeting with the EE Prof. Trey and John worked on getting serial and memory stuff working again. 9:30 (Aaron not until 10 of course) - 11:15Aaron and JohnJohn and Aaron met this morning to test recording and playback of audio. We hooked up the function generator as input and varied the frequency as we were recording. The playback sounded pretty damn good compared to what we have been getting. We then went to try the mic, but the power lead that was melted on somehow got broken off, so we couldn't test that portion. Will attempt to do that this afternoon in lab. Aaron has not yet started the circuit schematic, but will also do that this afternoon. It needs to be complete before Aaron and Jeffrey visit that professor tomorrow morning.

115

Tuesday, 4/273:00 - 8:00pmTreyFinally got a very reliable serial state machine. And it works great with the memory module so thus we have great communication going on. I tried it at 115200 and no problems at all. The problem in the state machine was the inputs needed to be latched. Meaning that there would then be no way they could change while making comparisons in the case statement of the current state. 2:00 - 8:00pmAaron, Jeffrey, and MichelleFinally got audio all the way through the system using both input and output filters! The audio is much cleaner (less noise) than before, but still not quite telephone quality. John and Aaron will meet tomorrow morning to hook the Audio up to the Xilinx and work more on Play/Record features. The Audio circuit is almost to a 'hardware freeze' state. Aaron and Jeffrey will talk to one more professor Thursday morning to get some more input about the audio system. Aaron will also start a schematic of what the entire circuit looks like (probably a combination of PowerPoint and a circuit editor like pspice).

Monday, 4/262:45- 7:40pm (lab time) and 10:00pm - 3:30amTrey & JohnWorked a lot on the serial state machine trying to get it stable. Not much really seemed to work but have definitely decided the way it was being implemented was dangerous. 2:00pm- 7:00pm (lab time) and 9:30pm - 2:30amAaron and Jeffrey and Michelle (at diff times)We worked more on getting the output amp to respond correctly. It is still distorting. It does appear that the output filter is 'smoothing' out the output waveform, so hopefully audio quality has improved. After talking to Scott, we will go back to using the 386 by itself as an amplifier. The two-stage radio shack amp will be removed in favor of the 386 circuit form the printed schematic. Aaron will try and get up in the morning and come up and do that before we meet at 3:35. Once that is done, we will then try the mic all the way through the circuit for the first time since we got the output filter to work correctly. Hopefully, that will produce better results. One odd thing AK and JW noticed tonight was that the output filter has a gain of 1/4. We are not sure why; the input filter has a gain of 1. Anyway, after Jeffrey left, Aaron and John hooked the Xilinx up to the A/D and gave the A/D a triangle wave as input. This wave was read into memory, and then the memory contents were put into an Excel spreadsheet for analysis. The wave was not reproduced very accurately in memory. John and Aaron are still trying to determine if the problem lies with memory sampling or with A/D sampling. We will talk to Scott more tomorrow afternoon. Overall, I think we have a much better understanding of what is happening at each stage.

Sunday, 4/2510:00pm - 2:00amJohn, Aaron, Trey, and JeffreyJeffrey and Aaron worked more on D/A - A/D. Input filter is hooked up and seems to help the audio quality a little. We are still working on getting the output filter to work correctly. We sent out an increasing (0 to 255 repeating) 'wave' from the Xilinx to the D/A to test it some to see if we can figure out if the waveform distortion is happening on the D/A or the A/D. Though it appears the amplifier is amplifying too much (the signal is clipping when the volume is adjusted too high), the D/A gave a very nice output that matched the increasing wave John put into memory. This leads to some interesting thoughts. Is the A/D not 'good' enough? What is it that is not 'good'? Should we remove the second stage of the amplifier (the 386) and just stick with the first stage (the 741) to reduce the gain? Also, the output filter is still not working. It completely kills the signal from the amp. Trey and I will be going to mid-state in the morning to get a -5V regulator; we will check into other A/Ds at that time. Trey and John continued to rework the serial and memory modules. Full testing using the hardware debugger was performed on the memory module for a write sequence. John will do a read run through tomorrow. Trey worked on making the serial more robust. 1:00 - 7:30pmPretty much everybodyThe individual parts are slowly but surely coming along. Serial and memory and dangerously close to coming together. We had something that seemed to work fine at 9600 baud but when moved up everything

116

crashed. Now 9600 doesn't work. John and Trey aren't really sure where the problem lies but it should turn up. BTW, the application didn't really have much of anything to do with those problems. The D/A A/D stuff is slowly but surely coming along. We got the filters to corner correctly (using an external clock), and moved the filter circuit and clock to a separate breadboard. We tried to integrate output and input filters but got no sound out whatsoever. The app does everything it's supposed to do. Plays, converts, and attempts to download correctly.

Saturday, 4/245:30 - 7:30pmJohn and MikeIt turned out that the biggest problem was the application. Mike brought a new version to the lab and now everything seems to work. We can transfer the entire contents of the memory chip over to a binary file on the PC via the serial port. On and off during the day Mike worked on fixing up PDACS to the final version. Most previous bugs in it are now fixed. It will play both a .wav and a raw soundfile on a computer with a soundcard. 12 noon - 3:00pmAaron, Jeffrey and MichelleWe worked (unsuccessfully) on getting the IC filters to work correctly (corner at 3kHz). Will try again tomorrow morning. The output and input filters are exactly the same, so we don't anticipate much trouble with integration once we get the filters working correctly. 11:00am - 4:30pmTrey and JohnWorked on further integrating the memory and serial modules. It appears that some of the data is getting transferred before it crashes. We are having problems figuring out if the problem is serial, memory, or the application. 8:15 - 9:45amMichelleWorked on the filter circuit. I built a 300kHz clock, the output comes from the 74LS93 chip pin 11. It's approximately 300kHz. I tried hooking up the circuit Jeffrey marked in the data sheet on page 8-14, but am having problems with noise for some reason (the signal is all distorted). When I turn on the power, the input signal gets really ugly for some reason that I can't figure out. The circuit looks really ugly now 'cause we didn't have a lot of resistors I needed, so I had to make resistances with resistors in series. Right now it's hooked up with R = 1 Ohm approximately (3 39 Ohm resistors in series). This requires two 1 microfarad caps, and I don't know what's in there right now. I also didn't have a 10 microfarad tantalum cap, or if we do I don't know which one it is.

Friday, 4/2311:00pm - 2:30amTrey initially then John tooGot serial portion alone working fine in the 4010. Had to make a few modifications to the state machine to make it more robust. Changed the app around a bit too. Then we integrated everything and it worked. It will read data for a while but then BAM, it stops. Usually it sends the memend or the serial module interprets a memend, we aren't quite sure. Hardware debugging will have to commence tomorrow. 4:30 - 7:30pmTrey & JohnWorked on integration with serial and memory after getting everything going on the 4003. When we got a 4010 nothing worked. We were worried bad things may have happened but we postponed more testing till later. One thing though, voltages being output by the Xilinx were quite the 0V for a 0 and 5V for a 1. They are more around 0.1 V for a 0 and 4.03 V for a 1. 3:00pm - 7:00pmAaron and Michelle We worked for several hours trying to get the filters to actually do something.. We built several of the example circuits in the book trying to use the internal clock. None of them worked. One last circuit we tried used an external clock -- it had promising but not correct results. Will try more tomorrow. 10:00am - 1:00pm

117

JohnInvestigated the idea of running an 8 to 6 companding algorithm before our DCT algorithm. This might make the DCT small enough to fit in a 4k10 with everything else. I will try to finish this idea up this afternoon.

Thursday, 4/2211:00pm - 2:15amTreyA tentative success is expressed by Trey. Ok, I think this all works. OVERVIEW of serial module: comes on and checks if DTR from computer is asserted. If it isn't then the module waits until it is this signal is asserted. Next, the module sits and receives characters. Right now, if any character other than an "a" is sent nothing happens, just a blinking LED. When an "a" is received the module starts dumping data to the PC. It continues doing this until the MEMEND signal is asserted. When it does, the module stops sending data, sets its own DTR active, waits for 68ms, and sets it DTR inactive. If at anytime during any of this the computer's DTR goes inactive, the module is totally reset because this means the cable was unplugged or the program on the PC turned off. Tomorrow, work will commence on working with the actual application and most importantly interfacing with memory. 12noon - 2:00pmAaronI scoured the net for filters that might work as anti-aliasing input/output filters. One site had awesome 9th order filters -- but I called them and they cost $50 a piece. I finally ended up ordering some 5th order 8-pin DIP ICs from Digikey. They will be Friday morning. 10:30am ~ 2:00pmTreyRewired part of the serial part to not use the interrupt line at all. Now I am directly tying to the *DSR pin coming from the serial port. This seems to work fine but I'm still having trouble with the state machine going off in the weeds. I talked to A. Fikes about the problem because I'd heard they had had the same problems. Anyway, he gave me a few possibilities that I'll try tonight.

Wednesday, 4/2111:00pm - 3:00amTrey & JohnExpected things to be working fine with the serial stuff but have started having, or possibly just finding, some problems with the implementation. It appears that interrupts are being generated by the UART at different times than I expect. So, tomorrow the INTR will not be used anymore and I'll wire directly to the DSR. 10:00pm - 3:OOam AaronI worked on getting the input amp to work correctly until about 1. It seems to work ok, but produced only slightly better audio output. I then read through the books we picked up at the library on audio and noise filtering. One thing has become apparent -- we definitely need input and output filters (a.k.a. 'Anti-Aliasing and Aliasing' filters). The corner of these filters would normally be 4kHZ (Nyquist), but we will need to oversample (Shannon -- 'Nyquist was an optimist'), so a corner of 3kHz will work quite nicely. However, the books also stated that aliasing filters needed to have sharp rolloff at the corner. This means they are very complicated circuits -- a simple 1st order active filter won't cut it. So, I am looking into some ICs online to see if we can find something that will work. I will try to get them ordered tomorrow. 3:00 - 5:30pmGroup Meeting in ClassGetting things to work together... Trey was still working on serial stuff trying to get a few new random things from occurring. Mike was working on the application ensuring everything was working correctly and making an icon for the group. John was helping everybody while still working a bit on DCT with Mike. Jeffrey was hooking up some amplifier circuit for the D/A A/D team and getting a new pot to work. Aaron and Michelle went to the library and talking to professors to research Audio stuff.

Tuesday, 4/209:00pm - 3:00am

118

JohnWorked more on implementing DCT in Verilog. It is getting there, but is quite large. Sooner or latter we need to look at a full dump of speech that was recorded into memory. This will help with DCT... 1:00pm - 2:00pm, 12 midnight - 2:30amTreyGot reliable serial communication both ways. Am now working on fully functioning communication between PC and Xilinx using control lines to signify end of data and such.

Monday, 4/198:00 - 10:00pm, 12 midnight - 3:30amTrey & John Got serial stuff going but still haven't gotten to interface with memory yet because of timing problems of a sort. The state machine is going into the weeds and picking state 29. So, even though this state wasn't there, off it went. We added a state 29 and it still went there. This happens at high speeds but can't be simulated at lower speeds. Will finish this up tomorrow hopefully so we can interface with memory. 10:00pm - 12:00 midnightJeffrey and JohnWe worked on polishing the interface with the A/D and D/A systems. Using the function generator, we can do a pretty good job of storing an playing back. We have not tried to use speech yet. 3:00 - 6:00pmGroup Meeting in ClassWorked on everything.

Sunday, 4/182:00 - 7:30pmTreyTrying to get reliable serial communication going between Xilinx and PC. Having a few timing problems but should get them leveled out here shortly.

Saturday, 4/173:00 - 5:00pmMikeWorked on debugging and finalizing the GUI. Pretty much done now.

Thursday, 4/158:00 - ?John, Michelle, and Aaron brieflyReplaced the blown op amp with a new one and started testing the memory interface with the A/D again. Figured out that for some unknown reason, the Xilinx wasn't picking up the data on the pins we had connected to the A/D. So we switched the A/D and D/A pins connected to the Xilinx, and we'll see what happens from there.

Wednesday, 4/149:00 - 11:00pmAaron, John, and MichelleWe worked on getting the memory to read data from the A/D chip. For some reason, we could read data from the A/D chip, but could read from the switch network John had set up to test the memory. Then Aaron blew an op amp, so we had to quit until Thursday night. 3:00 - 6:00pmGroup Meeting in ClassAaron and John worked again on trying to get D/A out of the memory to the speaker without getting any results. Right now, it seems that the digital output is not getting sent to the output pins correctly. Will work on it again tonight. Aaron and Michelle wired up the other input circuit (from the Xtend board diagram). It is basically an input filter between the mic and the A/D. It did clean up the output some (as seen on the Oscope), but the sound quality improved only slightly. We will be removing the old audio amplifier (from

119

the Radio Shack book) and using the one wired up last night that was used in the Xtend board. Basically, both the new input and output parts need to be made to look nice. Mike and Jeffrey finished biweekly 3. Michelle edited the audio portion of it. Trey worked on building a module to interface with the Application. It seems to be coming along but he's not sure what clock should be used to run the state machine. Random results occur when the clock is too fast. It doesn't seem like the application is sending data out the serial port like I would like either. Trey will work with Mike on this problem later. 11:30am - 1:00pmJeffreyJeffrey worked more on cleaning up biweekly 3.

Tuesday, 4/1310:00pm ~ 4:00amTreyWorked with Scott on some serial stuff for use in one of his projects. Worked on making a module that interfaces with the PC. Will take into account DTR on computer for connection and breakup and will need to receive a certain character before an actual transmission can occur. Will finish and test that tomorrow. 9:00pm - 3:30amAaron (gone from 11:30 to 1:30am) and JohnWe worked on interfacing the A/D and D/A chips with the Xilinx chip. The A/D is sampling at 8Khz quite well, though we can't tell for sure if it is sampling the 'correct' data, for instance from a random input like voice. It worked well with constant input, varying input from the pot, and varying input from the function generator. The D/A is almost working. We might be able to do some playback tomorrow during lab time. John worked on all of the Verilog for this. Aaron worked in improving the input/output circuits to improve quality. A new output amplifier, consisting of a single stage LM386 is now being used. It seems to provide better quality. Next, a filter will be put on the input to (hopefully) clean it up. Once we can store and retrieve the audio from memory, we will have a better idea where any other distortion is occurring. 10:30am - 2:15pmTreyGot the board tested and such and it works great! All the pretty LEDS work and everything. I wrote a little state diagram that will receive a character from the PC and echo it right back out. Pretty neat. Tonight Scott wants me to help him incorporate the serial part in one of his projects so.... Will work on the PC - serial communications module tonight and possibly reading from memory. 10:30am - 11:30am, 4:00pm - 5:30pmJeffreyI did a little cleanup work on bi-weekly 3. I have not yet reached the compression section, or our final thoughts. All we have to do tomorrow in class is to slap a few diagrams in place, and print it out. I would still appreciate it if everyone read through their respective sections, and make sure that everything is accurate. Feel free to make any changes, after all, this is our child...

Monday, 4/126:00pm - 7:30pmTreyFinished up the wire-wrapping of the serial board and hope to test it tomorrow. 6:00pm - 7:30pmAaron and JohnAaron hooked the Audio circuit up to the bus that John built from the Xilinx to the audio board. GND for the audio board was wired from the bus and also from the power supply itself (Scott's recommendation -- avoid a long GND path). 5V was wired from the bus. The op amps were powered using 10V and -10V direct from the power supply. John worked on a test circuit to test is we could pull data from the A/D chip. 3:00pm - 6:00pmGroup Meeting for ClassAaron and Michelle decided Audio System was ready to hook up to Xilinx. We will continue to work on improving the audio quality, but it may not get better than this. Aaron and Jeffrey plotted the bandwidth of the amplification system so that we would have something nice to put in our biweekly report (plus, Mahapatra insisted). John worked on wiring the connections for the Audio system to the Xilinx. We will be leaving the Audio on a breadboard and connecting it to the protoboard via a ribbon cable. Michelle checked

120

into how we would power the Audio system, which will require 0V (GND), 5V, 15V and -15V. We will use 5V and GND from the Xilinx protoboard and get 15/-15 from the big black power supply. The audio should be hook to the Xilinx by the end of class today.Mike and Jeffrey worked on translating the log file into something to be inserted into our biweekly report.Trey worked on wire wrapping the serial port circuit.

Sunday, 4/119:30pm - 3:00amTreyGot receiving to work on the UART side so now have full 2-way communication between the PC and the UART. Scott was pretty excited about this and wanted me to go ahead and wire wrap my stuff up. So, I got all the components together and will even have some cool LEDs. I got about half of it wire-wrapped tonight but it's taking quite a while. Will get the rest done hopefully tomorrow. 6:00 - 6:50pm, 7:40 - 8:50pmMikeI got the binary file receive part of the GUI fixed. I tested it and it works. I also developed a small application for Trey that will allow him to send data to the serial port. It is in my Nordfelt directory under xmitapp. I don't know if it works, but it should. 3:00 - 6:30pmTreyGot transfer from Xilinx to PC to work. I can send individual bytes input by the user and send multiple bytes in a loop. Pretty neat. Worked on a few timing problems with the Xilinx module being a bit too quick but shouldn't be a problem. Tonight I'll get receiving a byte going and hopefully get the skeleton full transfer going on. 1:30 - 3:00pmMike, Trey, Aaron, John, and MichelleDiscussed where we are, and where we need to go with regard to the project. We also developed an updated set of priorities for different systems in PDACS.

Saturday, 4/101:00 - 7:00pmJohnWorked on implementing DCT in Verilog. I think the DCT is almost complete. The only thing that needs to be done before it can really be tested is creating a module to handle the addition of our numbers. 10:00-11:30amAaron and JefferySemi good news. Jeffery and I did improve the sound quality of the audio output, though only somewhat. Most of the time it is at least understandable, although still very noisy and picking up breathing way too much. The funny thing is how we improved it. The microphone has 3 inputs: GND, its Output to the A/D, and 5V power. The 5V pin was accidentally disconnected, and the sound improved. Very strange. We can't explain that. It is possible we did not correctly implement the pinout on the microphone jack. Michelle and Mike wired it up first (correctly), but it became disconnected this week and Jeffery and Aaron had trouble getting it back together. We haven't been able to talk to Scott the past several trips in here, so we'll try again tomorrow afternoon to see if he has any more ideas.

Friday, 4/93:45pm - 4:45 pmJeffreyWell, I came in here on Friday afternoon to try and test the output at each stage of the audio device. I found that the input and output waveforms were pretty consistent up until around the end. My guess is that the final capacitor or the load from the speaker is distorting the output. But that is purely hypothetical. I eventually break a lead on the speaker, so I left hastily.

Thursday 4/811:30am - 1:00pm

121

TreyGood news... I have implemented the state machine in a straightforward edge-triggered way in Verilog. Everything is working as expected. I have a very simple program now that will switch the DTR on when a button is pressed and turn it off when the button is pressed again. I actually ran into problems with the button being on too long when I made the clock to the state machine higher. They're both running at 15Hz now. 10:00am - 12:30pmAaron and JeffreyAaron and Jeffrey came in this morning to finish reconnecting the entire A/D - D/A circuit, since we finally got the A/D working again yesterday. We did this with very little difficulty, but found that the audio quality coming out of the speaker was poor at best, for we could only produce static and a few odd words. By examining sample waveforms we found that the waveform was being inverted in the amplifier circuit. We built an amplifier to correct this problem, but there was little improvement in sound quality. We plan on showing our results to Scott, and going from there.

Wednesday 4/710:00pm - 3:00amTrey & John for a bitIt truly amazes me how messed up stuff can be. I can make a state diagram that sets the DTR active no problem, but when I add 1 empty state right after performing this task, BAMM, it quits working. Well, needless to say I know that I can communicate with the UART and affect control lines. The problem is with the state diagram. I'm thinking seriously of writing the whole thing in Verilog from here on out. We also ran into with a problem with the switches. When two of them would be active, all four outputs would become active. We finally figured out that the 10k resistor bridge we had in there was to small and replaced it with a 20k. They work find now. We wired up the last four buttons to pads 29, 5, 6, 7. 3:00 - 6:00pmGroup Meeting in ClassThe secret DCT project may happen. Mike successfully implemented a floating point multiply module in Verilog for the Xilinx chip. From this we can begin the development of DCT. For anyone that doesn't know, Scott doesn't really want us working on DCT because "it will take up way too much time." So, it's become a goal to get it done. :) Aaron et al got the A/D chip back working again. The problem spawned from a missing switch that "starts" the chip. Trey et al figured more out on the state machine. He can read from registers on the UART and even wrote to and read from the scratch register. Tonight the actual setup and hopeful transmission of data through the UART will occur.

Tuesday 4/69:30pm - 2:00amTrey & JohnWorked on getting serial module to work and tried narrowing down problems within the state diagram. Finally found that the top button was staying a '1' for some reason the first run through. We could not verify this using any other test cases. So, I just won't hook up my send to P23. BTW, it is much better to work on Xilinx stuff in two's. John helped a lot. 10:00 - 11:15pmJeffreyWith the memory now complete, I have been group hopping. I spent the majority of this evening catching up to speed with the D/A - A/D people, for it appears they need all the help they can get. After Aaron and Michelle left, I hooked up the old A/D chip and found we were getting absolutely no output on that chip either. So now it appears there is another logic error in the A/D circuit. We will look at it again tomorrow. 9:00 - 10:45pmAaron and MichelleWe hooked up the microphone directly to the amplifier circuit to test the volume of the circuit, and it was fine. Then we hooked up the entire circuit, and it worked for a minute, but then something happened to the A/D chip. It started overheating and then we got no output from it. We can't figure out why the chip isn't working. We've switched out ADC0804's, and the new one is doing the same thing, so something else is wrong with the circuit. We'll test more tomorrow. 8:40 - 10:40pm

122

MikeWorked with John on implementing a floating point by integer multiply Xilinx for working on DCT. Nothing yet, maybe tomorrow. 7:40 - 8:40pmMikeI worked on the GUI a little. I think its almost complete, except for the downloading part, that’s even patched up a bit. I'm testing the multimedia at home and then scouring the web for data on the MSComm class.

Monday, 4/53:00pm - 6:00pmGroup Meeting in ClassWe got a cool microphone that has a built in audio amplifier. Combined with the jack we are now effectively producing input voltages in the range from 0 to almost 5 V. Sadly though voice reproduction is terrible, at best. More work needs to be done on the A/D/A system to make it fully operational. Trey worked on the serial module attempting to create a test module that will strictly write a byte to a scratch register on the UART and read back from it. This will verify that he in fact can establish communication with the device. If this works correctly tomorrow he will attempt to move towards transmitting a byte to the PC. John continued investigations into the DCT compression algorithm. It looks possible.

Friday, 4/23:00 - 7:00pmJohnThe memory control module seems to be working fine. I implemented both a counter up through memory, and a counter down through memory. Both were read just fine and in order. I also dumped a bit pattern into the chip and in also 'read out' fine. The only thing I can not test in the transition from write to read and vice versa. This is because I can not fit both the read and write TEST modules on the chip at the same time with the memory control module. The memory control module will definitely fit on the chip with room to spare. Once serial is further along, we can get a 4010E and have plenty of CLBs to play with. 2:30 - 4:30pmMichelleWorked more on the noise in the circuit. First I moved the amplifier circuit to a separate breadboard and we still had noise. Then Scott noticed that we had the bypass cap hooked up wrong, and viola, the noise disappeared. I can now put an input signal into the A/D and hear it out of the speaker, noise free, or at least there's no noise when there's no input signal. But now of course the mic is not working, and I'm not sure why. I thought it was working yesterday, but now that I think about it I'm not completely sure it was. I'll try getting another one from Scott as I am sure it's hooked up correctly. 8:45 - 10:00amMichelle and AaronWe tested the circuit more to isolate which part was most sensitive to noise from the power supply. First we isolated the D/A half, and the noise was still there. Then we isolated just the amplifier, and the noise pretty much disappeared, but so did the sound output, so we're not sure what's going on there.

Thursday, 4/17:00-8:30pm MikeWorked on getting the application to receive binary data and dump it correctly to a file. No luck, maybe tomorrow.

6:00pm - 3:30amTreyTried and failed to get the serial stuff going. Even got Scott to look at some stuff and just had some really random things going on with the state machine and such. 8:30pm - 1:30am

123

JohnFixed the test module to properly use the memory control module. We can now stream into memory. On Friday I will finish up the read test module so we can provide a better demo. Hopefully by Monday I will have a write up on interfacing with the memory control module. 10:00 - 11:30pmMichelleWorked on the circuit again. Showed Scott how noisy the circuit is right now using the o-scope; he thought it was ok until we hooked up the mic and still got random noise. The plan for tomorrow is to isolate the D/A half of the circuit to find out which stage is most sensitive to the noise from the power supply. We'll do this by disconnecting the data lines between A/D and D/A, and connecting the input pins of the D/A to Vcc and listening to the output. If it's still noisy, we'll isolate the amplifier circuit next. 11:30am ~ 2:00pmTreyMessed around with stuff and I think my main problem was in specifying the baud divisor within the UART. Once I wrote that correctly data was sent over. I'm not sure if the correct data was sent because I ran into problems with the app. Trying to resolve that issue so I can then try signals. 11:30am - 2:00pmAaron and MichelleHaven't seen Scott yet today; Talked to Rabi instead and got the info I needed about the pot. Rabi seems very optimistic that the amplifier circuit we are building will work. Michelle and I hooked it all up, and then added the speaker. It was LOUD. Anyway, we will spend some more time looking at the output on the O-scope to see if everything is working correctly, but I think we are very close to wire wrapping and being through with audio. Aaron also worked on hooking up the mic. I have it hooked up but it is not working (no voltage change on the output). Michelle will look more at that tonight, and we will both be at the lab Friday morning. 9:00am - 10:30amAaronWorked on hooking up the audio amplifier circuit in the Radio Shack book. It is nearly ready for testing; I have some questions about how a pot is hooked up in the diagram. I will wait until I converse with Scott about this given my propensity for frying things.

Wednesday, 3/3110:30pm - 2:00amTrey and JohnTrey finished up building the circuit for the serial module, checked it, and checked it, and turned it on. I could tell that I was getting through the state diagram but nothing was happening on the app side. Like I was not sending any data out. John got his memory stuff going maybe. Can write single byes but is still having trouble with streaming stuff in. Possible problems with buffering. 3:00pm - 5:00pmGroup Meeting in ClassOnce again, the individual teams spent the day diligently toiling away at their problems. Mike put the finishing touches on the GUI, for now the user can close the application after a sound file is played. All he has to do now is test the application on a computer with a sound card. Aaron and Michele continued trying to find an op amp that would produce enough current to drive our speaker. After frying another op amp, Aaron and Michele decided to head to Radio Shack to find an op amp that would work, since the Physics Room. Trey began wiring up the Max232 and 16550 on a breadboard for testing. The state diagrams behaved as expected in simulation, but now a rigorous hardware test is in order. After that, Trey will begin wire wrapping the serial components, and integration is imminent. John and Jeffrey experimented around a little more testing the write to memory command. After sporadic results, it was decided that the write module probably works, although our test module is faulty. They plan to devise another write testing scheme and compare their results. That's our story for March 31, 1999.

Tuesday, 3/3010:30pm - 3:15amTreyFinished up the state diagrams for testing purposes. These will allow us to send a byte from our board and

124

hopefully see it on the PC and receive a byte from the PC and view at least a nibble of it on the LED thing. Actually, I just thought of possibly hitting a button which will allow you to just to viewing the second nibble. Also drew up all the schematics for the circuits so am ready to go. Tomorrow I will go ahead and wire everything up so we can get this going. 11:00am - 1:00pmTreyGot parts finally to hook everything up for the serial module. Caps, sockets, chips, and all that. Started redoing the state diagrams to aid in testing and will make development of a UART-Xilinx lab really easy. Finished the one to do straight writing to the serial port using input from input dips, a button to send, and a button to quit. Will work later on the receiver module and drawing up the circuitry around to test on.

Monday, 3/299:00pm - 1:00amTreyTalked to Scott and decided to write separate state diagrams to test just transmitting and just receiving with the UART. Then I'll write a wrapper that takes into account the memory. I started messing around with that and will also get some hardware stuff done tomorrow. I wire-wrapped the plug from the main Xilinx board that will go to the serial module. 8:30 - 10:30pmJohnI may have found the problem with the memory testing. The clock we were using to debounce the buttons was too high and was causing multiple triggers. We can implement the fix for this Tuesday night and MAYBE have memory wrapped up by Wednesday or Thursday. 8:15 - 9:45pmMichelle and AaronWorked more on the D/A circuit, trying out different op amps to get more current to drive the speaker. I screwed something up in class today, so we were trying to fix that. It ended up being that a fuse was blown in the multimeter. 2:00 - 5:30pmJohn and JeffreyWe continued to work on testing the memory. Inventing a test method is more difficult that writing the memory. We believe we have the write and read tested to some decent level. There are still some occasional problems that might be related to the buttons not reading the press every time... 3:00 - 5:00pmGroup Meeting in ClassEverybody pretty much worked on their own thing. John and Jeffrey's memory stuff is listed above, Mike worked on some wave stuff on the application, Michelle worked on amplifying the current, and Trey worked on getting parts for the serial module and modifying the state diagram.

Sunday, 3/282:00pm - 4:15pmMichelleI worked on the current problem with our D/A circuit. I measured the current at different frequencies for the DAC0830 and the new TI chip and graphed them. I also determined how much current the speaker requires (45mA). Right now the most we're getting out of the TI chip is 25mA. The good news is that you can vary this output current using different op amps at the output of the D/A chip, the bad news is that the best op amp we have only outputs about 27mA. So Aaron is going to Radio shack tomorrow before class to get another op amp to try out, and Scott is getting us more from physics. So we'll see if we can find a higher powered op amp. The other bad news is that this still does not solve our problem of the output getting cut off around 4.5 KHz. I plan on working on this in class Monday.

Saturday, 3/2712:30am - 1:30pmMikeWorked on the GUI a little bit more patching things up. The "Play" menu item is now enabled and should

125

work fine, but can't test on these machines. If it does work all that needs to be done with the GUI is the decompression and help file.

Friday, 3/262:30-6:30pmTreyFinished up the state diagram for the initial version of the serial control module and included support for making sure other devices aren't reading the memory through two inputs. Talked to Scott about getting parts and I need to write up some stuff on the voltages and currents on the lines going to the Xilinx chip demonstrating that I won't blow anything and also show the schematic of how I plan on connecting the different chips together, which is already done. I also need to construct several test cases that I'll go through to see if things work. 1:00-5:30pmJohnWorked on schematic and Verilog to run a complete test on the memory module. Hopefully within the next day or so we well be able to graphically show both writing and reading from memory. Once the memory is fully tested, I will write a small writeup on how to interface with it. 12:15-5:00pmMikeWorked with the GUI. I have fixed the writing to binary file problem we had been having with our received data. I have also implemented a routine to convert our raw received files into .wav files so that the windows sound player can play them back. I have yet to test the results though. Tested and it worked beautifully!!!

Thursday, 3/253:30pm - ???AaronI am still trying to figure out why we can't drive the spkr with the TLC7542. I hooked the DAC0830 back up on a separate circuit and checked its current output. It was about 15 to 17 mA, just like the TLC7542. This is very strange. Maybe current is not the problem. I will talk to Scott and see what's up. 9:30am - 12noonAaronI worked on the last problem (we hope) with the D/A-A/D: trying to get enough current out of the circuit to drive the speaker. Currently, we are getting about 15 to 17 mA (depending on resistors used in the unity gain inverter). I tried changing resistor values, but it only went up to 17mA (with 10k). I also tried moving Vref up to 10V (from 5V), since Vout = Vref (Digital Value / 256). I was thinking that we could then have a half-gain inverter, still get 0 to 5V output, but have more current, but it did not work. The output from the TLC7542 was not linear with Vref at 10V. In fact, it was down right screwy. I'll look into this some more... After that, the thing left for the A/D&D/A is to wire wrap the circuit and write the Xilinx modules.

Wednesday, 3/248:30pm - 1:30amTreyWorked on implementing the State Diagram for the serial control module. I've ended up with about 35 states due to the fact each signal needs held for a clock cycle. I had trouble getting bi-directional variables to work too. I ended up changing our Data lines to just outputs but they'll be needed as inputs eventually. There is possibly room for shrinking of the state diagram but it looks good to me now and I haven't had Scott take a look at it yet. One thing I would like to try to implement is a way to jump to a "Interrupt Handler" state if the INTR line goes high no matter what state I'm in. That'll make things more robust and will hopefully follow soon. 10:00-11:00 MikeStudied the file format for a .wav file so we can eventually convert our raw sound files into .wav files. 2:50 - 5:45pmGroup Meeting for Class and PresentationWe made slides and printed out the report and all gave an excellent presentation. Things went well. 11:30am - 1:00pm

126

John and JeffreyWrote a small Verilog module to test the read ability of the memory control module. When the Reset* pin on the memory chip is sent low, the memory array is filled with ones. Therefore we can test the read by reading these ones. The DataOut lines are initialized to zero, so the ones should be coming from the main memory.

Tuesday, 3/238:30pm - 2:15amTrey and MikeWe were finishing up the document and writing background information on serial communications. RS-232, UART, and MAX232 were all main topics discussed in the report. We also drew up a state diagram that will be used for our initial version of the serial protocol. This will have around 15 states and will basically just dump bytes to the PC. Future implementations will have full two-way communications as well as error detection so the PC will be able to request services. 6:00 - 11:00pmJohn and JeffreyFinished wiring up the interface components. The two buttons are connected to pins 23(top) and 24(bottom). We also connected the memory chip and the clock. Pins 45 - 49 are connected to memory and pin 13 is connected to the clock output. 7:00-8:30pmGroup MeetingWe all met to work on the report and presentation. Each subgroup worked on individual portions as well as common information in the documents. 10:00am-12:00 noonAaronI updated the midterm.ppt to reflect the new accomplishments for team D/A-A/D. I also tried lowering resistor values to get a higher current output for the speaker. It did not work. 9:00am-1:00pmJeffreyI took some time here to bring our midterm paper up to speed. I slapped in a couple of diagrams, and wrote some more stuff on memory accomplishments. I basically just filled in the gaps that Dr. Mahapatra's email created. Other than that, I just geared up for the presentation in general.

Monday, 3/2210:00-12:00 midnightAaron and MichelleWe finished the D/A and A/D for the midterm report. If any one wants to check over what we wrote, it is in the Aaron directory on osano under addamid.doc. 9:00-12:00 midnightJeffrey and JohnWe ran a couple of tests on the LEDs and then setup the switches. The first five switches are connected to pins 25 - 29. The last three switches are reserved for connecting to M0, M1, and M2 later if we need to. ~2:30-6:00pmGroup Meeting in ClassAaron and Michelle hooked up a test circuit for the TI DAC and it worked just fine. The output was linear over the required range. We then hooked up the Harris ADC804 outputs to the TI TLC7254 inputs and gave it a sine wave as input. The DAC output the same sine wave up to about 6kHz, where the output started 'jumping.' Also, the current output was not enough to drive the speaker. We are working on ways to solve both of these problems. The A/D and D/A portion of the report is nearly finished, except for the part about what we did in class today. That will be finished tonight. I'm glad we finally got this working; the irony is that we could have been done many weeks ago if we had started with this TI DAC. Its setup is extremely simple. Jeffrey and John assigned pins on the Xilinx chip to the various subsystems after researching the functionality of each pin. Memory will use five pins, AD and DA are currently allocated 16 pins, the 16550 is allocated 19 pins, and the rest are used for user interface stuff. The 8 segment LED is now connected to the Xilinx chip by pins 35-41 and 44. Trey and Mike worked on changing designs of

127

serial communications to accommodate both transmitting and receiving. This will allow for a more robust communication platform with much more functionality. We also looked at old projects in search of a state diagram to use with the UART but the old stuff implements a very basic design for a 6850 UART. Ours will need much more functionality and will be more complex because it is using a 16550 UART. Slide preparation for the presentation and our part of the report were also major concentrations today.

Sunday, 3/216:00 - 10:00pmJohn, Jeffrey, and TreyWired wrapped the Xilinx module for power, ground, and the Xchecker. We also downloaded a test project to the wire wrapped Xilinx chip. This should be the only time we have to wire up the Xilinx module. 2:00-5:30pmGroup MeetingStarted looking at presentation materials and individual groups finished up slides for each subsection. Michelle went home to start working on the D/A & A/D portion of the report for the midterm. Aaron worked on getting a new TI D/A chip, TLC7524 working that Trey acquired and it worked great. The output was 0 to -5 V. Aaron is in the process of incorporating the A/D chip with it. Mike also brought two other Motorola D/A chips that we will try if the TI chip doesn't end up working out. John and Jeffrey started working on getting a board wire-wrapped with the Xilinx module, memory, and testing equipment (buttons & LEDs). We decided to separate the layout of components into three parts, one previously mentioned, one with D/A & A/D, and one with all serial communication stuff. This will allow for multiple testing environments. Trey and Mike worked on the layout for the UART, MAX232, Xilinx, and serial port jack. Drawings of the circuits are being made for the presentation and for later reference. A communication diagram was also constructed showing the relationship of communication between the GUI, the MAX232, the UART, Xilinx, and the memory.

Thursday, 3/118:30pm-1:45amTreyWorked on the GUI. Cleaned some code up, added a few features dealing with the log file, a timer, etc. Also worked on writing bytes to binary files and was running into problems writing variants to a file. Extra bytes were added when writing. 6:00-7:00pmMichelleI am getting very frustrated with this circuit. I am changing out resistance values with the new resistors we got today, and have an interesting thing happening with the oscilloscope. I can change the voltage it measures by adjusting the volts/division, which definitely should not happen. I have no idea what I'm doing wrong, someone else will have to look at this with me next week. 1:30-2:20pm Aaron and MichelleMichelle tested the circuit with the -5 Volt regulator, and showed the data to Scott. He now thinks that our problem is that the resistors are too big, so we went to physics to get better resistors. Hopefully this will raise our offset voltage up enough that we don't have to worry about voltages around zero, which is where we are having problems. We'll see. 12:15-12:45pm MichelleI hooked up the D/A circuit with the power supply like Mahapatra suggested. It didn't work well 'cause we had to hook the ground on the board to the positive terminal of the supply to get negative voltage out of it, and it was pulling 1 A of current from the circuit, which is way too much. So I rehooked the circuit up with the -5 Volt regulator, and will try again later.

Wednesday, 3/103:00-6:00pm Group Meeting in ClassOf key importance was getting the Bi-weekly report done. While this was getting finishing touches from everyone in the group, mainly Jeffrey, we were all working on out different modules. John and Jeffrey

128

worked more on the memory module and talked to Scott and Mahapatra about cutting down on the CLB count. Aaron and Michelle wired up another circuit for testing the D/A chip after talking with Scott. Trey and Mike worked more on the GUI and got a fully working serial port sniffer, with status of control lines and ability to change DTR and RTS. After a little bit of work it was found that the DTR needed to be clocked from high to low to initiate communicati5on with the Basic Stamp II. Later this week, implementation of the UART control module will begin, followed by hardware layout and setup.

Monday, 3/089:00pm-10:15pm JeffreyI went ahead and punched the skeleton of our bi-weekly report 2, and sent it on to Trey, who filled out the serial stuff. It is in the osano directory under the biweeks directory called bi-week2-2. The only criticism form our first bi-weekly report was that we did not have the title of our project on the cover page. That's all for now. 3:00-6:00pm Group Meeting in ClassAnother wonderful day of problem solving. John and Jeffrey continued to slave over the memory, trying to reduce a CLB count that jumped from 44 to 89 overnight. We are currently looking at ways of restructuring the code. I don't know what else happened that day. Aaron and Michelle worked on the D/A more. We tested the linearity of the output voltage versus the binary input, and ran into problems. The graph is linear until the output voltage approaches zero, and then it messes up. We are not sure why this is happening yet, it might be because of the 741 op amp which converts the output current of the D/A to voltage. Mike and Trey worked on the GUI and the serial app, it should work pretty well now, we'll test in on Wednesday.

Sunday, 3/079:30-11:00pmAaron and MichelleWE GOT THE DAC0800 TO WORK!!!!!!!!Anyway, using the voltage regulators to supply the proper voltage, we got it working. If anyone is interested, a sketch of the circuit layout is on the back of one of the pages of the Thai document. Monday will be spent charting the output depending on input bits to graph data like we did for the A/D. This data could be put in our bi-weekely report. We also need to see if we can eliminate the regulators from the circuit . After that, we need to try again hooking the D/A and A/D together and testing the output with the speaker like before. Hopefully we made a big step in the right direction and we can quit moving backwards with the audio stuff... 12:00-1:00pmJeffreyI went ahead and did a rough outline of bi-weekly report 2. I basically just copied our log file in, wrote some introductory stuff, and brainstormed some ideas for problems and goals to accomplish next week. I made a new directory on the osano server called biweek, and put both biweekly reports there if anyone want to talk about them. We will discuss this in class tomorrow.

Saturday, 3/06

2:45-5:00pmJohn and JeffreyRefined the current working memory control module. Thus far we have cut down on CLBs by a factor of two... Tomorrow we will finish this refinement and do some boundary simulations. Hopefully on Monday we can hook it up and at least write and then read a byte. More ideas on testing the 4Mbit memory chip with the Verilog control module would be very cool. 1:20-4:15pmMikeGot quite a bit of the GUI done. Things look ok, it should be effectively sniffing the serial port, I guess I'll try that tomorrow. 12:15 - 1:45 pm

129

Aaron and MichelleWe hooked up the D/A circuit using the voltage regulators we got on Thursday. It still doesn't work, so it looks like we'll be building a D/A from resistors and transistors. We're not sure why it doesn't work, maybe the chip is bad or we're just stupid. We'll probably hook up our own D/A tomorrow.

Thursday, 3/0412 noon - 12:30 pmAaron and MichelleWe gave up trying to get the voltage divider for -5V to work correctly (the load of the circuit was screwing it up). So, we went with Scott today and got some voltage regulators for 10, -10, and -5 V. We will probably work on wiring these up Friday or Saturday afternoon. Once that is accomplished, we can test our last idea on getting the DAC0800 to work. After that, other ideas are to return to the DAC0830 but reduce the sampling rate (so it can keep up), or to build our own DAC using transistors and resistors. Also, if Mid-State has any other DACs, we could see what those could do.

Wednesday, 3/039:00 - 12 midnightAaron and MichelleWe spent more time on the D/A. Michelle wired up another circuit to test the D/A only, and it did not work. We're not sure what is going wrong, except that maybe the circuit resistance is interfering with some voltage dividers, so we need to use another breadboard to input + and - 5 volts. We're also looking at using voltage regulators for this purpose. 3:00 - 6:00pmGroup Meeting in classJohn and Jeffrey spent more time on the memory controller and did the math to come up with a minimum and a maximum frequency. The min and max frequency help to verify that the timing will work for the memory in relation to a 4kHz or 8kHz sampling scheme. We should be able to wire up the smaller memory chip on Monday and do some testing of both read and write abilities. Trey and Mike did more research on the serial port and concentrated on writing basic apps to interface with the serial port on the PC side. We are still looking at Visual Basic and Visual C++ but think the application part will be much easier in Visual Basic. Aaron and Michelle screwed with the D/A chip and ended up nowhere.

Tuesday, 3/029:00pm - 1:00amTreyI was looking at purely serial stuff today and ended up getting full communication between a Basic Stamp II and the computer working. I got, wired up, and programmed the BSII to send continuous output through the serial port. For anyone that's interested, the data rate is 9600 at 8N1. I wrote a Visual C++ console app that reads in data from the serial port and displays it on the screen. I'm going to look tomorrow at whether or not I can directly control the control lines of the serial port, specifically the DTR. I'll then take a look at whether or not I can write code with the same functionality in Visual Basic, thus allowing for easier design of the application (GUI). I'm going to look more at the actual hardware of the serial stuff as well. I also cleaned up the log.html file. 9:00 - 10:00pmAaronI looked over the A/D-D/A circuit again tonight. We are still not getting any output from the circuit, and the A/D chip is getting pretty warm whenever I power up the circuit. I think we may need some caps that are in the Thai diagram (Figure with ADC0804 and DAC0800) that have not yet been put into the circuit. They are all on the D/A chip and are circled in the diagram if anyone wants to look there. I will go by Zachary tomorrow before lab and pick up caps with those values (0.01 uF and 0.1 uF). Other than that, I don't really know what else to do. We may need to enlist Scott's help. The up side is that the inverter still works great!

Monday, 3/019:00pm-12:15am TreyLooked at serial communications code and application code. I'm looking at using either Visual Basic or

130

Visual C++. I'm basing the decision on ease of communication with the serial port as well as ease of making a user interface. I have some good simple C++ code for serial communication from Scott and have found samples in both languages within the Developer Network as well as several past projects. I posted the past projects that might be of some use for serial communication and app development on our main page. I'm also going to look seriously into setting up a Basic Stamp II for testing purposes on the serial port. It's supposed to be really easy to use. 2:30-6:00pm Group Meeting in ClassWhat a day, several giant steps, backwards. John and Jeff have been working on the Verilog implementation of the memory control modules. They have write working, and read works as well, sometimes. Aaron, Michelle, and Mike examined the inverter(works great) and the active low pass filter(doesn't work). We tried a passive low pass filter and that came out way too slow to be effective. Aaron and Michelle wired the new fast D/A to the old A/D as well as to the inverter. That circuit remains to still be tested, and is not working as of yet. Hopefully we'll have a stronger grasp of active filter design next class period and an effective filter. Trey went and bought parts as well as examination of the possible means to develop the GUI and application for communicating with the serial port.

Remember... Xilinx is cool, but occasionally its bogus 12:20-12:25pm Mike Fixed some stupid mistakes I made when rewiring the inverter and the filter yesterday. Anyone who wants can touch it now.

Sunday, 2/283:30-4:30pm MikeOk, I tested the configuration pretty thoroughly with Scott helping out. Everything works, more or less. The subsystem will work fine for low frequencies but doesn’t work at frequencies above 1KHz. We need to use a faster D/A, which we have. I also moved the inverting op amp and the filter to a new breadboard for more extensive testing there.

Friday, 2/262:30-3:30pm Mike Read the 325 book and came to a realization. We have designed the low pass filter incorrectly. Our active low pass filter works, but is not yet complete. See pages 902-903 of the book for more info. I don't know if the additional feedback resistor will make a difference but I think we should try.5 minutes later....Ok realizing that our previous active filter was incorrect I updated ours on the board to look like the one on page 902 of the 325 handbook. I think this may fix some of our old problems. I'll be by for a few minutes on Sunday to test it so let me know what you guys think. When referring to page 902 I used the 39 ohm resister for R2, the 1uF cap for C and a 47 ohm resister for R1. Ideally R1 would also be a 39 ohm, but the 47 wont' do much except make the gain about 85% of what it normally would be, no big deal. If anyone tests it before Sunday let me know if it helped. 1:00 - 2:30pmMike and MichelleWe tested the circuit at each stage, and found that our op amps all work correctly, and the active filter works fine. We think the D/A is just not keeping up with the A/D and plan to change it out with the faster DAC 0800.

Thursday, 2/259:00 - 9:30amJohnThe memory write now works, in simulation. A bug was corrected in the case of a buffer being full and

131

starting the main memory program command. We should now be able to stream in 2 Mbytes of data into the chip. The Verilog code is on osano in the mem directory (memory.v).

Wednesday, 2/2412:00 - 1:00pmJeffreyI went ahead and made all the necessary corrections to the first bi-weekly report. I expounded on the problem sections, and divided our accomplishments up into group and individual. The final report is available on the Osano server if anyone wants to look over what all I did. Feel free to make any corrections. 3:00 - 6:00pmGroup meetingAaron and Mike hooked up the speaker to the test circuit and produced sound. However, the sound was mostly noise. Friday will be spent trying to eliminate the noise from the circuit. We think our 0800 D/A chip is bad, so Trey and Michelle went to Mid-State and got a new one. Jeffrey finished the biweekly report, and Jeffrey and John worked on the write cycle control for the memory. They can write a byte to memory, theoretically since we don't have the memory yet, but still have a little more work to do. 9:30 - 10:15amJohnEntered the initial attempt at a memory control module in Verilog form. I have not had a chance to compile it in lab yet, we can do that during class today. The algorithm in the mem directory on osano if anyone wants to look at it. Currently the algorithm allows for data streams to be written 8-bits at a time with minimum control bits being clocked into the memory chip.

Monday, 2/226:00 - 7:30pmMike, Aaron, and TreyWe worked some more with Scott trying to get our output from the D/A to match the input to the A/D. It was determined that the most likely cause of error is that the DAC08000 we have is bad. We got a DAC0830 from Scott and will try to hook it up next. Kudos to Mike for staying extra late to clean up our lab stuff. Aaron found the PDF datasheets for the DAC0830 and put them in the current directory on Osano as dac0830.pdf. 3:00pm - 6:00pmGroup meetingAaron and Mike fried a potentiometer! They did this while hooking up the A/D D/A test circuit. We started our biweekly report which is due Wednesday. John and Michelle researched compression, Jeffrey researched memory interface, and Trey researched the serial interface.

Saturday, 2/2010:00am - 2:00pmJohnWorked on improving and generalizing the Verilog companding algorithm because is seems that a look up table this large will kill way too many CLBs. Read the memory data sheet very thoroughly and have a rough draft idea for an algorithm to write to memory. I think the hardware interface will be very simple (just power, the clock, and the XiLinx chip). The XiLinx portion will depend mostly on how the rest of the component timing is being handled.

Friday, 2/193:30 - 6:00pmTrey and AaronTrey and Aaron found a site that showed how a 68k was hooked up to an A/D and a D/A (which also had audio in and audio out, respectively, and some info on hooking up serial to it). It was awesome! We started hooking up the D/A to the A/D test circuit we already have, but we have not finished it. It is possible some people could come up Sunday afternoon to work more on this. It doesn't seem necessary to have a whole group meeting. The current plan is to hook up A/D, D/A, and the pot, and test the output voltage using the

132

multimeter. If that works, we would then proceed to attach the speaker and mic. The next step would be to work in the Xilinx somehow. 1:30 - 3:30pmTrey, Aaron, and MikeWe went into Bryan to Mid-State Electronics and found what we think will work as a D/A converter. The chip is a National Semi dac0800. It cost about $5. The chip does 8-bit D/A at 100 ns and is low power. The pdf is in the current directory on osano; its name is dac0800.pdf. Mike and Aaron also looked at Active filters. We are very close to a solution there. We still need to work on the amplifier part of the output.

Wednesday, 2/1711:15amMichelleI heard from Scott that my friend at Atmel called back. Our 2M memory chip should ship tomorrow, so we should get it early next week.3:00-5:00Group Meeting (class)Looked at new circuit schematics for filtering analog input and output based on designs of CrystalSemi chip. Built test circuit for A/D chip. Got A/D it working correctly on test ckt in self-clocking mode. Now we need to get D/A chip (its "in the mail" supposedly) and do a test circuit on it to see how it works and then try and hook up A/D, D/A, LP filter, and Amplifier together and try and feed a waveform in and get sound out.

Tuesday, 2/1610:15-10:45 amMikeRead the data sheets for the A/D and D/A very thoroughly. Have new info to discuss with everyone tomorrow about their operation.

Monday, 2/154:30-5:30 pmMike and AaronFinished LP filter design. Simulated in B2Spice and got expected results. Were not able to test actual components yet -- the EE instrument room didn't have needed capacitor. We recalculated some values and got an answer we believe will work: A simple RC circuit with R=4 Ohms and C=10 uF. The input voltage is tied from R to GND, and the output voltage is tied from C to GND. The transfer function is then Vo/Vi = 1/(RCs + 1), which implies that the corner frequency f = w/(2*Pi)= 1/(RC*2Pi). Since we need a corner of 4kHz, we picked C to be 10 uF, which meant R would be 4 Ohms. One alternative is to set C=1 uF, which implies R=40 Ohms. When simulated in B2Spice, the value of a 5V input at 4000 Hz was about 3.53 V, which is .707 * 5V. 3:00-5:30 pmGroup Meeting (class)Finalized components, checked on component availability, and gave component list to Scott. The A/D and D/A chips are available now, but we are still waiting to hear from Atmel about the memory chip. It's so new that none of the distributors carry it yet. Michelle requested a sample from Atmel on Monday, and should hear back from them on Tuesday. 4:15-5:00 pmJeffreyWent ahead and pieced the abstract together from various components of the initial proposal. I went ahead and posted it on the FTP server for further review and modification by peer group members. Comments and alterations are highly encouraged. 2:00-3:00 pmAaronWorked on adding/editing web page and establishing project milestones.

133

Sunday, 2/143:00-5:00 pmMike and Trey We went to Radio shack and purchased a speaker, two small circuit manuals, and an ic that performs audio amplification! Yeah. We also went to Barnes and Noble and researched developing amplifier circuits. 3:00-5:00 pmAaron and MichelleWe worked on LP filter and BJT amplifier to be used between Speaker and D/A. We have a BJT design made, but need speaker specs and input voltage/current info to complete. The LP will be a simple RC circuit with 1/RC set to have a corner frequency of 4kHz. 3:00-6:00 pmJeffrey and John We completed an initial hard coded 2:1 companding compression implementation in Verilog. It used 18 CLBs. Creating a 4:1 or 8:1 would be fairly simple and require the same number of CLBs. We still need to generalize the algorithm instead of hard coding it. This will present some difficulty as Verilog does not have some of the needed features.

134