Posted on

Team Status Report 3/21

This week the team continued to work on the SystemVerilog implementation and Matlab pipeline. We have successfully completed the oscillators, mixer, envelope, and filter modules in both SystemVerilog and Matlab, marking a major milestone in the core signal path development. With these components in place, our focus is now shifting toward implementing the full filter set and verifying the correctness and stability of the overall pipeline. On the Matlab side, only the effects stage remains to be integrated to complete the end-to-end model.

In parallel, we worked with Quartus to synthesize an online example project onto the Intel DE-10 FPGA, gaining familiarity with the toolchain and deployment process. We are still working on establishing communication between the HPS core and the programmable logic (PL) fabric. Additionally, we made initial attempts to produce audio output from the FPGA, though this is still a work in progress.

At this stage, achieving reliable audio output from the FPGA is one of our top priorities, as it is essential for validating the full signal chain in real hardware and ensuring real-time performance. We will continue focusing on debugging the audio interface and establishing a stable connection between the processing pipeline and the output hardware. In parallel, completing the Matlab pipeline is equally critical, as finalizing the effects stage will provide a full reference model for formal verification. This will allow us to systematically compare outputs between Matlab and SystemVerilog, ensuring correctness before full hardware deployment.

Posted on

Shayaan’s 3/21 Status Report

Unfortunately this week I was unable to make as much progress as I would have liked. This week I started to create the SystemVerilog Filter and MATLAB filter files for the simulator. The filter we have chosen is a second order infinite impulse response filter.

A second-order infinite impulse response (IIR) filter is a discrete-time filter defined by a difference equation that uses both past inputs and past outputs, allowing it to achieve complex frequency responses with only a few coefficients. It is the lowest-order filter capable of producing resonance, making it especially useful for shaping audio signals in digital synthesizers. It is computationally efficient and well-suited for real-time and hardware implementations, while still providing flexibility through tunable parameters such as cutoff frequency and Q factor.

Next week, I will use waveform analysis to verify the SystemVerilog implementation, integrate the filter with the other system modules, and connect the MATLAB code into the overall simulation pipeline

Posted on

Team Status Report for 3/14

This week, the team continued working on the core modules in Verilog, while also getting the FPGA ready for testing our implementation on hardware.  We’ve got a MIDI controller in the mail as well, which will be all we need to test that the signal propagates through the pipeline correctly.

Daniel began writing wrappers for the Quartus side of our design,  starting on getting the modules we already have to synthesize.  Shayaan began writing MATLAB tests, which will allow for a much faster checking of our work, by virtue of being able to play directly samples generated from MATLAB, without having to go to hardware. This way, we can ensure what we intend to design will sound the way we expect it to. Jake continued working on the ADSR envelope generator, fixing issues as they arose in a test-bench.

Posted on

Jake’s Status Report 3/14

This week I focused again on implementing the ADSR envelope generator in verilog. I fleshed out a parent bank module, which generates an envelope per-voice with a generate loop. Every voice receives a key-press signal, and its own set of input parameters. While conventional synthesizers do not usually employ a per-voice envelope, it may be interesting to see what this could allow from a sound-design perspective, and supporting it in verilog is straightforward. In our final design, it’s likely I’ll either bundle all the voice signals together and run them in parallel through one-instance, or have only one instance of ADSR  controls for all the generators. Either way, this parent-level bank will support sweeping over the number of voices in our final design.

I revised the internal logic with the output level, and scaled the user-option input level in respect to the output level, as well as compiled a testbench. I still need to vary the state-update to be a parameterizable division of the clock, but this should be a quick-fix I’ll do tomorrow.

In addition to RTL, I helped Daniel get started flashing the FPGA through Quartus. There were a few points of confusion mounting JTAG, and flashing the image, but we sorted it out after some reading, and flashed test programs ensuring our line-out, audio-codec, and other parts are working. We started together on the top-level module to flash the verilog written so far.

Posted on

Daniel’s Status Report for 03/14

This week, we received all the necessary cables and adapters to begin synthesizing and testing functionality on the WaveShaper hardware on Friday. I began a Quartus project and have started integrated functionality, drawing from the selection of IP blocks and beginning a scaffolding to support the core modules.

As of right now, the most work has been in synthesizing and creating SystemVerilog “HDL handles.” There was some additional delay in finding out how to use IP blocks in the Quartus software.

I (with the help of Jake) was able to perform a simple end-to-end test of the toolchain, ensuring that we are able to program the hardware.

Otherwise, I considered how the WaveShaper both (1) has been designed such far in a way that presupposes the Western 12-tone scale and (2) may serve as a tool that can be used to create annoying sounds for malicious reasons.

Posted on

Shayaan’s Status Report 3/14

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.

Posted on

Team Status Report for 03/07

This week, the team pushed to freeze the design of, concretely modularize, and begin the implementation for the WaveShaper in time for the semester’s halfway point. 

Daniel finalized the system architecture for the hardware and external I/O. Jake began writing the hardware description for the ADSR envelope in the sound synthesis pipeline. Shayaan began designing and writing the mixing of oscillators. In addition, the team allocated their time towards writing a design report document, organizing system requirements, specifications, and development schedule.

These steps align with the proposed schedule, and the project is progressing smoothly. On that same theme of project management, the unfurling of the SystemVerilog hardware description of the modules in parallel represent a first for the team in implementing a design upon which we all conferred. Hopefully, this is a good trial for team coordination going into the latter half of the project’s development period and receiving feedback on the design report.

