Month: April 2026

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.