Month: November 2019

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 I worked on updating the display to use the onboard block ram, wrote a new effect, and tried to get the FFT working in simulation.

The reason I updated the display driver is because using LUTs dramatically increased the compile time. Changing it to use M10k was relatively simple.

The new effect I wrote tries to emulate the clipping we were seeing with our older code. It is called the “deep fry” effect.

Interfacing with the FFT seems to be relatively simple. It uses a simple ready/valid interface. But, I cannot get it to compile properly in simulation. I spent all day today trying to get it to compile in various simulation software packages to no avail. At this point, I will either abandon the FFT or try to get it working through synthesis alone.

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 was finalizing some of the bugs faced with bit crushing and panning with MIDI. Additionally I have started the verilog and microarchitecture for echoing which is currently being tested in simulation but will soon tried on the FPGA using the SDRAM chip. The MIDI keyboard will be able to dynamically change the delay of the echo based on the pressure.

Additionally I helped Nick P. briefly for debugging the display controller.

This week we worked on polishing off the MIDI decoder, some simple effects, and the display driver. The MIDI decoder is currently working very well, and we are able to use it to control our effects. The display driver is still in the testing stage, but it will not be difficult to get it to print out more interesting information. Overall we have made a lot of progress this week.

This week, I worked on writing a driver for the display. I started by writing a general SPI driver, and then wrote a higher level control FSM to configure the display. The driver seems to be working well. I plan on updating the driver to print out the current audio signal onto the display.

Here is an image of the test pattern:

 

Since we were able to get audio passthrough working, we each of have been continuing on the other aspects of the project.

Nick P. has been working on researching how to implement FFT in verilog for the complicated effects that need the frequencies of a window of audio. Additionally he has been looking into the screen display protocol since it may be useful for real time hardware debugging.

Nick S. has been working on getting the MIDI FSM decoder to work in hardware. This has been a combination of testing in simulation as well as testing in the board to make sure the essential key presses and velocity changes are working as intended.

Roshan has been working setting up the pipeline for all the audio effects. This includes the now working ADC/DAC modules, the synchronizing registers between the slower and faster clock domains, and the instantiation of the effect modules in the proper order.

This week I have been working on implementing the micro architecture for the effects pipeline.

Since last week we were able to get audio pass through working by hooking up the adc data line to the dac data line within the fpga…this week we actually tested the shifting registers in verilog itself with the dac and adc interfaces. Initially we got extremely noisy audio. However I was able to fix the issue by changing the dac driver to be negedge instead of positive edge since the dac chip samples it on the positive edge.

Additionally instead of doing the native 24 bit audio we changed to 16 bit as defined by our spec and it seems to still have clean audio. Now I am working on setting up the synchronization registers for transferring the audio between clock domains (3.125 Mhz for dac/adc and 50 Mhz for effect processing).

This week I’ve looked into the display driver and FFT more. I’ve tried to compile and run the FFT IP, but haven’t got it working. For the display driver, I’ve begun planning out its verilog implementation and looking at the controller datasheet. The display driver has a simple SPI interface with a few other pins that indicate if we are performing reads or writes and instructions or data. I’ve considered adding a FIFO to make the hardware design of the controller easier, but it doesn’t seem very necessary. The control FSM can be designed such that it only sends data when the hardware driver is ready. Here is my planning document for the display driver so far:

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.