Appendix

System Flow Chart


Tuner

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.

A (E5)

8.3616

B (B4)

11.1616

C (G4)

14.0625

D (D4)

18.7717

E (A3)

25.0568

F (E3)

33.4476

Number of clock pulses indicating halfway between two notes.

Half_A_to_B

10

Half_B_to_C

13

Half_C_to_D

16

Half_D_to_E

22

Half_E_to_F

29

Number of clock pulses required to indicate a perfect note and the number of halfwaves required to reach that total.

A

268 pulses

32 waves

B

268 pulses

24 waves

C

281 pulses

20 waves

D

300 pulses

16 waves

E

300 pulses

12 waves

F

268 pulses

8 waves

Flow Chart of Tuner

IC Data Sheet

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.


IC Test System (Breadboard)

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).


IC Chip Test System

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.


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.


VHDL Code for Simulation

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.


Java Code

EMo.java

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:


EMo Rocks

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.

Test Pattern Generation

TestPatternGenerator.java

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.


EMo Home Page

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)

.

.

Back to main page