Month: October 2019

I have not gotten as much done this week as I would have liked due to job search stuff. That being said, I worked on a few different things this week. I spent some time figuring out how the ADC/DAC I2S drivers will work, as well as figuring out what manufacturing parameters to order the PCB with. If we use PCBWay and solder the components by hand, the PCB will be quite cheap (~$30). The components that go on it will be another $50. Here is my planning so far for the ADC driver:

The verilog implementation of this driver should be pretty simple.

Additionally, I’ve looked more into how to implement digital frequency filtering and pitch shifting in the Fourier domain. I think that spectral leakage may be an issue with this technique, but that we can mitigate it with some clever processing.

This week my main focus has been bringing up the FPGA’s block ram functionality, as well as creating a reading and writing module for it to interface with the chorus effects module. Intially I went into this knowing about how much storage I would need in order to implement a chorus effect. Using that info I learn how to build a RAM module from the Quartus MegaFunction Wizard. That enabled me to setup the ram the way I wanted. In this case I determined that separate read and write ports on a 2 port RAM would be useful since the chorus effect works by delaying the input sound by various short intervals and recombining it with the original, which means I constantly needed to be writing to the memory as well as constantly reading from several places in memory. These behaviors are what my reading and writing modules are designed to do. They can vary depending on how many channels or ‘voices’ I want to have in my chorus effect as well as how much delay I’d like in the chorus voices. I will begin testing of the module onboard the FPGA next week as well as a doing more work to decode the MIDI protocol on our FPGA. My progress is slightly behind due to my busy job search, however I aim to get back on track as my interviews start to finish up.

This week was continuing to come up with a concrete plan for how to structure the verilog code base.

This was just a rough sketch done in lab, but through the discussion we organized all of the major modules required for the integration phase.

The panning module was written and I started testing and verifying the module. Based on a discussion with the rest of the team and Professor Nace we realized that having some sort of testbench that can use example wav files for the generated data and sending it through the DSP modules will be an efficient way of testing. At the same time we can ensure that our algorithms are correct from a auditory perspective by playing back these wav files and making sure that the sound played is the effect we expected.

This is an example wav file that I have been using for testing purposes. I have written python code that allows us to read the data (stereo) by each audio frame. The plan is to then dump these values into some sort of systemverilog array file so that we can instantiate a driver to read and drive these values into our module for testing purposes.

The greatest risks we currently have as team is the possiblity of our keyboard getting damaged which would be a significant hit to our budget, as well not being able to figure out the math behind some of our most complex effects which potentially involve Fourier transforms. We are managing these risks by using extreme care with out keyboard as well as working hard to set ourselves up to have plenty of time for working with the more complicated effects.

Our overall design has not changed significantly from our initial vision. This is because our initial planning for the system was robust enough that we had considered potential problems like memory for example.

Currently we are still on schedule. One thing we need to do is to purchase the speaker we intend to use for our project. This will be crucial when it comes to real world testing.

This week my two goals were planning the chorus effect, and getting familiar with the MIDI output of the keyboard. For the chorus effect I had many things to consider. For example, I first needed to know how much memory I would need for an effect like this. So by taking our 44.1kHz sampling rate, 2-channel, 16 bits per channel audio, I was able to calculate that we’d need about 176kB of memory per second of audio we wanted to store. Based on qualitative tests in Audible where I tested various delays, I found that about 0.025s of delay between copies of an audio signal was where the effect started to sound unpleasant. So as a result I used this value to calculate that 4.410kB of storage was necessary for this effect. After discussion with the rest of the team we believe that using the onboard block ram of the fpga was the best solution, because we wanted to ensure our SRAM didn’t have other effects that might interrupt echoing’s performance. I’ve been looking into how to infer block ram in SystemVerilog code as well. My plan for the chorus effect is to constantly store the audio stream in my allocated block ram space, and then pull out copies at varying intervals from the stored data, depending on how much delay I want and how many “voices” I want in the effect. I also spent some time cleaning up our top level SystemVerilog module. This involved adding comments and headers for code readability as well as setting up a rough structure for how our effects will be integrated into and enabled within the top level module. The last thing I did this week was start to get a sense of how our MIDI keyboard is actually sending data, and begin to correlate that with the research I’ve done on the MIDI protocol. I’ve attached images of some of the signals I’ve seen. There is a MIDI start command and end command as well as some other data bytes related to the aftertouch capability. start status byte data byte end status byte

This week we appear to be on schedule as the keyboard was shipped very quickly with amazon prime so I was able to begin testing already. Next week I hope to implement a MIDI decoder module in the fpga.

This week, I have worked on finalizing the PCB design. Since last week, I’ve added some extra components, double checked connections, and refined the layout. Here is the finalized schematic design:   

The final PCB is designed to slot into the GPIO connectors and replace the acrylic face plate on top of the FPGA. Here are renders from the top and side views respectively:

I have also completed a BOM for the PCB. For a single PCB, the BOM cost will be about $45. Here is a screenshot of the BOM: