Team D0: FPGSZR

This week, I worked on prepping for our demo and getting started with some VGA code for giving the user a visual view of what’s going on.

My plan is to have the VGA show the live drum sequence, effects being used, filter shape, ADSR shape, and (hopefully) some representation of the audio output. I’ll use one of the monitors in HH to debug this. I am also looking into what screen to attach to the FPGA. This small screen will be directly integrated onto the synthesizer, and will provide a more minimal UI to the user for interfacing with the synth.

I’m also working on getting more drum samples onto the FPGA and figuring out an efficient way to route an ADSR to all of them. Unfortunately, I may just have to duplicate the ADSR module for every drum track. Without doing this, the user won’t have the full customization of the drums that I want to provide.

For testing, I’m planning on capturing the output from the ADSR using a testbench and then validating the output using C++. By just capturing the envelope values based on what I set to be the attack, decay, sustain, and release, I can compare the envelope’s value with what is expected. For the drums, I will capture the output and load it into Ableton. I’ll make sure that the BPM is correctly configured and then also test the output volume levels of the drum tracks. To make sure that the wavetable is outputting the correct tones and notes, I’ll capture the output and use fourier transform to decompose the frequencies and ensure they correspond to the correct note. For a quick check, I’m also going to just use a handheld tuner.

Unfortunately a large part of my week was spent dealing with a Quartus issue; for some reason, I lost the ability to program the FPGA itself, and had to invest a large amount of time finding a workaround. As a result, I focused my effort on setting up a testing pipeline in simulation in order to look at filter / delay outputs and ensuring their stability. Once I got that to work, I debugged delay, and it looks like it works without having to clamp the delay feedback coefficient. Additionally, I used the IIR components to construct a single-pole and biquad low pass filters, and created a cascade filter using multiple single-pole IIR filters. I seem to have finally resolved the Quartus issue today, so I hope to spend tomorrow verifying the filters on the FPGA and qualitatively comparing their outputs, and to spend a large portion of next week ensuring that FM is working properly.

In terms of system testing, I hope to use the pipeline I’ve already set up for the delay output. Primarily, the testbench I’ve designed allows me to optionally add in parts of the pipeline (such as FM, ADSR, delay, etc.), and check how components interact with one another and gather data on output waveform. From this, basic visual inspection can help ensure output stability and that the output is approximately what would be expected. Checking the collected data against MATLAB scripts can allow for further verification, especially on components like a low-pass filter, where the expected output is not immediately obvious. A final check can be performed on the actual FPGA, something I am able to do now that Quartus has been configured properly. Since delay, FIR, and IIR filtering all go in the portion of the pipeline, the testing process is exactly as described above – configure the audio pipeline so we can isolate the specific component in simulation, and then perform progress checks on the output. For FM modulation, the process is slightly different, namely that I intend to directly compare against MATLAB scripts, rather than trying to visually determine if the waveform “looks” correct. I intend to remove all downstream portions of the audio processing pipeline, looking directly as how the wavetable index / waveform output behave.

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.