Month: March 2026

This week, we focused on preparing for the interrim demo and planning out interface for the final design. We feel that most of the components are coming along well and we hope that we will have time to add in additional features and a nicer interface using an Arduino with knobs / buttons. The schedule has not changed and we feel that we are in a good spot, our major risks going forward are with filtering and the MIDI breakout board being more complicated than expected. Nonetheless, we have ended the week feeling optimistic and fairly prepared for the upcoming demo.

I spent most of this week with my teammates preparing for the upcoming interrim demo. For the first half, I realized that there was a core issue with how I was implementing frequency modulation earlier and decided to redo it based off of articles I found online, mainly, I now use two oscillators. The first is the baseline that is already used to perform wave table lookup, and the second oscillator is used to modulate the first. I am still in the process of debugging this and do not believe it will be done before the demo, but I plan on running simulations and comparing outputs to matlab scripts – one of the standard testing processes as described in our design report.

The second half of the week was spent on adding delay to the actual FPGA and debugging. The delay module was added into the pipeline after ADSR. A major bug was output amplification, it turned out that I was incrementing the feedback gain too rapidly. This seemed to cause the output amplitude to rapidly reach its maximum, causing a very unpleasant noise to constantly be emitted from the FPGA. I am still trying to understand the source of the issue, but clamping the value of the feedback coefficient g was enough to resolve it. I still plan to spend tomorrow gathering data in order to better understand the cause of the issue, so that I can avoid it for other filters. I intend to spend next week further debugging FM, and hopefully beginning to add in FIR and IIR filters.

I spent most of the week debugging the RTL for the FIR filter component, and implementing infinite impulse response (IIR) filtering. The primary difference between FIR and IIR filtering was that IIR filtering also considers past output values as well as prior inputs, increasing the number of weights that needed to be stored as well as the number of steps in the adder tree. I decided that it was simpler to maintain prior values for both X[n] and Y[n] as shift registers, rather that storing them in BRAM, since, based off of my research, IIR filters do not need to store a large amount of terms. The bookkeeping circuitry eliminated by moving to a sliding window approach seems to outweigh using registers instead of BRAM to store prior input / output wave data. With audio output configured correctly, I also looked into verification. I began writing testing scripts in MATLAB to generate “golden models” for various filters / on board components, mainly looking at the Signal Processing Toolbox. The main question remaining is how to properly capture output from the FPGA synthesizer itself, a problem which I hope to solve in the following week so that we can perform some validation / refinement before the interim demo.

This week, we all came together to integrate our separate modules. The end result was creating a pseudo-keyboard using the FPGA switches, and being able to output various notes using the sine wavetable. All in all, we consider this a great success and we are still on track. The biggest risk we are looking at is demo day, and ensuring that we remain on schedule and can provide a good look into how our final product will look. Some issues may be difficulty with the MIDI interface, along with ensuring that our sound quality remains good.

Video of current stage: https://youtube.com/shorts/-aKYDpD8pd4?feature=share

This week, I worked with Jose and Misho to properly integrate all of our modules into a top-level design. By doing this, we were able to successfully output a sine wave playing at different frequencies, based on a simulated key press through the FPGA switches! The next steps on my end involve creating the ADSR envelope for the note amplitude. Once that’s done, I’ll talk with Misho about integrating it into his filter design. I also need to validate the note frequency (for now, we will hook up the FPGA to a speaker and then use a tuner app to validate the frequency of the outputted note) and integrate interpolation for the other waveforms (saw, square, triangle).

I have also started thinking about how to integrate the drum track into our design. Although the samples will be quite small in memory footprint, we want to support as many as possible. Thus, it may be necessary to use the SD card for extra memory and interface with the Arm core. The MVP for this should still be just using BRAM, but it’s possible that we can have a reach goal that involves using this more ambitious goal. Another question to consider is the input interface for the drums. I would love to have a nice, 3D printed design and chassis that we can interface with to give the user a more intuitive feel. However, we will see if we have enough time at the end of the project.

All in all, I am happy with the progress we have made and believe that we are on a good pace.

The main design change made was covered in Jose’s status report, which is the asynchronous FIFO (rather than a normal FIFO) for managing data between the general FPGA and audio CODEC system. This was done after a talk with teammates where we realized that there was a need for clock domain crossing in our system. While necessary for our system to function and send out data properly, it does not incur any external costs aside from the time spend implementing/debugging (which has only been around three hours so far). Overall, though, our schedule has not changed and we look to keep progressing with our project as planned (and begin doing more thorough integration with our FPGA before the interim demo). Our biggest risk so far is simply getting audio output integration with signals working, since it serves as the backbone for our system. Hopefully, it’s up and running by the following week. In the case that progress staggers, we plan on spending more time than allotted to the course next week to get it working (in addition to the time spent on the other portions of the system.

This week, I spent a large amount of time on the ethics assignment. This involved doing the required readings, along with answering the appropriate questions and then applying that same thinking to my own project. In addition to my work on the ethics assignment, I also worked more on the RTL for the wavetable. I began integrating the phase accumulator into the input to the wavetable, and worked on creating the proper look up table for matching MIDI input to the correct frequency addition when updating the phase accumulator. I then use this phase accumulator value to index into the wavetable and output the correct amplitude. I am also working with Joaco and Misho to integrate these separate modules and ensure that they are functioning properly together. To validate the wavetable output, I ran a verilog testbench which saved the output and then compared to the expected value for each note. We then began validating the output on the audio CODEC, but have not done significant analysis to ensure that it matches directly with the expected note frequency we are playing. For next week, I am going to work on validating the note output.