Author: nsaizan

This week we are finalizing our project for demo day. We’ve recently expanded our effects list to include band pass filters, pitch shifting, and echoing. As a result we now have most of the effects we planned on implementing which is a success for us. Before demo day we want to make sure that any amplification to specifically quiet effects is done so that they can all be heard clearly on demo day.

This week I made the framework for a chorus effect module. This effect involves the addition of the original audio with a delayed version of the audio. The delay however is variable, and in this case modulated by a triangle wave. They delay is achieved using a BRAM instantiation since a maximum of 30ms of audio is required. Currently I am in the process of running simulations on the module to make sure it behaves as expected, afterwards I plan on doing synthesis tests to see how it sounds, once I’m sure the datapath is working correctly.

This week I wrote the tremolo effect module and got it working in hardware. When I was planning this effect I considered using a sine wave for modulation, however with our given time constraints it seems more reasonable to use a simpler square wave for modulation. It still creates a cool effect but requires much less time to put together. After testing in simulation I brought the module to hardware and resolved some timing bugs, ultimately making the effect work reliably.

This week was mainly two things: First I was finishing up the midi decoding interface so that we could effectively use it to apply our affects to the audio stream. It has been working very well since then. The other task I’ve begun is starting the amplitude modulation effect. the plan is to use key velocity to create the modulation frequency and to use the after-touch pressure to change the amplitude/depth of the modulation. This way a high energy key press will give a high energy modulation. And the same with a low energy key press.

This week my goal was to make some progress getting our main project code onto the fpga and integrating MIDI decoding into the synthesized code aswell. After wrangling with quartus and pin assignments files I was able to get our code synthesized along with MIDI decoding. Currently I am debugging some timing issues. It seems to read commands as expected sometimes and intermittently mishandles them during other times. I will need to think about various avenues of testing whether it be more testbench testing or potentially using signaltap. I will also analyze the code a bit more to see if I can identify the issues we’re having.

My current testing method involves displaying the pitch and pressure values. They are only displayed when the buttons are pressed.

This week all us us were very busy but we managed to work together to get audio passthrough working correctly. Initially when we setup the device it did not work on the first try. Nearly everything was working as expected except that the DAC was not outputting a signal. We did lots of testing of individual signals and components to isolate the issue. Eventually we learned it was a routing mistake on the pcb, which was easily resolved with a small jumper.

This week we are mainly in preparation mode as the integration part of our project nears and we need to get ready for the MVP demo.

Roshan has been working on the ADC and DAC handlers on the fpga side since the ICs we’ve used utilize a serial bus to send the digital data. He has also continued looking into effects for our MVP.

Nick P has assembled the PCB and done some basic testing aswell as continuing to research FFT implementation options as this is a critical part for some of our more complicated effects.

Nick S has been working on the MIDI decoding module, which has involved testing through the use of testbenches for various sub-elements of the module as well as debugging.

We seem to be on track for a successful MVP by the first demo date.

This week I was very busy finishing up a lab, but I found the time to help Nick P our a little bit with reflowing our PCB, and the majority of my time on this project was spent debugging/testing the Midi Decoding Verilog code. There are still some timing issues which need to be worked out as we begin to integrate, but it seems to be working decently so far. Attached is a screenshot of the testbench output for the module. The compression is pretty harsh, however you’d be able to see a new pitch/velocity pair show up in the arrays as the data is received over a simulated midi interface.

This week I worked on the MIDI Decoding part of our project. My first steps were to being looking at the waveforms of our MIDI keyboard and begin to inspect the actual data it was sending. My goal was to confirm that the information is was sending is consistent with the research I’ve done so far on the MIDI interface.

The above picture is the waveforms generated from both a KEY-ON and a KEY-OFF message. On the left side you can see that one of the bits in the first byte is different. this is consistent with 0x90 for KEY-ON and 0x80 for KEY-OFF, which is a part of the MIDI standard. One of the challenges was realizing that each byte is sent in reverse bit order, and there is a low bit to signal the start as well as a high bit to signal the end of a byte. While the inner byte order is reversed the ordering of byte amongst each other is not.

With this information I was able to begin working on the MIDI Decoding FSM/Datapath. Currently the only messages we care about are NOTE-ON, NOTE-OFF, and AFTERTOUCH. And thus that is why those are the only types of commands read by the FSM. Writing the whole MIDI decoding system out was a little over 300 lines of systemverilog, however I have not had the chance to test it.