Posted on

Jose’s Status Report for 02/21

I spent this week working on the design/code for the FPGA’s audio codec. The following is split into two portions. The first has to do with the I2C protocol/wires that communicate with the CODEC. It’s impossible to ignore since it’s what needs to be utilized to send out the reset/power/setup write commands. With that in mind, I designed two handshaking FSMs for the purposes of 1. Sending out write commands for initializing the CODEC and 2. Handling the I2C protocol itself (i.e., sending out all the bits of data properly). The design for such FSMs can be seen below:

  1. I2C Protocol

This takes care to respect the I2C rules, particularly modifying the clock (which we provide) carefully when initiating data transfer. Just to note, the design also takes care of the fact that we’re transferring data at 100Khz (while the FPGA’s provided clock is going at 50Mhz).

2. Sending out commands

While the register we’re writing to is the same for all of these (address 0x34), the commands being sent all have unique hex values.

This was coupled with the actual interface with the CODEC, which was much simpler to implement since, apart from feeding the necessary clocks, data transfer is done through a parallel shift register.

This leads to an overall interface that looks like so:

Once all of that was done, I focused on setting up Quartus on my laptop for actually putting the code onto the FPGA and begin testing. While arduous, I got the pins set up and the entire system set to begin doing the previously described work next week. 

My progress is on schedule, as I’d marked this week for developing the initial design/code for the system and next week for debugging/testing the code as necessary. With that in mind, I hope to get a system in which some sort of audible noise is heard next week implemented on the FPGA itself (now that my Quartus is set up properly).

Posted on

Mihail’s Status Report for 2/21

This week I focused on implementing the RTL for the frequency modulation component of our digital synthesizer and began planning the ADSR envelope component.

For the FM component, I implemented a 24-bit phase accumulator to track the phase of the waveform. The circuit takes in a tuning word representing the carrier frequency, a modulation signal, and a scaling factor. It then uses them to update the phase accumulator every clock signal, outputting the modulated phase, which will then be used for wave table lookup. FM computation is coupled with the phase accumulator, so that we can ensure consistent behavior across output types.

Additionally, I began planning the ADSR envelope generator, mainly sketching out the finite state machine for the system. I also began writing Matlab scripts so that I could test simulation output of the FM component against a reference model, but had to spent most of my time brushing up on the language, since it has been about two years since I had used it.

Next week, I hope to verify the RTL for the frequency modulation component, sketch out the data path for the ADSR module,  and begin implementing the RTL for it.

Posted on

Kaloyan’s Status Report for 02/14

This week I worked on determining our solution approach for how to represent the audio we will be processing.

One option is to make no noticeable change, and just treat every number as a standard int interpretation (similar to how something like C would do it). This is beneficial because of its simplicity, and will require fewer hardware resources, since all the arithmetic is already provided with FPGA primitives.

However, this may cause problems later down the line. Since our CODEC works from an I2S protocol with 24-bit precision, and it expects amplitudes in the form of -1 to 1, we would have to do some conversion at the end. Alternatively, we can adopt a fixed-point notation to represent this amplitude range. Namely, Q 1.23 provides one sign bit and 23 fractional bits, allowing us to represent the range of -1 to 1 nicely. However, this comes at the additional cost of extra hardware to instantiate the proper arithmetic. The engineering effort is relatively low, since there are already Verilog libraries for this kind of work, but the hardware utilization will still be higher.

Ultimately, we favored the Q1.23 form. I also worked on the block diagram for the design presentation, and am excited to start working on the RTL next week!

Posted on

Team Status Report for 02/14

No changes were made to the overall design this week, and so far there are no significant risks involved with the project. As a team, we worked on getting the design proposal presentation ready, which included adding specifications for design requirements and the like. While our testing and solution methodology did not change, we were able to expand on the ideas we were establishing last week (one significant one was fixed-point representation for our signals, allowing for low latency and faster calculations over floating point operations). Our overall schedule has not changed apart from José’s focus beginning with audio output first and then going to MIDI interfacing (swapping the order). Here is an overview of the updated schedule:

A was written by Mihail Alexandrov

B was written by José Cestero

C was written by Kaloyan Stefanov

Part A:
The FPGA synthesizer processes all data digitally on a single device, avoiding high-voltage analog circuitry and therefore reducing the risk of electrical shock to users. This, along with prolonged exposure to high intensity audio output, are the two main health considerations in the project. We’ve discussed controlling output audio amplitude as a solution to the second issue. In terms of safety, the synthesizer operates at the low voltages characteristic of FPGAs and provides deterministic behavior due to the digital architecture, limiting failure points and reducing the likelihood of unexpected faults that could lead to safety risks. With respect to welfare, the project promotes accessibility to music creation by providing a lower cost, reconfigurable alternative to traditional synthesizers that could be adapted for both learning environments and creative expression.

Part B:

