Appendix
Below is a flow chart for the tuner. The constants used for a 11 kHz clock are outlined here.
Number of clock pulses in a pristine note. These are not used in the code but are used to calculate the other values.
|
Number of clock pulses indicating halfway between two notes.
|
Number of clock pulses required to indicate a perfect note and the number of halfwaves required to reach that total.
|
Flow Chart of Tuner
This section outlines the number of logic blocks of each Xilinx chip as well as the names and pin placements.
The top level schematic of each chip is shown to indicate the pin names and whether they are inputs, outputs or tri-state. The actual pin placements of these can be read off the section of out pin placement script which we have included. This script can be used to wire up the breadboard which is used to test the product. Because the physical pin and ribbon cable numbers are also given, is should be easy to use a probe to check the outputs of each signal. Toprefers to FPGA1 and Top2 refers to FPGA2.
The last part given for each FPGA is the reference report. This report shows the sizes of each entity and the total amount of chip space used. From the report labelled top_size. out it can be seen that FPGA1 took up a total of 204 cells. A closer inspection reveals the sizes of each entity. Top2_size. out shows that FPGA2 used 234. 5 cells out of a possible 400. Once again the sizes of each entity are shown as well.
The project was first tested and then built full blown using a breadboard attached to the Rapid Prototyping Board via ribbon cables. The breadboard was required for all the final input and output of the system. This included analog to digital and digital to analog conversion for the final phase and many lights and DIP switches for the testing phase. A schematic describing how to construct the breadboard and hook it up to the RPB is given below. The IC Data Sheet given in the appendix shows the pin names and locations more clearly but this is a great overview of the board. Data sheets for the ADC and DAC used are also given below. For details on how to hook up the ADC and DAC see the data sheets for specific examples (for brevity, only the first portion is included here).
On Chip Test System We had time to get the sram working. This next set of files act together as a digital delay. This simple, simple design allowed us to see if our state machines would work nicely and made sure that our method of talking to the ram was accurate. We hand clocked data values in from the breadboard through the external proto connector A, and watch them appear later on the LED's. Rather than testing 256 values like we used in our design we used only 8 for simple testing. We routed both the data and pertinent address lines to the on board LED's. The digital delay module was easily pilfered from the file sample keeper. The slop entity derived from the top file, and governor bears resemblance to the controller. The fact that this test worked gives us great hopes for EMo. VHDL Code For Synthesis
Herein lies a great tonnage of VHDL code. It is so well designed and nice to look at it makes a man cry. We worked a great many hours on the underlying system, and we believe it's well represented by this code. With a few tweaks, it'll work like a charm in no time. Notice the modularity of it all, the smoothness, entity bounds represent concept bounds. These smooth blocks plug into one another to form a complex system.
Herein lies a great tonnage of VHDL code. It is so well designed and nice to look at it makes a man cry. We worked a great many hours on the underlying system, and we believe it's well represented by this code. With a few tweaks, it'll work like a charm in no time.
Notice the modularity of it all, the smoothness, entity bounds represent concept bounds. These smooth blocks plug into one another to form a complex system.
This is some code used for running the simulations. A new top was written to control top.vhd and top2.vhd so that it would be much easier to simulate all the files working together. Because we used SRAM, we needed a vhd file to simulate it. We found a great file on the net. Note that these files are so simulation purposes only.
EMo.class (This is 100% pure java. Download the byte code and enjoy)
This is some code we wrote to simulate EMo. It is the only indication of what this dream sound EMo will be. It was really exciting to get this implemented, but of course it's not real time. We can only record licks on our computers and pass them through. Only when we write to chip and pass our holy signal through real time, will the age of EMo begin.
Directions:
Follow these directions well, lest you be sworn at.
Put the classs file in your home directory and ensure that this directory is seen by your classpath. For Unix boxes try "setenv CLASSPATH .;" (you'll have to be in your home directory when you do this. For PC's you could move this file into a directory that is on your classpath (type set at the dos prompt to see what directories your classpath knows of), or make the directory you're in the classpath by typing "set CLASSPATH=." . In any case give us mail, if you need help becuase this is too cool an effect to miss.
Type at your command line these words three:
java EMo GuitarLickPlainJane.snd GuitarLickEMofied.snd
EMo is the class name. GuitarLickPlainJane.snd is a sound file that your little brother recorded on his new guitar and converted to a raw, mono, signed (byte swapped if done on a PC) sound file. It can be at any sampling frequency (this isn't a feature, rather a characteristic of the algorithm). The file GuitarLickEMofied.snd will be the new output file and will have the same specs as the file above. Use goldwave (for windows available at shareware.com) to record and format input samples on your PC, as well as to play the output file.
Then after hearing the sweet sounds of EMo, run down your street naked yelling "Rock and Roll has been saved!"
Here are a couple of sound files that we used to test our theories on. It's pretty obvious which one rocks the house down. Check out the waveforms to see the difference.
TestPatternGenerator.class (Byte Code)
This piece of code is used to generate test vectors, its great because it's so easy to use, and allowed us to pass a tonne of different sound files through our simulator without worrying about setting shit up. If you are smart and doing a DSP project that uses an A-D you can use this class file to generate yourself some test vectors. The way it's set up now the force file looks very much like an ADC that asserts it's data for a while and then later goes to a high-impedance state. If you're an expert hack (like Clay) you don't need to know java, just look at where the text is output and change the strings. The syntax for using this class is:
java TestPatternGenerator soundfile.snd testvectors.forcefile
The soundfile.snd is a binary sound file full of signed short integers. They are two bytes in Unix Byte order (opposite of what a PC uses.). The force file is a text file that is many, many times larger than the .snd file, the first sound file we used was a 26 minute version of Dazed and Confused (Led Zeppelin) sampled at 44.1kHz, the force file was 4 TeraBytes long, and took 43 days to run through the simulator... a 2 to 3 second sound file should be more than enough.
Student CAD Tool Documentation
Here is the fabulous CAD Tool documentation from EE552.
Check out the fantastically out of date EMo home page. (The page may be out of date but EMo will never go out of style)
.
.