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.