This week I worked with my teammates on the project proposal presentation. In particular, I assessed requirements for the audio quality, such as determining latency and SNR thresholds. I also came up with guidelines for testing, and worked directly with my other teammates to put in the product orders for the project. Next week, I hope to continue planning out the project for the design presentation, particularly to focus on the block diagrams / hardware design for audio processing inside of the FPGA.
Team Status Report for 02/07
The team worked together this week discussing project requirements and whether some goals (drum playback) were too ambitious for the project. Overall, we determined that we’d keep the goals as is, since initial research from everyone revealed that some goals (like MIDI keyboard input) could possibly be completed earlier, allowing for some more leeway in the case that things go wrong. While we have been discussing initial system drafts, our plan is to work on block diagrams next week for our high level vision of the design. This aligns with our schedule outlined in the gantt chart, such that no changes are envisioned. Our general proposal and set of features stays the same, and we’ve begun gathering the materials for the project (DE10 Standard FPGA and MIDI Keyboard) in order for us to kickstart both the design process and initial implementation steps next week. The biggest risk for blocking progress as of now seems to be our team’s lack of DSP experience. Learning some of the techniques and algorithms for filtering, then, could potentially cause us to spend more time on planning/designing some sections of the project. In the case that this happens, our plan would be to dedicate extra time (~3 hours a week) into reviewing content from 18-290 more in depth and implementing algorithms in simulators like Matlab in the case of confusion.
Kaloyan’s Status Report for 02/07
This week, I worked with my teammates on our proposal presentation. I designed the block diagram and solution approach, along with working out what audio effects we would implement and coming up with the idea for an additional drum track. For next week, I’m looking forward to working on the design presentation and figuring out the more technical aspects of the RTL, along with beginning to write the RTL for the wavetable generation.
Jose’s Status Report for 02/07
Most of my work this week involved researching what components I wished to use for the MIDI input interfacing with the FPGA and how I would get them to work together (at a high-level, of course). There were two main options for MIDI input, and that involved either using USB or the dedicated MIDI DIN cable to connect with the FPGA. My research yielded that these come with their own benefits/tradeoffs, being:
USB:
- High bandwidth (with a full speed of around 12Mbps)
- No external hardware necessary (meaning that the USB can directly interface with the FPGA)
- Non-deterministic timing (USB communication is based on sending packets of information, which may need to be polled at times)
- RTL necessary for interfacing would be much more complex, since I’d need to account for different channels, timing, and more complex state control
MIDI DIN:
- Lower bandwidth (a full speed of ~3.1kB/s)
- External hardware necessary (ideally, can just use a MIDI breakout board)
- Deterministic timing
- RTL necessary would be much simpler (since DIN MIDI is byte-serial and self-clocking, meaning that error handling is less complex)
With all this in mind, I chose to approach interfacing on the FPGA through the use of MIDI DIN. My logic for such was that the interface will be pivotal for testing all the wave generation and sampling we produce, so going with the simpler option would allow for us to begin testing as early as possible and better guarantee that we have some sort of working product on time. Moreover, if I can save time on interfacing, that means that I could spend more time on working on filters and adding drum sampling features later on.
Once I decided on using MIDI DIN, the next step was beginning to figure out what keyboard I’d use (that had that output port type) and how I’d properly interface with it/the FPGA. I ended up picking the following keyboard:
This is the MONOPRICE 49-Key MIDI Keyboard Controller, which has enough physical buttons and features to implement the functions we want to. Moreover, it contains both USB and MIDI DIN output (in the worst case where I decide on pivoting back to USB output). Because this was available on the ECE Parts Inventory, it was also a wise decision since it allowed us to save on budget for other expenses, like the MIDI DIN breakout board.
There were many options for what I could use when interfacing with the keyboard, but my research ended up pointing to the SparkFun 12898 MIDI Shield:
This component, while being in stock on DigiKey, has detailed documentation for processing input/output. Apart from that, it has deterministic output, making parsing key data much less complicated. The other option would have involved assembling a decupler circuit (either using a PCB or physical board, which would likely create complications further if physical failure needed to be debugged). This leaves the high-level interaction between the keyboard and FPGA much clearer, since it’d involve connecting the keyboard to the MIDI shield, and then have the shield communicate with the FPGA. We’d just need to solder the connections, which is not complicated.
Overall, I feel like I did good progress researching this week, and am left with a clear direction on what to keep pursuing next week. Now that we have an FPGA from inventory, my plan is to begin developing the VGA interface on hardware and start developing code for parsing output from the MIDI shield (which will be ordered soon). I can say that everything is on track, and no time has been wasted.