Jake’s Status Report 04/25

This week, I helped Daniel bring up a desktop-environment kernel, as opposed to the console version we had been using prior,  which didn’t support Advanced Linux Sound Architecture needed to interface the MIDI controller. When this initially didn’t work, we resorted to streaming over USB through a serial monitor, on a laptop that could accept MIDI inputs.

So the main motivation behind my action this week was eliminating a huge source of end-to-end latency, and to get us to a point where user-testing is feasible. I now have people waiting to test our device, and this point of contention here is what’s stopping us from moving forward.

Now that the kernel is upgraded with the working drivers, we’ve begun working a program to parse MIDI CCs from the keyboard, and serve control signals to the FPGA. Once we’ve actually got our whole keyboard support final, we’ll need to a bit of frequency correction with the hardware-synthesis of oscillator tuning words, and make sure that accepting our controls doesn’t take DSP blocks.

We’ve found in synthesis that all DSP blocks are in use, consumed by multiplies, but we still have a lot of Logic Elements to make use of.

Team Status Report for 04/25

This week, the team starting tying together the final steps in getting the Waveshaper demo-ready. This included a battery of tests for subsystems and the last steps of integration.

Daniel and Jake worked on MIDI CC commands, cleaning up clocking issues between modules, routing the control systems for the synthesis core (i.e. enabling the user to modify ADSR or filter parameters), keyboard integration, HPS architecture, and performed the I/O latency test.

Shayaan worked on synthesis and a polyphonic demo along with project tooling for more quickly translating system parameters into standard units.

Unit tests:

  • Vocal polyphonic independence.
  • Waveform fidelity.
  • ADSR correctness.
  • Chamberlin variable filter.
  • I/O and FX engine latency.

Objective measurement vs subjective perception was a key takeaway here. The relay method for keyboard control was deemed unacceptably slow. The polyphonic MIDI arbitration procedure was also changed in light of these tests.

Daniel’s Status Report for 04/25

This week, I am aiming to get the HPS sub-system fully squared away. It turns out that there was a corruption in my flashing of a slightly more souped-up Linux system image to an SD card which rendered it unmountable and unbootable media.

Now, having caught this mistake,  I can likely finish getting the keyboard to work natively without a relay by the end of the day.

I now aim to finalize the serial communication mechanisms for Waveshaper control and add a visualization output byte stream.

I performed the latency unit test. This was an end-to-end test of the entire I/O. I used real hardware with a trigger-mode oscilloscope.

Shayaan’s Report 4/25

This week, I finished synthesizing all the SystemVerilog needed to create a fully functioning polyphonic digital synthesizer. Currently, the controls are mapped to the FPGA’s onboard I/O, such as buttons and switches, but Daniel is working on transferring these controls to the keyboard interface. Once everything is integrated with the keyboard, the core system will be complete.

To go beyond a basic synthesizer, we are considering adding features that make the output sound more expressive. One potential improvement is applying an envelope to the cutoff frequency so it evolves over time. Adding this feature would produce a richer and more realistic sound.

I have also started developing an algorithm that takes an input audio signal and decomposes it into coefficients that can be used by the FPGA to reconstruct the sound. While I do not expect to have a fully working version by demo day, my goal is to achieve reasonably accurate polyphonic sound reconstruction using only the oscillators, envelopes, and filters available on our board. So far, I have implemented an algorithm that extracts an envelope from a given sound with about 80 percent accuracy, and I am continuing to refine it.

Daniel’s Status Report for 04/18

This week, I tried to get the keyboard up and running with the WaveShaper as well as implement MIDI CC commands to dynamically adjust the ADSR envelope and filter parameters While this is now up, it is only for one voice at a time.

The keyboard is currently using the laptop from the interim demo setup as a relay. As Jake mentioned in his status report, the distributions of the Linux kernel provided by Altera were not compiled with ALSA support despite having the corresponding dpkg packages. While I believe this can be fixed, I have decided to focus elsewhere for now.

Finally, I am preparing the Quartus file for the final artifact. The time it takes to synthesize is becoming longer and longer with the HPS. Attempts to use design partitions do not seem to reduce this.

Jake’s Weekly Status Report 4/19

This week things move towards conclusion as we find ourselves thoroughly in testing phase. I’ve prepared a questionnaire and a queue of test-users to play with the device. We initially planned to conduct user-testing this week, but experienced challenges with the MIDI-keyboard connectivity.

