Author: theresec

Team Status Report for 4/26/20

This week Adolfo and Tess focused on getting ROM0 games running on the FPGA. Together the worked on smoothing out the final timing and memory bugs that came up when implementing the work around for combinational read on the FPGA. Once Tetris start running, Tess focused on debugging MBC1 and MBC3. Adolfo worked on fixing the small PPU bug that became apparent when running Dr. Mario.

Once Dr. Mario was running, Adolfo took over debugging the MBCs and Tess start updating and creating the final report and final presentation. Adolfo debugged the MBC by creating a small FSM to support the boot rom process, and allowing memory to dynamically adjust the different cartridge and ROM size. He was able to get it working in simulation, but there is still an issue with MBC on the board. Adolfo and Tess will investigate this once the presentation is over.

Additionally, while Adolfo was working on getting larger games onto the board, our on chip memory isn’t big enough to run games larger than 512 kB. To work around this, Professor Nace has given a new board so once we figure out the MBC bug we will move to the new board to try larger games.

Pratyusha and Adolfo setup the SoC on Adolfo’s board, and we were able to transfer and run the controller binary on Adolfo’s board, with controller unit tests passing. They ran into unforseen problem where they couldn’t flash the FPGA without stopping the program on SoC , and couldn’t have the program on FPGA keep running while executing the SoC program. We expected the HPS program and the FPGA program to both proceed simultaneously and talk to fpga peripherals.

To fix this, we first tried to get qsys, a system design integration tool, running on Adolfo’s laptop, but due to a bug with Windows/Qsys we couldn’t run Qsys on his laptop. For this temporary hitch, Adolfo used an RPI to processor controller inputs while Pratyusha worked on Qsys. Now, she can run a program on SoC while flashing FPGA with a different program.

As a team, we will work on finishing the presentation this weekend and preparing for the presentation on Monday. Once the presentation is over, we will focus on finishing the report. Adolfo and Tess will also focus on determining the MBC bug, and then polishing the code and repo.

Tess’ Status Report for 4/26/20

This week we focused on getting ROM0 games to run on the FPGA. This required finding all the small timing and memory bugs that were created by having the memory accesses at a different clock speed. To resolve this, we made our simulation model mimic our hardware model. Additionally, we made as much memory combinational read, meaning an array, to make the transfer easier. Once we were able to get all the synthesis issues and base logic worked out, we got Tetris and Dr. Mario running on hardware!

I spent a majority of the week working on the MBC. I implemented MBC1, MBC3, and MBC5 based on the different documents and reports that people in the community. I worked on debugging through the tests, but towards the end of the week I passed it to Adolfo and started working on the final report and presentation. Due to the refocus, we wanted to make sure we had enough time to implement all the changes. Therefore, I started and lead updating and creating our final report and presentation. Once the presentation is done, I will work with Adolfo to finish getting MBC working on the FPGA.

Goals for next week:

  • Get MBC1, MBC3, and MBC5 working on the FPGA to run more complex games
  • Polish code to match coding standard
  • Finish report

Tess’ Status Report for 4/19/20

This week I worked with Adolfo to get the system onto the FPGA. I was setting up the needed functions on the FPGA through the Megafunction Wizard. We realized that combinational read was not possible using the RAM function so we needed to go back to simulation because our machines can not handle having arrays of that size. So I focused on finding a workaround. Originally we tried using the negative edge of the clock. This worked except in the case where there was a consecutive read and write to the same location. Then we tried giving it a faster clock and that broke our logic. Logically, we knew that the faster clock should work so we looked at the areas that were failing and saw it was a memory to memory transfer, so we adjusted the logic and made small timing changes and we were able to get it to work.

While Adolfo worked on the PPU and the system worked in simulation, the next thing was to support more games. To do this I implemented a memory controller that looked to see which setup the game was expecting. This allowed the games to extend their memory by being able to switch between different ROM and RAM bits. I worked on the controller that currently supports 2 out of the 3 main memory bank configurations. Depending on how these 2 work out, I might be able to get to the third one but that is the rarest of the setups.

Currently, I’m working with Adolfo to get Tetris running in simulation so we can put it on the board. Since our simulation setup matches the one we have on the FPGA, we hope to have everything on the board smoothly.

