Category: Pratyusha Status Report

And we’re done! This week, I worked on building a qsys project for the SDRAM controller from scratch to integrate memory management and attempt game switching on the FPGA.

By the end of the project, for the SoC, we have the controller driver working, SoC and FPGA running simultaneously, as well as the SDRAM (Nios ii) tests working! That comprises the unit tests, and while we got FPGA, SoC to run programs a the same time, we only couldn’t integrate game switching with fpga.

For the rest of the time, I worked with Adolfo and Tess on the final report and demo video, and added my project and code samples to the repo.

You can find SoC code and resources + code with documentation at

https://github.com/tchannn/Game-Boi/tree/SoC

Thanks!!

This week, I worked on integrating the HPS controller code with FPGA program. I created a guide to do the installation and porting over of code to the SoC, and we were able to transfer and run the controller binary on Adolfo’s board, and the controller unit tests worked on his board.

Adolfo and I ran into unforseen problem where we couldn’t flash the FPGA without stopping the program on SoC , or 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, they used an RPI to processor controller inputs while I worked on Qsys.

I managed to integrate the HPS and FPGA parts of the board, with programs running on each of them, through understanding, working with, and writing a program on qsys. Now, we can run a program on SoC while flashing FPGA with a different program.

I also worked on the final presentation and delivery of the same.

 

The first thing I did this week was to get internet (WiFi from MaC) working on the board, so I could use okpg (the Angstrom package manager) to install basic commands and kmod.

Then, I tried meddling around with connecting the NES USB controller to the board, but I couldn’t see any additions in /dev/input. To start simpler, I acquired a wired mouse, and added it on the second port, though couldn’t find it either. However, lsubs and fsdisk showed the devices.

After figuring out which device was the addition, I looked into the events in /proc/bus/input/devices and found the mouse event. It then also appeared in /dev/input.

I later realized that the NES Controller wasn’t going to appear in /ttyUSB* because it wasn’t a serial device, and thus the approaches outlined in here  wouldn’t work.

After isolating the character event through dmesg and simple hacks like printing out system state at various points of plugging and removing the attached device, I couldn’t read legible data from the device.

The kernel modules that would’ve made it easier to read the usb input weren’t compiled into this distribution of the Angstrom kernel.  So I tried to compile the missing kernel modules that would enable me to read human-readable signals, (modules – xpad/joydev). I am currently attempting that.

In the meantime, I have started reading up accessing the SDRAM. I will use a USB storage device to store memory instead of flash (or so is the plan, for now), because the board is still booting off of the Linux console version on the flash storage media (mirco SD card), and as far as I can tell, the guide doesn’t have a way of flashing the board, but I’ll keep searching for one. It is not a priority if the USB storage device can store persistant memory.

However, I’ve to understand how Qsys works, because from the SOC community, it seems like using qsys to initialize the AXI bridges is the best way to communicate with the SDRAM on the fpga side. I don’t have a Windows machine, and System Builder needs a Windows machine to generate the basic template (figuring that out).

Goals for next week include getting further along with saving data from USB storage to SDRAM, and making sure data integrity is persevered. I also hope to get NES controller unit tests working.

 

Some relevant sources:

• https://www.raspberrypi.org/forums/viewtopic.php?t=160400
• https://stackoverflow.com/questions/15949163/read-from-dev-input
• https://stackoverflow.com/questions/3737655/reading-usb-input-stream-on-linux
• https://forums.nesdev.com/viewtopic.php?f=9&t=19698 + latching????
• https://stackoverflow.com/questions/3737655/reading-usb-input-stream-on-linuxhttps://stackoverflow.com/questions/15949163/read-from-dev-input

The goal for this week was to set up a network, a way to transfer files, run a c program that uses the fpga peripherals, and have a program for the controller to talk to the soc.

I spent  the initial phases of the week setting up minicom and transferring files. Ideally, I’d be able to scp files from the linux vm to the board and vice versa, but there was no means of setting up a network, which is why I ordered the ethernet peripherals.

In the meantime as a backup, I set up minicom. Since the board had no internet or network, there was no way of downloading any software onto and any other source of obtaining files other than direct serial com, I had to figure out a way to transfer files that didn’t involve xmodem or another decoding service. After much trial and error, I decided to go with base_64 as a primitive decoding service to transfer basic c files.