The design uses the HPS ARM core on the dev-board to parse MIDI input over USB. At present, the linux kernel advertises support for ALSA, which the core was to parse, and pass as input to the FPGA in order to save LE’s for spending on the synthesis data-path instead of on decoding USB communication. While this worked for demonstration, streaming to the FPGA from a .mid file, the kernel we were running didn’t support the technology to accept the MIDI keyboard input.

Daniel and I are in the midst of trouble-shooting this block. I tried using the linux-socfpga github repository to rebuild the kernel with the functionality we need, making  boot-images and device tree structures that would work for the device, then sending them to the device over UART.

Daniel managed to get the keyboard working with a relaying with a terminal that does have ASLA for now to begin. I took FFTs of the each oscillator in time using VISA to stream SCPI commands to an oscilloscope over USB and verified correctness by looking at the FFT. In this way, we also verified that the filters were removing the appropriate spectral content.

As I’ve designed this semester, I’ve learned a great deal about Linux systems, and bringing up verilog. I’ve learned about VCS, and DVE as well as how musical synthesis is achieved. I’ve learned mostly through reading data-sheets for the DE10 standard online, watching other people’s projects online through youtube or instructables, and asking AI to explain mathematics, or source me things to read.

Team Status Report 4/18

This week, Shayaan finished writing and verifying all of our SystemVerilog modules. Much of the design has also been synthesized, leaving only the final pipeline synthesis remaining. Our completed signal chain will follow the structure: Oscillators -> Filters -> Envelope -> Effects. Once the full pipeline is synthesized, we will evaluate how many voices our FPGA can support given resource constraints.

We are also planning to enhance the system by adding an envelope to modulate the filter cutoff frequency, which should produce a more dynamic sound. In addition, our MIDI keyboard recently arrived, and Jake and Daniel have begun working on transmitting MIDI commands to the FPGA. We are currently encountering some difficulties sending commands directly, so we may need to use a computer as an intermediary.

Daniel is also working on developing a GUI on a computer that will provide detailed control over the synthesizer and offer a more intuitive visualization of our pipeline. The interface will feature a drag-and-drop block diagram, allowing users to easily add and configure effects, filters, and envelopes within the signal chain.

This week, we also performed final verification of our synthesizer. We measured the frequency of the waveforms generated by the FPGA and compared them to the desired target frequencies. We also computed FFTs of our oscillator outputs to evaluate how closely the generated waveforms match their ideal forms. For example, we analyzed the FFT of a square wave to confirm the presence of only odd harmonics. While it is easy to hear whether a filter behaves as a high-pass or low-pass filter, we additionally used FFT analysis to quantitatively examine how the filter affects different frequency components.

Finally, we organized a session where friends will use our FPGA synthesizer to provide validation data. We plan to discuss both the results and the evaluation methods in our presentation.

Shayaan Status Report 4/18

This week, I made significant progress in writing and synthesizing our effects set. At this point, all of our SystemVerilog modules have been written and verified against our MATLAB pipeline using bit-by-bit verification. This process involves generating an expected hex file from the MATLAB pipeline and ensuring that the SystemVerilog output matches it exactly.

I have written and tested the Delay, Echo, Reverb, Redux, and Distortion modules, and I have successfully synthesized Delay, Echo, Redux, and Distortion. I plan to synthesize Reverb shortly. There is still a small bug in our Envelope module that I am actively working to resolve.

The next step is to integrate all of these components into a final top-level module and evaluate how many voices we can support given the FPGA resource constraints. Another major aspect of our project, which we discussed earlier in the year, is developing a program that takes an input sound and determines how to recreate it using our FPGA synthesizer. This includes identifying the appropriate frequencies, filters, envelopes, and effects needed to approximate the original sound. Once the top module is complete, I will focus on building this program and aim to bring it to a presentable state before demo day.

One of the most important lessons I learned during this project is the value of thorough verification. There are many approaches to verification, but using bit-by-bit comparison with a golden model proved especially effective. When issues arose during synthesis, this method allowed us to quickly isolate and identify the source of the problem because we had high confidence in the correctness of verified components.

I also gained experience working with proprietary IP, which can be quite cumbersome. Since we are using an Intel FPGA, we rely on Quartus IP blocks to drive the DAC for audio output. Integrating and understanding these components took significantly longer than expected due to the complexity and limited transparency of the documentation. Additionally, my team is working on interfacing with a MIDI keyboard, which may require further interaction with proprietary IP. Navigating documentation and implementing even basic functionality often required substantial time and effort.