Author: theresec

This week I worked on implementing a majority of the FSMs. After design work, we finally have a framework that we could begin to implement so I started to implement the FSMs based on our datapath. This included setting up the structs that we will need and polishing the timing of certain FSMs.

Additionally,  I attempted designing the mixer for the APU. As I was doing this, I learned more about how sound is synthesized. Due to the primitive nature of the Game Boy APU synthesizer, it isn’t clear how the voice information from the decoder is being translated into a wave that can be mixed with other waves. This leads to what I hope to accomplish by the end of next week:

• Implement and test all the FSMs
• Finish implementing the datapath for the CPU
• Understand how to convert decoded information into a wave

This week I change my focus and prioritized on working on the design report that is due this weekend. After working on the design review presentation and reading the feedback, we realized there were some details we needed to flesh out before moving forward with implementation. While talking about these details, I was able to get a better understanding of how the APU will interact with the rest of the system. The APU is a purely a read-only sub-system so it will not have any write-backs or interrupt complications like the PPU. This will help with planning and designing interactions amongst the subsystems.

Additionally, from the feedback, we went back and reviewed our verification standard and memory storage. After reviewing the manual again, we realized that we needed a micro SD card to act as our persistent memory because although the board has flash capability, it doesn’t have the storage on the board. Therefore, we have put in a request for a micro SD card so we can begin loading the games and looking at the memory transfer protocols. Additionally, we realized that was no clear “block RAM” on the board so we decided to move our working memory to SDRAM.

For the design document, I wrote the introduction, the APU sub-system description, and the project management.

Before focusing a majority of my time on the design report, I had a chance to start outlining the decoders’ access to memory and wrote out what each bit meant for that voice. By the end of Spring Break, I hope to have:

• Written out the decoders for the APU
• Designed how the mixer for the APU
• Implemented the CPU

This week I worked on finishing the FSMs to manage the CPU when there are multi-cycle instructions. Last week, Adolfo and I determined that we would need either one big FSM with multiple branches or multiple smaller ones. We decided to make the smaller ones. I worked on the FSM for the 8-bit ALU operations, 16-bit add operations, pop/push, inc/dec, and CB instructions. Adolfo and Pratyusha are finishing the final 2 FSMs. During this process, I realized there were a lot of flaws in our original CPU datapath so I was updating it with needed connections.

Afterwards, I did more research into how the Game Boy audio works. To save space, the Game Boy had a real time synthesizer because holding an entire audio file in the cartridge took up too much space. There are 4 voices with 5 registers each. Two of the voices are pulse waves that produce the tone. One voice defines the wave shape and the other is used to output white noise. The bits in the register define the voice so each wave needs its own decoder because the bits are in different locations and mean different things depending on which wave you’re looking at. From there, the voices are mixed together and controlled by 3 sound controlling registers. With this information, I was able to design a preliminary datapath for the APU:

With knowing more about the audio, I was able to select and order at DAC. I selected the Monolithic 16-bit AD669 DAC. It is 16-bit with parallel transfer and has a sampling frequency that will be more than suffice for our sound quality. Additionally, it is a through-hole chip, so we need to wire the GPIO pins of the development board to a breadboard. To get the audio into a speaker, we also had to purchase an audio jack breakout board.

Action items for next report:

• Design how the mixer will work
• Read through DAC manual to know what circuit requirements are needed
• Implement FSMs for CPU

This week I worked with the rest of the team to design the datapath for the CPU (which can be found in the team’s status update for the week). Our original CPU design was a two stage pipeline where stage 1 was fetch/decode/execute, and stage 2 was memory. When we learned that all memory accesses use the same memory, we had to rearrange our pipeline. Once done, we were able to add the needed components and connections to match the timing of the Game Boy.

Afterwards, Adolfo and I worked on determining a way to handle multi-cycle instructions. For Game Boy architecture, only 8-bits are sent at a time. Therefore, for multi-cycle instructions, we are continuously receiving new information that is needed for one instruction. To handle this, we decided to use an FSM that would save state for the datapath so it would know which instruction we were handling at all times. The idea is that the FSM will be located in the fetch/decode stage. In the cases of single cycle instruction, it would only enable the pipeline register. In all other cases, it would essentially take the place of the decoder and send the needed control signals. After designing the one large FSM, we realized that it would be cleaner and easier to debug if we had multiple smaller FSMs to handle each category of multi-cycle instructions. We currently have 7 FSMs.

On my audio work, I was researching the different ways we could get audio from the FPGA to a speaker. The first was to use the on-board CODEC that would allow us to directly insert a connection between the board and a speaker. The issue is that the CODEC is dependent on the I2C protocol, which would take significant research, implementation, and testing to assure it is correct on top of the Game Boy audio itself. The alternative is to use a DAC to convert signals for us. This is the more straightforward option because there is no protocol. I have found two DACs that we can potentially use: Monolithic 16-bit DACPORT AD669 and PCM2704CDB. I will continue to look at their data sheets and consult a TA before making a final decision.

Action items for next report:

• Finish FSMs for CPU
• Finalize which DAC we will be using
• Draft an audio datapath