Status Reports

I spent a lot of this week doing experiments with FPGA usage and deciding the best way to design both the wavetable and the delay/reverb modules. In this status report, I will describe the experimentation done, the process this week of designing some of the effects modules, and some miscellaneous items as well.

Wavetable Experiments

I started out the week working on wavetable size experiments, something I wanted to get done as early as possible (as mentioned in last week’s report). Since we wanted to avoid putting the wavetables on a memory external to the actual FPGA chip, such as SDRAM or flash, I wanted to see what the FPGA usage would be if I just put all the wavetables in the FPGA LUTs themselves and create a big combinational lookup table to act as the wavetables. Jens generated a 12-bit, 512 sample sine wave to test this idea with, and the results were a lot better than I thought! It turns out, a single one of these tables uses about 3% of the available LUTs on the smallest Terasic DE0 board (Cyclone III) used by the old iterations of 18-341. I tested with additional tables present, and the number of LUTs used scales linearly. In general, it seemed that the usage was approximately 1 LUT per 12-bit sample. However, I was recommended by Prof. Mai and Ford Seidel to explore using the FPGA’s block ram for wavetable storage instead and it seems like this will be a good solution as well. One big advantage of using the block ram is that the Quartus generated block ram modules are two ported, which will make Jens’s life a lot easier down the line when he makes the wavetable access modules. However, one downside that worries me is that using the block ram will make our design board dependent, since different boards will all have different amounts and types of block ram. While this isn’t a major problem, I had wished the design could be as portable as possible. We don’t anticipate needing to do a radical board change and any board changes will be all in the same Altera Cyclone family.

Reverb and Delay Design

I also started designing the reverb and delay modules this week. The two effects are very closely related at first glance, but are actually quite different in the nitty-gritty. Both involve creating a delay queue where the samples will pop out some number of cycles after the sample is played normally, however the queue for the reverb module will feed back into itself after being attenuated to create an echoey effect and will also be shorter than the queue for delay. Unfortunately, since the sample rate for standard audio is 44.1kHz, we will need to queue up 44,100 16-bit samples in order to create a one second delay. As with the wavetable experiments, I tried to create a quick prototype module in Quartus to see the FPGA usage of a naive implementation of the queue, but it ended up being completely crazy and infeasible (also learning that Quartus will only allow a generate loop to go 5000 iterations before dying). A 16-bit sample queue with a queue depth of only 4096 elements alone will take up 65k logic elements on a board, almost 5 times the amount on the Terasic DE0, and this queue is only big enough for less than a 100ms delay! I was again worried that I would have to deal with the on-board SDRAM and would need to hack up a controller, but luckily, it seems like block ram will come to the rescue again. The Quartus Megafunction wizard will let you synthesize a FIFO structure on block ram, which was awesome to find out, but unfortunately, a 16-bit FIFO of length 2¹⁶, a queue depth that would allow for a maximum delay of a bit less than one second, would take up 64 M9k block rams, whereas the DE0 board only has 56 such block rams. I don’t see an alternative path to implementing delay with any reasonable maximum delay, so this will probably force us to switch from the DE0. Luckily, we already had plans in place to switch to the Terasic DE0-CV, an updated board that is almost identical except for using the Cyclone V FPGA instead of a Cyclone III. The new FPGA has 308 M10k block rams, about 6 times the amount as the old board, while only being a little more expensive as to not increase the total project cost by too much. This has the added benefit of allowing us more block rams to add more wave shapes later on, something that will not take a lot of time or be too difficult, while make the user experience of the synth significantly cooler. In addition to nailing the exact implementation of the queues for the delay and reverb effects, I also got around to designing the other parts of the effect.

Miscellaneous

Finally some other miscellaneous updates. I put in the purchase order for the MIDI keyboard on Monday after lots of agonizing over it being the first purchase of the project and received the keyboard on Thursday. Unfortunately I don’t really have a good place to put it yet so it’s being hidden in the capstone lab. I plan on running some tests with the keyboard, and try interfacing it with the FPGA early next week. A lot of time this week was spent working on the presentation and documentation rather than on implementation, but I’m not too worried since a lot of the planning for future steps was hashed out this week as well. Running the tests helped lock in a lot of important design considerations for the modules that needed to be done, so overall things are running pretty smoothly.

Goals for Next Week

For next week, I aim to finish the complete design of the reverb and delay modules, and hopefully have a Verilog description mostly or completely written. I want to start testing the MIDI interface between the keyboard and the board as well. Since the comprehensive design review report needs to be done next week as well, I will not expect all of these goals to be achieved but I expect them to all be well underway.

This week, we have started diving deep into the design of the project. I worked mostly on the design of the MIDI – FPGA interface, but I also spent a considerable amount of time helping design the wavetables, something not in my schedule.

I researched the MIDI specification and determined the best way to connect the keyboard to the FPGA. While most modern MIDI keyboards send messages over USB, I ultimately concluded that time spent designing a USB controller or fiddling with a USB IP block would not be the most productive use of time and decided that the alternate serial MIDI connection would be better suited for the project. Unfortunately, running with the serial connection has significant downsides. First, the serial connection runs at only 31k baud, which means a full MIDI message will take almost 1ms to send. Second, the MIDI spec requires some analog support circuitry on the receiving end, before the signal can be received by the FPGA. There are examples of such circuitry for use with Arduinos online, but we will need to run tests and tweak the circuitry to work with the FPGA. Finally, not all MIDI keyboards have a serial out and I have spent some time looking for a suitable keyboard online that is both cheap and includes enough knobs to control the effects. My aim is to make the purchase order by Monday. Fortunately, the message will be sent over UART, which will be fairly simple to implement in Verilog, which I have begun doing.

On the wavetable side, we have been discussing within the team what way would be best to store the wavetables. Ideally, the wavetable would have enough samples to minimize interpolation, but having at least 4 wave shapes means the memory usage of the tables can grow to be quite large. We have been discussing and researching several options: putting it on the SDRAM (8MB available), putting it on the flash memory (4MB), or putting it in LUTs on the FPGA itself (15k LUTs total). For the SDRAM and flash memory, we would have to either find a memory controller or write one from scratch, with the SDRAM also having the additional requirement of reloading the tables onto the board every power-on. We would vastly prefer not to write one from scratch, but we are still unsure about whether we will be able to find a suitable memory controller elsewhere. I have been researching options and have been looking for memory controllers given by the FPGA board maker, and have possibly found one that could work. More details about this debate can be found in the team report.

I am a little behind schedule since I had wanted the whole interface to be near completion by the end of the week, but I think after overcoming the design problems that I fleshed out this week, implementation will be straightforward. Next week on the schedule is built in slack for me, so I don’t need to take any special actions to catch up in my opinion.

For next week, I want to have be able to have the interface fully implemented and tested. I am unsure about whether I can get the MIDI keyboard shipped here by the end of the week, so I was planning on using Jens’s keyboard to test the circuit and UART receiver. I also want to run some experiments about wavetable sizes in Quartus and conclusively decide on what way to store the wavetables in the board.