Our FPGA synthesizer will be made to take in input from an external MIDI keyboard, yet its internals will be made in a way such that all the processing is done on one singular component. This means that the external input device can be modified as we wish (while the internals stay the same), meaning that those who are impaired could use musical devices in ways that they normally could not. It expands the range of people who can produce digital music (and even invites the opportunity of having more disabled artists in the music space). This, moreover, relates to the fact that the device is meant to be low-cost and reproducible. While this relates to its economic factors, it also has to do with the fact that simply more people can express their cultures through music without any barriers. It all results in a long-run effect of democratization of musical production, such that musical communities become larger and cultural representation is broadened.

Part C:

Our FPGA synthesizer is aimed to be low-cost, providing a hardware alternative for those interested in electronic music but lacking the means to acquire a hardware synthesizer. By relying on an FPGA, we also provide users with ability to create modifications and improve upon the existing design. This makes the synthesizer even more economically viable, as we can provide updates to the actual design as development continues, providing users with a continuously improving product. In comparison, analog synths lack this reprogramming, making it difficult (if not impossible) to change the product once it’s been released. Indeed, one can envision an FPGA “music box” which can be configured in a multitude of different ways (guitar pedals, audio effect rack, etc.), a much cheaper hardware alternative compared to buying all these analog devices.

Posted on

Jose’s Status Report for 02/14

This week I focused on primarily two things (apart from the design presentation, of course). The first was designing a system for receiving data from the MIDI shield, while the other was beginning to investigate how we’d get audio to output through the use of the DE10-Standard’s builtin 24bit CODEC. 

Regarding the first, I was investigating how the SparkFun MIDI shield outputted data being processed from the MIDI DIN cable.Serial Selection Jumpers

The board features the opportunity to select between hardware and software UART. For the purposes of the actual FPGA, we’re interested in selecting hardware UART (which is enabled by default). Software UART, however, is going to be useful when debugging how the FPGA is processing inputs, since further research revealed that connecting it to an Arduino would allow us to use the library developed by SparkFun to see how input should be properly interpreted (using Serial.print()). 

With this in mind, I knew that the hardware UART configuration would output data utilizing the standard MIDI message format as outlined here: https://www.songstuff.com/recording/article/midi-message-format/. This led to me writing up an FSM for parsing MIDI data as outlined here:

 

This is primarily designed for status messages sent out by the controller that contain two bytes, which are:

0x80: Note ON

0x90: Note OFF

0xA0: Poly Pressure

0xB0: Control Change

0xE0: Pitch Blend

The FSM will be waiting until one of these status bits is sent, storing it in a register and then transitioning to waiting on the two information bytes. If, at any point, a valid status byte is sent out, we transition back into waiting on the 1st byte. Once two data bytes are sent out, we transition into the TRANS_MESSAGE state (where the actual command will get transmitted onto the FPGA). This leads us going back into the GET_1ST_BYTE state, repeating the process all over again. This is a high level representation of what I’ll be trying to implement soon, so the design can (and will probably) be tweaked as needed.

After this, I began researching how the DE10-Standard’s audio codec worked. It supports 24-bit audio, utilizing a 2s complement format. Interfacing with it would require dealing with its I2S interface, utilizing a parallel-to-serial shift register (shifting out bit values one at a time). As I was going over the design for this and the MIDI interface, I realized that the most important baseline for setting up the project is the audio. My partners need a way to test out that their initial implementations are working properly, which means that I should focus on this first. While I’m still on schedule, I hope to complete a functional audio interface with the FPGA next week and then work on the MIDI interfacing afterward (essentially swapping the schedule for both tasks). Overall, though, I have a solid idea on how to move forward with implementing the designs for both.

Posted on

Mihail’s Status Report for 02/14

This week I spent my time with the team, preparing the design presentation. I spent much of my time focused on the solution approach for the FPGA internals, particularly our audio processing pipeline. Additionally, I worked on creating a plan for testing and verification, looking at how we could numerically compare our digital output to a golden model, and responded to some feedback from the TA regarding the presentation. After next week’s presentations, I hope to get started on implementing the RTL for the frequency modulation and applying the ADSR envelope.

Posted on

Mihail’s Status Report for 02/07

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.

Posted on

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.

Posted on

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.

Posted on

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:

  1. High bandwidth (with a full speed of around 12Mbps)
  2. No external hardware necessary (meaning that the USB can directly interface with the FPGA)
  3. Non-deterministic timing (USB communication is based on sending packets of information, which may need to be polled at times)
  4. 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:

  1. Lower bandwidth (a full speed of ~3.1kB/s)
  2. External hardware necessary (ideally, can just use a MIDI breakout board)
  3. Deterministic timing
  4. 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:

Amazon.com: Monoprice 606607 MIDI Keyboard Controller - Black, 49 Key | Pitch-bend & Modulation wheels, Driverless plug and play for Windows and Mac PCs - Stage Right Series : Musical Instruments

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:

MIDI Shield Arduino R3 Shield Project Kit

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.