This week I spent some time working through the configuration of the onboard CODEC to line-out. The I2S frame should be 32 bits per frame, 28 bits for left and right stereo. The frequency = sample_rate * bit-depth * 2. So we’ll need to drive a minimum of 3MHz with the FPGA output as master, and the codec as slave. Any line out powered PA system will work.
Daniel’s Status Report 02/21
I spent the first half of this week preparing to present the design report on Wednesday.
After that, I took time to revise the Intel documentation for the IP blocks available in the Quartus software tool chain. By taking advantage of the already existing IP blocks for the audio codec, DAC control, and DSP, it may accelerate the interfacing endpoints of the WaveShaper to get the project to a demo-ready stage. I am not familiar with using IP blocks under the Quartus toolchain, so I needed to familiarize myself with the general process and set up a project file that could be used to program the fabric.
We have all the tools required to attempt to create an end-to-end test and produce a series of notes from Shayaan’s oscillator hardware descriptions. Namely, using the audio “stack” of blocks to ultimately drive the Wolfson audio chip.
Moving forward, I would like to use the HSP chip to create a interface to receive USB payload data and pass the wrapped MIDI commands to the main control module of the WaveShaper.
Team’s Status Report 2/21
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.
Shayaan’s Status Report 2/21
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.
Jake’s Update 02/14
This week I tentatively decided to move forward with the DE10’s onboard codec. It’s at least clear now that the codec will deliver 48KHz out at 16 bit-depth, using pulse-code-modulation. What remains to be done is confirm that the codec can access its next outputs from the Bram under real timing-constraints using I2C to talk to the board. I wrote a square wave in verilog which remains to be tested.
Daniel’s Status Report for 02/14
This week, I continued to explore options for communication between the driving PC, the WaveShaper, and additional MIDI peripherals. Earlier this week, I had considered and sketched out a protocol wherein all auxiliary (i.e., non-MIDI) information would be transferred within the SysEx commands of the MIDI spec. While this is still feasible and should be able to keep up for live, real-time music, the USB specification enables the use of “composite devices” which support multiple, simultaneous interfaces. This could lend itself to more flexibility and warrants more analysis before setting in the serial communication in stone. From an ease of implementation point of view, it would have the advantage of having convenient parallelism between these conceptually disjoint streams without the need for additional hardware or cables.
(This design decision was prompted with the choice for the DEC-10 FPGA in mind, seeing as it supports both USB host and device interfaces.)
We would want to consider support the following serial streams.
- PC to the WaveShaper for MIDI notes and events.
- PC to the WaveShaper for a “shell”-like command interface.
- WaveShaper to PC for probing into the sound synthesis datapath.
- WaveShaper to PC for responses to “shell” commands.
- [Optional] A final USB audio input interface which can enable the PC to be used as a speaker / audio sink.
These could all be interfaced through dedicated, corresponding USB device classes.
While it would be incredibly helpful to offload the multiplexing to the USB hardware and controllers, I would want to revise the hardware we are deciding on more thoroughly before making such a jump. That said, the option remains to merely implement the first MIDI with SysEx interface (which would be in line with the original plan).
Team’s Status Report 2/14
This week we met with Tom Sullivan and Daniel Zhao to discuss our plans. We decided upon the Terasic DE10 FPGA to begin synthesizing and testing our modules ASAP. Shayaan wrote a saw in Verilog, and visualized it in VCS, as detailed by his report. Jake tried something similar with a square of arbitrary duty. Daniel focused on distinguishing between host versus participant in USB I/O communications between the Waveshaper, PC interface, and MIDI controllers. Jake investigated the on-board codec to decide if it’s suitable for our purposes in live audio.
(A) One public safety concern related to our project is excessive sound exposure. Prolonged exposure to sound levels above 85 dB can cause hearing damage. Therefore, if we include headphone peripherals, it is important to ensure that the output does not exceed safe listening thresholds.
Additional safety considerations include proper power regulation, adequate electrical insulation, and thermal management. Any components that could pose even a minor hazard should be properly enclosed or isolated from the user. By prioritizing these safety measures, we aim to ensure that our digital synthesizer remains safe and accessible to all users.
(B) Musical synthesizers do really well to serve social factors, simply because music is an innately social and cultural thing. People both make music together, and go to venues expecting to hear live music. We use music to help create the cultural moment we’re living in, whether we’re playing or just listening. The Waveshaper’s minimal feature set serves on two fronts: first, the musician is forced to be intentional about the sound they’re making, as there aren’t unlimited tools, and second that this robust feature-set allows a broader set of users to access the device. A more streamlined feature-set means the portability increases, and price comes down, because the hardware isn’t bogged down supporting features not every patch will use.
Secondarily, this project serves as an educational tool. Implementing on a dev-board means that there will be verilog to share. A musician needs awareness of the control-path to make music, but it might be useful for an engineer to see a device that is so explicitly tied up with the concept of inter-connected modules. The musical synthesizer is a very externally visible implementation of very ubiquitous design concepts in hardware. This visibility of path makes it a great educational tool perhaps for extendability.
(C) From the get-go, the WaveShaper was set out to meet particular cost criteria. As a project targeting hobbyists and experimentalists, keeping a low economic barrier to entry was a priority in the design process. This goal was not only considered for the choice of on-board components and associated manufacturing expenses but also in how the device would be used once in the hands of the end user. This secondary aspect is twofold. For one, by ensuring that the ports and interfaces were as generic as possible, a variety of peripherals and computing devices can be used. This opens the door to the use of secondhand markets and even so-called “libraries of things” to customize the user experience. Moreover, we aim to leverage the use of an FPGA and its dedicated sound synthesis as an accessibility feature. To achieve the same real-time performance on a general-purpose computing device in software would be much more expensive and would compete with possibly limited compute and I/O bandwidth for graphics, web tutorials, etc. A less powerful desktop PC, laptop, or even a single-board computer like a Raspberry Pi could be used as the interfacing device.
Part A was written by Shayaan Ghandi. Part B was written by Jake Tarin. Part C was written by Daniel Abujaber.
Shayaan’s Update 02/14
This week, I worked on finalizing the FPGA we will use as the main processing component of our digital synthesizer. We selected the DE10 because it includes 112 DSP blocks, a 50 MHz clock, audio I/O ports, and a 24-bit CODEC. We believe these features are sufficient to meet our design requirements.
I also created a more detailed block diagram that includes our four voices, the communication protocol with the PC, and the audio output pipeline. The diagram specifies the algorithms we plan to use for modules such as the sawtooth oscillator (phase accumulator) and the noise oscillator (LFSR).
Additionally, I began developing oscillator prototypes and successfully implemented a basic sawtooth waveform module that takes a frequency input and produces a 24-bit resolution output waveform. While developing this module, I learned how to view analog waveforms using VCS, which allows us to visualize how our signals change over time.
One public safety concern related to our project is excessive sound exposure. Prolonged exposure to sound levels above 85 dB can cause hearing damage. Therefore, if we include headphone peripherals, it is important to ensure that the output does not exceed safe listening thresholds.
Additional safety considerations include proper power regulation, adequate electrical insulation, and thermal management. Any components that could pose even a minor hazard should be properly enclosed or isolated from the user. By prioritizing these safety measures, we aim to ensure that our digital synthesizer remains safe and accessible to all users.
Team’s Status Report 02/07
On Monday, February 1st, we presented a final proposal for the complete set of features and scope of The Waveshaper. Having decided what we are building, we shifted focus this week onto the beginnings of a hardware-implementation design.
We met to form consensus on a high-level description of what The WaveShaper is to be in technical terms, specifying HDL modules, finalizing the choices for I/O, and defining the black-box specifications (inputs and outputs) for the individual components and sub-systems of which The WaveShaper shall be comprised. Successful divide-and-conquer team dynamics require each contributor to understand precisely how their own work interfaces with the parts a teammate will design
Specifically, this week we decided:
- To implement on an FPGA development board.
- To sample at 44.1kHz with a 16-bit-depth.
- To use MIDI’s user-defined System Exclusive (SysEx) commands for WaveShaper-specific communication.
These questions will lead the design process over the next week:
- Which FPGA development board to use?
- How can we best quantify the signal bandwidth requirements in terms of FPGA area, speed, and extended features?
- What memory solution is best for our requirements?
Of possible interest is the more specific block diagram we made in our first all-hands meeting after the proposal presentation.
Jake’s Status Report for 2/7
This week I prepared for and presented our Project Proposal!
Whilst Shayaan spent time determining which FPGA we should use, and Daniel focused on how we should implement MIDI, I spent my time figuring out what additional hardware may be necessary for the synthesizer. This coming week, I am to decide how the output after the FX channel should convert into L/R stereo ¼” outputs, as well as a driven 3.5mm headphone jack.
The precursory control-path we’ve devised has some details which will dictate the external hardware required. Take for instance, the implementation of our oscillators. We could have a control-path to generate the desired output oscillation, for instance, a sawtooth generated by an accumulator register, and adder. In contrast, synthesizers have also been designed which read pre-computed samples of a waveform from a read-only memory. Each choice enables different advantages. For instance, an “oscillator” reading out samples from memory would allow for the implementation of a “user-bank” where users could send their own arbitrary waveforms to be read-out in playback. However, basic saw, sine, square, triangle function oscillators would suffer from the regularity of the access. Some argue that the use of precomputed values changes the character of the synthesis because you’re getting the exact same value every single time. Yet a wavetable implementation would require such a memory. We will likely move forward with oscillators dedicated to each style: preserving the character of basic function oscillations in a subtractive synthesis, and using memory-indexing “oscillators” to support user-defined waveform readout.
The cost of supporting memory-indexed “oscillation” is offset by the fact we may use the memory for other things too. Among the effects we’ve elected to implement are chorus and delay, which will likely require discrete memory to push parameters like max delay time, without compromising upon our generating sample rate or sample bit-depth. Certain filtration techniques use sliding-window algorithms, which may also benefit from expanded memory capacity. If we somehow managed to skate by without discrete memory for implementing any one of these oscillators or effects, using them in parallel would likely create issues anyway. To this end, one of us will decide which specific memory shall be used when we decide upon an FPGA dev-board.
Now a little about taking the end of the synthesizer’s control path, and forming it into an audio output. Once we have a digital signal ready for output, we need to get the signal analog so that an amp or speaker or transducer-of-your-choice can take it as input. There are a lot of dedicated ICs available from manufacturers to assist in this task: my chief consideration at this time is an audio-codec from Texas Instruments. We’d ensure our output is a well-formed I2S data-stream (a different protocol than I2C, despite the similar name), drive power to chip, and have ready-to-go output for a speaker or pair of headphones. I am unsure whether this will be suitable for a ¼” line out however, any circuitry required for our audio output I’ll have figured out by the end of the coming week.
The TI slide-deck I’m looking at as I consider audio-codecs is available here.