Category: Uncategorized

This week I worked on creating a MATLAB pipeline for verification purposes. The goal of this pipeline is to emulate the operations performed by the hardware in the FPGA. The pipeline begins with oscillator functions that generate oscillator waveforms over time. These oscillators are then fed into a mixer that combines the waveforms. The mixed signal is subsequently passed through an ADSR envelope. This represents the current state of the pipeline.

The MATLAB implementation is designed to preserve the characteristics of the hardware signals. All function inputs and outputs are represented as unsigned integers, and all values are constrained to fit within 24 bits. In addition to implementing the functions, I created testbenches that plot the resulting output waveforms for analysis.

The next steps are to extend the pipeline by adding filters and audio effects. Once complete, this pipeline will serve as a golden model for formal verification of our RTL implementation.

In addition to the MATLAB work, I spent time debugging the RTL module wave_mixer The main change I made was converting the oscillator outputs from two’s-complement integers to unsigned integers. This simplifies the wave_mixer logic, and the module is now functioning correctly.

It is important that we complete the MATLAB pipeline soon, as our current verification process relies primarily on visual inspection. While it is often intuitive what the expected waveforms should look like, making visual inspection a useful first step, the MATLAB pipeline will allow us to perform verification in a more formal and systematic way.

During this week, I began working on the wave adder module, which takes a series of weighted coefficients and applies them to the oscillator waveforms. The module is pipelined into two stages. The first stage performs multiplication, where each individual waveform is multiplied by a 32-bit unsigned coefficient. The second stage performs addition, where the products from the multiplication stage are summed and then normalized.

This process introduces a two-cycle latency, as we anticipate that this stage may become the critical path in the design.

In addition to implementing the module, I wrote a simple testbench that feeds in oscillator waveforms along with an array of oscillator coefficients and outputs the resulting summed waveform. However, based on visual inspection, the output waveform does not match the expected result. Debugging this module and identifying the source of the issue will be the main focus of next week.

Together, we also finalized our design report, which details the specific algorithms, protocols, and components that will be used in our implementation.

Our project is connected to cultural factors because music is deeply tied to culture and interpersonal expression. By designing a flexible synthesizer capable of recreating sounds from a diverse range of instruments, we hope our product can increase accessibility to and awareness of different musical traditions. We have designed the system with the intention that it can reproduce musical sounds originating from a variety of cultural backgrounds.

This week, we finalized the major requirements of our project during our design presentation on Wednesday. One of the most significant decisions was to use the DE10 Standard as our FPGA platform, since it includes a built-in CODEC and audio output. We also selected the specific MIDI keyboard we plan to use.

After the presentation, we discussed the possibility of decoding USB signals directly on the ARM core within the FPGA rather than using an external breakout board. The main advantage of decoding signals on the ARM core is that we can write the interface in C, which would significantly improve our ability to iterate and debug quickly. However, a major concern is that the ARM core may be significantly slower than a dedicated breakout board and could become a bottleneck in our system. Our current plan is to begin by using the ARM core to decode USB signals so we can get control signals onto the FPGA, and then transition to a breakout board later if performance becomes an issue.

Daniel is responsible for establishing communication between the ARM core and the FPGA fabric, and he began working on this connection this week. Meanwhile, Shayaan developed prototype oscillators for all the waveforms we intend to generate. He verified the functionality of each oscillator through visual inspection using the waveform viewer.

Next week, we will focus on writing our design proposal paper. One key piece of feedback from our presentation was that our design requirements were somewhat unclear, so we will ensure they are clearly and explicitly defined in the report.

This week, after creating the presentation and finalizing the major design requirements, I began working on the SystemVerilog that will be implemented on the DE10 Standard. I completed the sine, square, triangle, and noise oscillators and visually verified their outputs using the waveform viewer. I also created basic testbenches for each oscillator to evaluate their waveforms at different tuning words (frequencies).

Since I had already developed the saw oscillator earlier, we now have a prototype oscillator for every waveform we intend to generate. At the moment, the oscillators output waveforms that are meant to be interpreted as two’s complement values, but I still need to check the CODEC specifications to confirm what format it expects. I also plan to determine the maximum frequency at which each waveform can operate and whether this limit differs among the oscillators.

In addition to these two tasks, the next steps are to create an oscillator adder that combines multiple waveforms and to develop a MATLAB script that performs the same function so we can compare the results through inspection. Once the overall algorithm is finalized, I will run more comprehensive tests.

Our Proposal!

Proposal Presentation