Each team member wrote upon the global, cultural, and environment factors and/or implications of the project in their respective weekly report. Jake Tarin wrote about the global factors (Part A), Shayaan Ghandi wrote about the cultural factors (Part B), and Daniel Abujaber wrote about the environment factors (Part C).

Posted on

Daniel’s Status Report for 03/07

This week, I focused on fleshing out the final aspects of the communication architecture as it relates to the hardware. However, certain details cropped up which in turn informed the “data layer” and resulted in a change in previously made decisions.

Beforehand, I abstracted the model for USB communication on the DE10-Standard development board in order to focus on how to structure the “software side” of the USB-MIDI payloads. In doing so, I did not account for the fact that the USB hub which is downstream of the on-board USB controller presents a restriction in the topology as the USB layer sees it which clashes with the conventions used in standard MIDI devices.

For at the very least the purposes of debugging, I wished to leave headroom the option for a custom serial channel between the WaveShaper and a driving device. While I thought initially this could be achieved by the means of a USB Composite device driver, further inspection resulted in a satisfiability problem between the available USB ports, their direction, and how easily these could all be meshed with standard drivers.

Ultimately (along with consideration of the ease of development), I thought it would be best to compromise slightly on the original technical goals and introduce external hardware components which can ease this.

The final communication architecture resembles involves three streams of data.

  • Serial I/O:
    • WaveShaper interface software <-> FTDI VCP Driver <-> Host PC USB controller <-> FT232R USB UART IC <-> HPS <-> WaveShaper core on the FPGA (over AXI)
    • (The Host PC will register an FTDI VCP device seen from the converting hardware.)
  • USB-MIDI Host PC to WaveShaper:
    • WaveShaper interface software <-> USB-MIDI driver <-> MIDI-USB to MIDI-DIN converter (external hardware) <-> DE10-Standard GPIO on connected to FPGA (UART)
    • (The Host PC will register a USB-MIDI device seen from the converting hardware.)
  • WaveShaper to MIDI controller: WaveShaper core on the FPGA <-> HPS (over AXI) <-> USB3300 & USB251 stack <-> USB-MIDI controller
    • (The HPS supports Linux which has built-in support for USB-MIDI in the kernel https://github.com/torvalds/linux/blob/master/sound/usb/midi.c)
    • These decisions were made with the goal of maintaining a plug-and-play experience, pushing the now necessary converter to something that can be treated as inside the “black box” of the WaveShaper for an end-user, and all the while keeping an I/O interface which could be later developed and refined using specialized ICs such as the MIDI CH345.

On the topic of environmental factors:

While a musical synthesis tool and toolchain may seem on the surface to be benign, one must make the conscious effort to pay mind to possible ramifications of its use and implementation as a result of this fact. Modern electronic devices are all tied into a massive supply chain and manufacturing pipeline which involves the use of many resources and man-hours. At scale, the chemicals, their emissions, and even the choice of solder may present questions and concerns about their impact on the surrounding environment. While these cannot be quantitatively evaluated without a procedure and process, several of the guiding philosophies of the design of the WaveShaper align with a more sustainable future in electronics manufacturing and to a certain extent in computing in general.

The WaveShaper is a dedicated hardware synthesizer. Were the WaveShaper to be developed as a commercial product at scale, the consequences our choosing hardware which is targeted and strictly necessarily would reflect on the both the literal footprint of the PCB and the figurative environmental footprint. By not resorting to using an array of microcontrollers for I/O, synthesis, etc., we reduce the need to put the corresponding devices for this compute on each board. Likewise, by our efforts to keep the I/O as general as possible, this would prevent an end-user from having to purchase and use several adapter cables. (In the case that they would, the other side of the coin is that these common interfaces would be present in other devices they may choose to use in the future.)

In aggregate, these principles and their resulting design decisions not only target a low-overhead set of requirements for compute and processing power but also in the resulting devices which would need to be soldered, interconnected, tested, shipped, etc.

Posted on

Jake’s Status Report 3/7

This week I started implementation of the ADSR envelope generator which will control amplitude/volume of each synthesizer voice. On the final design, when voices remain to be filled, each key-press on the input MIDI-controller will correspond to the triggering of its own envelope generator. At present, the generator takes in attack, decay, sustain, and release parameters along with a key-press parameter. It generates a waveform which will be used to scale oscillator amplitude.

What I’ve written so far will detect key-press and release events, and transition through the different phases of the envelope. The envelope output-level is updated with an increment each clock-edge so that the slope of each stage in terms of level-change/unit-time can be tuned to user-levels without using floating-point operations.

The timing is still under-development, at present, the envelope updates each clock cycle, instead of having a separated control-timing signal. So for the coming week as I continue this design, I’ll separate this piece out so that the parameter tuning corresponds to the scale of audible-noise, and not the internal clock. After this is done, the envelope should be connected to the output of our wave-adder Shayaan was working on this week to see if we can then modulate amplitude upon a key-press.

I’ve opened a pull-request for what I’ve committed this week visible here: github link.

This week, we also finalized our design report.

In consideration of global factors, this synthesizer is designed as a standalone hardware instrument, as opposed to the most readily-available alternatives right now: software synthesizers requiring a PC. Our FPGA design can be operated without requiring access to a personal computer. Further, if the design were later implemented on a dedicated PCB, we could extend the availability as a low-cost device. Taking this approach would improve access for any musician or hobbyist without the means to invest in more powerful synthesizers.

Posted on

Shayaan’s Status Report 3/7

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.