Differences

This shows you the differences between two versions of the page.

--- projects:cordic_algorithm [2013/12/19 22:41]
cbarnes
+++ projects:cordic_algorithm [2013/12/19 23:19] (current)
cbarnes
@@ Line 18: / Line 18: @@
 Finally, I was ready (or at least, as ready as I ever would be) to make CORDIC in verilog. Fortunately, people had done similar things and shared their work on the internet, so even though I am on a team by myself, I certainly didn't have no help. I started by making the simple module, defining x, y, and angle inputs and sine/cosine outputs.
-Then I had to produce a 31-entry long table of atan values to be my look-up-table. Each value in the table is equivalent to atan(2<sup>-i</sup>) where i starts at 0 and ends at 30. But, to create a 32-bit scaled value so that all the unsigned, fixed-point arithmetic would work out, every value was multiplied by 2<sup>32</sup> and divided by 360. Thus the atan table was created. {{ :projects:atan_table.png?500 |}}
+Then I had to produce a 31-entry long table of atan values to be my look-up-table. Each value in the table is equivalent to atan(2<sup>-i</sup>) where i starts at 0 and ends at 30. But, to create a 32-bit scaled value so that all the unsigned, fixed-point arithmetic would work out, every value was multiplied by 2<sup>32</sup> and divided by 360. Thus the atan table was created. {{ :projects:atan_table2.png?700 |}}
-The CORDIC algorithm only works for values between -90 and 90 degrees. This is why my next step was to check if these conditions were true, and make the necessary changes if not. Because of the way I scaled the angles, I could simply check the leading 2 bits to see what quadrant the angle was in. PICTURE
+The CORDIC algorithm only works for values between -90 and 90 degrees. This is why my next step was to check if these conditions were true, and make the necessary changes if not. Because of the way I scaled the angles, I could simply check the leading 2 bits to see what quadrant the angle was in. {{ :projects:quadrant.png?700 |}}
-The last part was to finally implement the meat of the CORDIC algorithm where all the iterations take place that produce cosine and sine values. The number of iterations that need to be implemented depends on how many bits wide the input is. Since my inputs were 16-bits wide, I only needed 16 iterations before I wouldn't be getting any more precision. So the entire algorithm is contained in a for loop that goes though, assigns the bit-shifted X and Y variables of the current iteration, finds the sign of the current Z angle, then calculates the next values of X, Y, and Z. PICTURE
+The last part was to finally implement the meat of the CORDIC algorithm where all the iterations take place that produce cosine and sine values. The number of iterations that need to be implemented depends on how many bits wide the input is. Since my inputs were 16-bits wide, I only needed 16 iterations before I wouldn't be getting any more precision. So the entire algorithm is contained in a for loop that goes though, assigns the bit-shifted X and Y variables of the current iteration, finds the sign of the current Z angle, then calculates the next values of X, Y, and Z. {{ :projects:cordic.png?700 |}}
@@ Line 35: / Line 35: @@
 === Workplan Reflection ===
-In our workplan, we set a goal to create an audio/visual synthesizer using an FPGA, which we completed by setting up our FPGA that can play notes and light up LED's depending on  In terms of meeting our goals for the demo, we were able to both play music and light up corresponding LED's.
+In my workplan, my goal was to create Verilog code that would implement the CORDIC algorithm and produce sine and cosine values with the reach goal of doing logarithm as well. I almost met my minimum deliverable, but my code does not perfectly do what I had planned it to do. I think I underestimated how difficult it would be to implement signed, fixed-point math.
-With regard to our workplan, we were able to set out to do everything we wanted to do, partly due to the fact that we were relatively vague in what we actually wanted to do with regard to music. The only step that really took significantly longer than we expected to was synthesizing our verilog code on our FPGA. A large reason for this was that it took us almost a week from when we started to even get all the correct Xilinx packages downloaded and properly installed. Other than that, our timing was about what we expected. Our final step was a rather arbitrary "making our music and lights cooler", which we have been iteratively doing over the course of the last week, and we now have a final product that we are more than satisfied with.
+I didn't follow my workplan very well. I think there were a lot of contributing factors as to why, namely that it took me longer than expected to understand the CORDIC algorithm. Most notably though, I realize now that verilog is still a language I am very uncomfortable with and this was what made it take so long implement CORDIC in verilog, although I think my understanding of verilog is significantly higher now.
-=== Circuit Diagram ===
-{{ :projects:signaladder.png?400 |}}
 === Code Appendix ===
-All of our code is in our github repository: https://github.com/mdelrosa/cafinalproject. The ucf files are all responsible for mapping between the FPGA and our verilog code. The relevant code with regard to the user input piano is in piano.ucf, and piano.v, and the code with regard to playing music with a look up table is in music_code.ucf, LUT_song.v, and memory.mem. The code responsible for switching between the modes is in master.ucf and master.v.
+"https://github.com/bunyipc/cordic"

ca Wiki

User Tools

Site Tools

Differences

Page Tools