I spent most of the week working on testing out and debugging the FPGA interface with the built-in codec (apart from working on the design report with my team). There was some time spent getting caught up again on Quartus’ features and tools, since most of my recent work had been through the use of Vivado. Once that was over, I set up all the pin assignments as required for the I2C and I2S interface, being left with the following physical debugging setup:
The most significant 4 LEDs are meant to represent the state for the main I2C setup FSM, which is a four bit value. The next four are of the same type, but they show the states for the internal I2C protocol FSM (just to be clear, the main I2C setup FSM sends out the write commands while the internal one manages the actual ack handling, SDA pulling, etc.). Finally, the last two LEDs are meant to represent the error signal (in the case that something with the protocol went wrong) and the done_sending signal (which indicates that data finished sending). I spent a while trying to debug an issue with the overall setup FSM, wherein I was setting the “send_data” signal to high for only one clock cycle. This caused issues with the protocol FSM, because I have it set up so that it sends out data and manipulates the clock at a rate of 250 Khz (in the case of the 50Mhz clock, I’d be manipulating state once every 250 ticks). This caused “send_data” to not be perceived by the protocol FSM, and leave the setup FSM in its first state as the protocol wouldn’t be activated. Once I modified the setup FSM, the FPGA’s LED representing “done_setup” lit up. While this was the main factor for identifying that the system was functioning properly, it also helped that the CODEC began outputting audio from the line out port, as seen in the video below:
https://youtube.com/shorts/HG-n8KKO8Xg?feature=share
While I have a simple square wave being outputted, my plan for the next week is to more thoroughly test the audio CODEC and investigate how to extract its output for signal comparison in MATLAB. Specifically, I’ll try testing different types of audio output to see if there is variance with the output (that is, I’m not just outputting random noise). I’ll also look into using Quartus IP for generating a 12.288MHz clock utilizing a PLL (since right now my approach could most definitely be fine-tuned). This is in line with the schedule, and no catching up is needed.