I then set up cross compilation and download intel fpga embedded suite which didn’t have a lite version as claimed in the guide :(. However, I found out about community version that some older versions came with and got it installed instead, and fixed issues with paths and root permissions as ece341.

Unfortunately, the ece341 VM comes with the memory portions pre-segmented and frozen, though I gave the VM extra gigs, it went towards an unallocated pool since the swap memory followed the /sda disk space. I installed gparted and though possibly jank, booted the ece341 VM onto the linux OS image that acts as host for gparted, and reassigned disk space by manually moving the swap memory placement. This took me quite a while to figure out.

Today, finally managed to set up ethernet connection. Getting right parameters configured, understanding network interfaces and different parameters, /etc/ folders relating to startup scripts and network and device dir, various commands relating to networking..

Now i can scp files, and set have run scp’d a c file compiled binary that I used to talk to the HPS peripherals.

Goals for next week include receiving signals from the USB hub and looking into Memory mapped RAM and game state saving.

 

 

03/28

This week, I focused on flashing the micro sd card and booting the board.

I chose to work with the console BSP instead of the LXDE version. This is because the former is more lightweight, and (in theory) should be all we need to run a program that doesn’t involve SOC graphics. It is slightly harder to configure than the Linux Desktop that connects the different FPGA peripherals with the SOC.

I managed to boot the board with the console version and ran a hello world program so far. I’m figuring out how to transfer files to the SOC.

The guide on the terasic website details setup on a Windows machine. I faced some challenges along the way, such as using mac and linux instead of windows for each of the steps to get the img configured and running on the board.

This involved installing putty and figuring out device manager and communication settings Windows equivalent on Linux. I also had to expand the partition space to be able to fit more programs on the micro SD card.

I had to figure out how to load the config .sof files and configure the soc with the default settings to be able to talk to the fpga peripherals and set up the bridges to talk to the fpga. This wouldn’t be a problem if we used the linux LXDE image/deskop, because it comes with the default settings, but is also much heavier than the console version for the purposes of this project.

All in all, there isn’t much documentation for using linux VM/ mac for setup and it was interesting to search for other resources and try options that didn’t work for booting the soc.

Update 02/39

Ran a hello world program, configured fpga trough soc and turned on leds. Next goal is to transfer files to the SoC, look into Memory mapped RAM and controller driver.

 

After spring break, I worked with the team on alternative project ideas. We considered switching to a software emulator, and I began looking into the requirements/languages used/ benchmarks, etc. I also looked up sample projects and test suites.

However, after Jens mentioned Professor Nace would potentially ship us each boards, we collectively considered and are now scrapping the audio portion of GameBoi.

I thought through tests to verify that the game switching and controller driver work.

As mentioned in the Statement of Work, (taken from the SOW)

“since the SoC will house the persistent memory, it will hold game state and will need to transfer the game bits depending on the game that the user wants to play. To check this, once we transfer the bits, we will sum all of the stored bits in both the FPGA and persistent memory. If the sums are the same, we can reasonably assume that none of the information was corrupted. Additionally, we will attempt to read in a game to the FPGA, then the FPGA will read the information back to the SoC untouched. If the bits all match, then we have proven that two way communication between the FPGA and SoC are correct. To test our game switching, we will run the above test consecutively, but use a different game in each iteration. “

“To test the controller driver, we will map each button of the controller to an LED. The LEDs that correspond to the pressed buttons must be on until the buttons are released. This will prove that we are able to receive the right signals from one or more buttons of the controller at any time. “

I (hopefully for good) sorted out connection problems between my VM on mac and the DE10-Standard Board. I managed to run a simple program on the DE10-standard board.

I was debating between using a Linux Desktop Environment and a Linux Console BSP, but I’ll probably go with the latter, as there seems to be no need for a Desktop Environment.

I am waiting on an SD card to be able to flash the image onto the card and the SOC.

For the upcoming week, I hope to

• Get the ConsoleLinux booted onto the SOC
• Run a basic MMIO program such as writing to the LED/ using switches to communicate to LED through SOC
• (Stretch) Reading button presses from NES controller.

This week, I spent most  of my time understanding the different types of memory on the board, writing the design document, as well as helping with the CPU FSMs. While working on the document, I realized I needed to read more into the SoC and how it integrates with the FPGA and controllers.

I worked on the introduction, memory management, qualitative requirements and SoC sub-system parts of the document.

Since the bios on the SoC has a way of interacting with the USB port (to say, decode NES Controller signals), the next question is figuring out how to get the SoC to talk to the FPGA. We plan on using the SDRAM on the FPGA, using it as MMIO accessible by SOC else, we are going to resort to the FPGA using DDR3 memory on the SOC. I am also looking into the HPS-> FPGA bridge tonight, and will have a more conclusive approach.

Here are the two manuals I am cross referencing at the moment:

Hard Processor System Technical Reference Manual

DE10 Standard User Manual

Meanwhile, SOC has access to the flash memory, can load and store game state.When a game switch happens, the SoC will let the current screen finish rendering and then stop the CPU’s execution. Once the execution is stopped, all of the CPU’s state and the memory will be saved for later re-execution, in flash memory. Afterwards, all of the state will be cleared and the new game state will be loaded in from flash to SDRAM.

By the end of Spring Break, I hope to have:

• A way of manipulating memory through SoC and FPGA
• Help with implementing CPU

 

This week I worked on understanding the different parts of the DE10 Standard Board, and going through the manual. I also tried setting up my laptop with the board (still ongoing), and procuring a spare windows laptop just in case.

I’ve been looking into how memory works on the game boy, and memory/storage specs on the DE10 Standard Board.

Memory on the GameBoy:

Here is my understanding of the important parts of memory mapping on the game boy/boi. When the Game Boy first boot’s the bottom 256 bytes of memory is occupied with the boot ROM.

Once the Game Boy is done booting, it unmaps the boot ROM from memory. Then the to address 1-> 0x3FFF are occupied by game code loaded in from the cartridge. Inside of this memory are the interrupt table and the cartridge header area. I’m not sure how flash interacts with this cartridge header area, and I’m going to discuss my interpretation with my teammates tomorrow.

The remaining sections of memory are the tile ram (0x8000 – 0x97FF) which  contains data about the graphics that can be displayed to the screen. The Game Boy uses a tiling system for graphics meaning that a game doesn’t control the specific pixels that get drawn to the screen. The placement of tiles at certain positions happens in the “background map” (0x9800 – 0x9FFF).

Next up is Cartridge RAM. I’m looking into whether or not the games we load need this, (0xA000 – 0xBFFF) Cartridge RAM. Since we don’t have the external cartridge, might have to specially map this to some other section of memory.

(0xC000 – 0xDFFF) is Working RAM; it’s function is as you’d expect of working RAM  and (0xE000 – 0xFDFF) is Echo RAM.  This section of memory directly mirrors the working Working RAM section.

0xFE00 – 0xFE9F: OAM (Object Atribute Memory) – Used for special characters (sprites). 0xFEA0 – 0xFEFF: Unused – This area is completely unmapped: reading from it just returns 0s and writing to it does nothing.

0xFF00 – 0xFF7F: I/O Registers

0xFF80 – 0xFFFE: High RAM Area

0xFFFF: Interrupt Enabled Register

Other notes

In total, the above Memory mapping amounts to 64 KB, and we have 1 MB of persistent storage that we can use through the Mircro-SD slot. So we’re more than covered for game switching / random hacks that we may need to put together for our gameboi to work. I am amazingly shocked by how much memory was allocated per game… a mere 64 KB!! Either ways, we have more than enough RAM to work with, considering the 64MB (32Mx16) SDRAM on FPGA, 1GB (2x256Mx16) DDR3 SDRAM on HPS and the MicroSD Card Socket on HPS. Since game switching requires persistant storage, I was thinking of storing the different game states in the Micro SD card Socket, and a table that knows which game maps to which section of memory in there too.

Meanwhile…

I looked into other DE10 Standard Projects, to understand how they employed memory. I also found a project , part of which could be done as a warm up to understand the board better.

I will also be working on some of the CPU Fsms before tomorrow’s group meeting, and have a discussion on whether DDR3 SRAM or the standard RAM is better to use.

 

References:

https://github.com/AntonioND/giibiiadvance/blob/master/docs/TCAGBD.pdf

https://gekkio.fi/files/gb-docs/gbctr.pdf

This week we worked on designing the datapath for the CPU. We currently have a two stage pipeline with fetch/decode/execute as stage one, and memory as the second stage. We went through each instruction and used a couple of references such as Gekkio’s Game Boy manual and the original Game Boy handbook to figure out the datapath.

I then worked on the datapath for the CPU. It was hard to get started because I am not as familiar with system Verilog, considering I haven’t taken 18-447 (currently registered for the same) and/or 18-341, but I’m hoping to learn more through capstone, and my teammates. The biggest challenge was figuring out the overall structure of the modules for the CPU, and how to represent pipelining via Verilog code.

I have started looking into  memory mapping for the FPGA, and hope to have more details fleshed out for switching game state in time for the design review.

Action items for next report:

• Memory mapping for FPGA
• Controller and flash drivers