Category: Status Reports

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.

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.

 

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.

This week Tess and Adolfo worked on implementing the CPU in simulation. They had to polish each component in the CPU and finish implementing all the instructions. Once they implemented everything, they wrote unit tests for each instruction to assure the system worked. Adolfo found a compiler to convert from .asm to .gb to .h so we were able to easily write unit tests.

After this, Tess worked on creating a memory controller that would handle the DMA process and manage access. A majority is done but she still needs to research memory bank switching. Since that was not a priority for getting the overall system running right now, since Tetris doesn’t use a memory bank controller, she started working on the timer. Her and Adolfo are working on getting that finished before the demo tomorrow.

Adolfo also worked on finishing the PPU. He is currently focusing on displaying a background image as the first layer of the display. He has the PPU FSM working correctly and fetcher. He was able to get VGA test running again on the new board. In addition, he was able to upload FPGA files and set pin assignments, which will be make it easier for the team to transition from simulation in the near future.

Pratyusha set up minicom to transfer files to the SoC, in the initial absense of a network and internet for the board. She then set up a network to talk to the board, and ethernet connections on either side (VM and Soc). She also rearranged memory of the VM by booting VM OS onto another linux OS to repartition and rearrange memory. After creating the cross compiled binary of a HPS program ,she scp’d it onto the board, and can now use ssh. The program uses HPS key to light the HPS led. Her next goal is to interpret USB signals from the hub controller, and understand memory mapped RAM.

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

This week, we primarily focused on figuring out how to proceed with the project, what changes we’d need to make, and reevaluated our unit tests. We decided to cut out the audio portion of our project, since we will no longer have access to the tools we would need to get the audio circuitry working.

Professor Nace ensured each one of us has a board (thank you!), so we will still be able to make significant headway towards the project, and work on each individual component of the system independently. However, as a consequence of scratching out the audio functionality, Tess will be working primarily on the CPU, giving Adolfo and Pratyusha more time to work on the PPU/graphics and SOC/Controller-Driver.  Integration is going to be harder since we cannot work on the project synchronously. To counter this, our goal is to come up with fully functional components and good unit tests, to prove that each component worked even if integration fails.

Attached herewith is our statement of work.

Statement of Work

This week our main focus was the design document because we thought that there was no point in working on implementation when the design is not nailed down yet. This turned out to be a good idea since we discovered some oversights that had been made in our previous plan, we refined our plan for the SoC to FPGA communication as it turned out to be more complicated than we originally thought. We will be using the AXI bus functionality offered by our Cyclone V SoC, which allows us to memory map components of the FPGA to the SoC’s address space. This means that we will have to change our memory solution from block RAM to SDRAM. This shouldn’t be too painful given that the timing guarantees of the SDRAM are still much faster than what we require. We still plan to use block RAM as a stand-in while the SoC sub-system is developed.

Thanks to writing the design document, we now have far more detailed architecture diagrams for our system. As a team, we will start implementing each of the subsystems in the next few weeks. Hopefully, we will be able to have a working prototype by the end of spring break or the week after that. We chose this goal to keep us on track to finish on time and with all of our stretch goals.

Here is the overall system diagram that we came up with this week:

 

This week we worked together to finish the FSMs for the CPU. Since there were so many FSMs, we decided to divide them amongst the team members so everyone had a thorough understanding of how the CPU worked and what the control signals would be. This will help make implementing the datapath and FSM easier in the future.

Furthermore each member developed a datapath/system diagram for their individual section (see further description in individual status updates). We now have to work together to understand how they will need to interact with each other so we can set standards for dependencies. This is one of the biggest risks because each part has their intricacies and we don’t want to violate any dependencies.

We had to shift our focus and polish our designs for the design presentation next week. For next week’s report, we hope to have implemented the CPU datapath and FSMs, and begin debugging. Individually, we hope to have our individual parts planned so they can be implemented as well.

This week we worked together on designing the datapath for the CPU, we tried to reverse engineer the datapath based on the instruction timings and known aspects about it. With the help of this reference, we were able to get a datapath that we believe accurately represents that of the Gameboy. We hand executed some instructions through it and they all matched the cycle timings that the Gameboy reference manual specified. Here is the datapath we came up with:

Furthermore, we made a first draft of the FSM for multi-cycle instructions, this is what we came up with:

For next week’s report, we want to be able to have an initial implementation of the CPU and have a testbench for it so we can start ironing out bugs. We think this is important so that we can all start focusing on our areas of the project.