Goals for next week:

  • Get Tetris, Dr. Mario and a game that uses MBC1 running on the FPGA
  • Polish MBC3 and run a game

Team Status Report for 4/19/20

This week the goal was to set up everything for integration. Adolfo and Tess started moving the simulation CPU onto the FPGA. Unfortunately, they thought that combinational read memory would be available. Tess focused on finding a work around and updating the logic to match. She was able to solve this issue by using a faster clock for memory. Since synthesis takes a long time for such a large project, she updated the simulation model to match what the FPGA would look like.

Since the CPU is essentially done for games that only use ROM0, Tess moved onto implementing a memory bank controller (MBC) so the emulator could support more games. This required creating a controller that controlled memory accesses to a different memory location so the CPU was hidden from the difference.

Adolfo focused on finishing and then perfecting the PPU. Since last week, he polished implementing scroll and fully implemented and tested sprites. Although the PPU was already passing more tests than other emulators, but his goal was to pass almost all of them to clearly pass our expectations. He had to refine his logic because of the timing and memory change, but then he worked on perfecting the display. He is debugging a test that displays a face because it is a hard test that specifically targets all the small details of the PPU.

Additionally, Adolfo set up the registers on the FPGA side to accept joypad inputs. He is now working with Pratyusha to get the SoC to write to those registers.

By tomorrow’s demo, they hope to have Tetris running on the FPGA.

This week, Pratyusha  had two objectives –

  1. To get the USB Controller driver working
  2. To get the SDRAM Nios-2 test running on the board

For 1. Pratyusha compiled modules with an unofficial version of the linux kernel with special flags, and ported over drivers to the board, which after configuration could receive bytes from the controller. For the NES-controller’s controller, she understood the event structures, types and linux/input.h, details linked here, and then composed code to handle multiple presses and releases of the controller inputs, and dealt with variable length packets.

All in all, the end result is as shown here. Each button press and release maps to the respective led being on and off.

2. Additionally, Pratyusha got the SDRAM NIOS-2 test to work on the FPGA board. This means we can copy over information to the SDRAM from the SoC, and read back from it and compare the bytes, to check if they are the same. Still have to implement checking the sums being equal for the bytes on FPGA and SoC.

Goal for this week is to read from USB storage, and write those bytes to SDRAM, read them back and store it on the USB flash.

 

Team Status Report 04/12/20

This week Adolfo and Tess worked on finishing the overall system by running the Blargg test suite. At the beginning of the week they had almost all the components needed to run the tests. After the mid-semester demo, they completed and put everything together. They worked on debugging and fixing issues that came up during the extensive and thorough testing. At the end, they were able to pass all the tests and now they are moving towards putting the system on the board.

Tess is working on getting the entire system on the board. She used the Megafunction wizard to set up memory and is currently compiling the entire system in Quartus. She will be working on getting Tetris running by the end of the week and then she will move onto memory bank switching.

Adolfo also worked on the PPU. His first goal was to display a background. When he was able to display that, he moved on to displaying static images. With this, he and Tess can start debugging on the board because he can display the result on the screen now. After this he worked on scrolling. He got scrolling working, but since our first goal is to run Tetris, he is moving onto displaying sprites.

Pratyusha set up internet on the board to get opkg to install relevant packages. She also detected the NES controller on the board, and is trying to compile the missing kernel modules and load them onto the board, to use joydev a the driver that converts the signals from the USB port to signals that can be used. The alternative to that, would be individually manipulating the latch, clock and data lines on the USB port to the controller, while reading and buffering data, after which we’d have to interpret it.

She also started working on memory component, and is trying to configure the AXI buses on Qsys to be able to talk to the SDRAM. Her goal is to get the unit tests for the NES controller working next week, and move further along on running Qsys and being able to access SDRAM from SoC.

Tess’ Status Report 04/12/20

This week I worked with Adolfo to finalize the CPU so we could move towards getting the project onto the FPGA. At the beginning of the week, we had a self-tested CPU that covered a majority of the tasks and we had a working timer and memory. Throughout the week, we realized we had small issues with the memory so we redid that.

We were able to run Blargg’s test suites, one of our benchmark unit test suites. These tests extensively tested our CPU because they tested each possible instruction with every possible bit location and number. Currently, we are able to pass all the tests so we believe we have a solid and completed CPU.

Now we are moving toward putting everything on the FPGA. We have all the components that we need by using the Megafunction Wizard. Currently, I compiling it in Quartus and loaded the memory with one of Blargg’s test so we can test on the board rather than in simulation.

Goals for next week:

  • Able to run Tetris on the FPGA
  • Start working on the memory bank controller to support more games

Tess’ Status Report for 4/5/20

This week I worked on getting the CPU ready for demo and other components to integrate with the CPU. For the CPU, I worked with Adolfo to finish implementing it. This included polishing the ALU and datapath, and implementing miscellaneous instructions. After we implemented all of them, we tested all of the instructions with written unit tests. We wrote the test in asm and Adolfo found a compiler to convert it to a .hex file that the CPU could read. We now have a working CPU that includes interrupts and supports all the instructions.

The next component I worked on was memory. I wrote the memory controller for simulation that would handle memory access from the CPU and PPU. It gives each section in memory its own magic memory. In additional, it handles cases when the PPU and CPU want to write to the same location. In the memory controller, DMA processing are handled, which is when memory in one area needs to be copied to the OAM area. Currently, Adolfo and I are working on implementing the timer so we can run the tim00.gb test from Moonete test suite.

Goals for next week:

  • Implement entire system in simulation
  • Begin system wide test

Tess’ Status Report for 3/29/20

This week I worked with Adolfo on getting the CPU running. I finished coding the datapath with the parts that Adolfo finished coding and worked on polishing the ISA and signals files. To help our testing, I made a magic memory component for our test based on 18341 P6 magic memory.

While Adolfo finished the ALU and decoder, I started writing basic ALU testbenches.  This would make sure our timing was right, the correctness of our output values, and the correctness of our FSM. We plan on creating more unit tests for our components before using the test suite since it will be easier to control the debugging process with our own tests.

Additionally, I worked on writing the updated risk management plan and Gantt chart. I incorporated how we were going to use the unit tests and test suites to minimize debugging integration. The Gantt chart reflects us removing the audio portion, how we changed our division of labor, and schedule changes due to the transition period.

My goals for next week are:

  • Finish debugging the CPU
  • Incorporate interrupts

Team Status Report for 3/29/20

This week we focused on getting the CPU running and booting the board and transferring files to the SoC. Tess and Adolfo focused on getting the CPU running. They started by finishing the code. A majority of the code was complete but they had to polish the connections between the different components and cleaning the ISA and signals file. Once this was done, they compiled each file individually. Once they could compile each file individually, they compiled the datapath to the magic memory they created based on the 18341 P6. Currently, they are working on debugging it with unit tests they created and they hope to have it debugged by the end of the week so they can incorporate interrupts and the PPU.

Additionally, Tess and Adolfo will need to work on learning how to handle interrupts in the multi-cycle instructions in order to stay cycle-accurate.

Pratyusha focused on getting the board booted up. She established serial connection with the VM and the board. She was able to boot the board with the console version of linux. Additionally , she managed to run a hello world program, configured fpga trough soc and turn on leds. Her next goal is to transfer files to the SoC, look into Memory mapped RAM and controller driver.

Tess updated the risk management plan. The team worked on Gantt chart to include the new risk and mitigation plan created by the remote access situation:

Updated risk management plan and Gantt chart

Tess’ Status Report 03/22/2020

This week we sorted out and finalized what our new project will be due to moving to remote access classes only. We will continue with the original project idea of creating a FPGA Game Boy emulator, but we will no longer support audio due to the lack of access to the lab. We understand that integration will be especially challenging so we will rely even more on the unit test suites and those for the SoC. Additionally, we worked on the SOW to officially refocus the project.

I worked on implementing the datapath for the CPU. A majority of the datapath is coded and hooked up, but I will need to work with Adolfo to assure the signals are correct. Additionally, all of the FSM and signals have been finalized so now we will start integrating the components of the CPU and begin debugging once the decoder is finished.

Additionally, I started looking into “magic memory” that we can use to simulate our CPU before we have memory mapping completed. I looked at 18447 magic memory and 18341 P6. The 18341 P6 will be suffice because it meets our timing requirement and doesn’t require us using segments. To get this to work, we will need to alter the code to work with our CPU and create a .hex file to fake the memory.

My goals for this week:

  • Finish coding the CPU
  • Start testing the CPU with our version of “magic memory”