Author: aspauldi

Over the past few weeks, I’ve focused on understanding and implementing a kernel driver for our system. In our original schedule, this task was supposed to take around a week. That has turned out not to be the case due to me running a bit behind and complications with the implementation of the kernel driver.

 

What I do have, is a user space front end to the controller kernel driver and a kernel space driver file that has not been compiled yet. Theoretically, this should work fine, but I have been unable to compile the kernel module due to complications with building against the pre-built kernel provided by Terasic. As far as I can tell, they do not provide the tools necessary to build against the provided kernel, and so a new one must be built from scratch and supplied to our board. I’ve begun this process, and hope to have the kernel built and booting by the end of today. If all goes well, I’ll be able to jump straight into testing the controller module tonight/tomorrow.

 

Due to the excessive and frustrating amount of time it has taken to write my first kernel module, audio has been pushed back to the body of this coming week. I don’t anticipate audio taking much time, as Joseph has a firm understanding of what would be the hardest part (communication with DDR3 and the cpu). Aside from this, it will be a relatively simple FSM that reads from memory and sends data to I2C. I believe the driver will be simple as well, considering I’ve learned some useful tools while reading up for the controller driver (ex. I can create a device file and arrange it so that the write system call sends samples to the kernel driver).

 

Once audio has been finished, I’ll be working on the sprite engine.

 

Drafts of the user space and kernel space implementation of the controller driver are available here:

https://drive.google.com/file/d/1LZ3EGkWE5TbSmbO2-qg8U7c6oalinqTu/view?usp=sharing

This week, my main task was to create the memory mapped I/O necessary to send controller input from the FPGA to the ARM core. In our design, we chose to use the lightweight AXI bus of the Cyclone V FPGA to accomplish this. Additionally, I set up my FPGA with a linux image that allows for a UART console and wrote a brief controller read program to test the communication. Finally, I set up an ARM cross-compilation development environment on my computer, using the arm-none-linux-gnueabihf library provided by arm, in order to compile the controller test program.

 

Under the current settings, the controller input is available to the ARM core at the base address of the lightweight AXI memory mapped I/O space (address 0xFF200000). The controller test uses /dev/mem to mmap this address into its address space and read from it, then prints the results to the console.

 

Due to my unfamiliarity with qsys, the process of bringing up this communication took longer than I expected. When all was said and done, I did manage to get communication working, though I ran out of time and was unable to finish the controller section of our interface (which would require wrapping it in a kernel module which has a call safely exposed to the user and definitions to ease in parsing buttons). Due to this, I’m slightly behind, but anticipate being able to catch up again next week.

 

A video of me running the controller test is available here: https://www.youtube.com/watch?v=jU2mdtBN-I0

 

The controller test:

https://drive.google.com/file/d/1U8mn_7gTbG2sWP3rkUN0vx-6YtHiBfZu/view?usp=sharing

This week, I documented the internal structure of the audio and controller modules, and created block diagrams for those modules. I also detailed the controller FSM to aid in the implementation of the controller module.

On the subject of the controller module, I implemented and tested that this week. The protocol has been detailed in previous reports, but essentially the module is a timer running at 60Hz and a clock divider that generates the clock for the controller. Once the timer fires, the FSM waits to sync up with the controller clock and then begins the input request protocol. As discussed before, the controller is wired over GPIO. In the tester, the current input state of the controller is displayed on the LEDs of the DE10-Nano. Since the DE10-Nano only has 8 LEDs, and the controller state is 16-bit, a switch 0 is mapped to switching between the MSB and LSB of the controller state. After a few bugs and re-familiarizing myself with system verilog, it works like a dream. The LEDs lit up in response to my input apparently immediately. Unfortunately, a few of the wires for my controller port fell apart while I was moving the board, so I didn’t get the chance to capture video of the demo (at any rate, the LEDs are small and probably won’t show up well anyway).

I’ve attached the controller and audio diagrams, as well as the controller module implementation and test source code. Note that we’re managing our code on a private github, and the tossing of zips is just to ease distribution over our blog.

Diagrams:

Audio

Controller

Controller test source code:

https://drive.google.com/file/d/1dZzLapQ6Y364X1jte-TLIdnNxRoFoYm6/view?usp=sharing

This week, aside from helping with the presentation and discussing the overall plan with Joseph, I worked on research for the Audio, Input, Software, and Communication systems. I’ve attached a copy of my notes.

Suffice it to say, the current plan for audio is to have a single channel of 8-bit PCM audio and 32KHz, which will be representative of the GBA in sound power. Note that our users will be able to produce better sound, as they aren’t bound to a 16MB cartridge, though. Audio will be output by sending samples supplied by the CPU over I2S to the HDMI output. The interface itself hasn’t been designed yet, as I’m not sold on how it should be done specifically, so I’m a touch behind. I plan to get that done as soon as possible, and I’m confident I can be back on track by the end of next week.

For input, we plan to use a SNES controller over GPIO. I go over the details of the SNES controller communication protocol in my notes. It’s a simple protocol thats clocked well below what our FPGA will be clocked at. It should be relatively simple to bring up, as long as we can find controller ports.

For software, I took another look at the C standard and realized that our requirement of providing it to the user is completely infeasible if we are also creating our own kernel. The C standard has a lot to say about what an OS should provide, and we won’t be providing much of it. I’ve narrowed it down to a useful subset, which is listed in my notes.

For communication, I spent way too much time trying to understand how the FPGA and HPS communicate with each other. From what I can gather, the last GB of the HPS’ address space is mapped to the HPS-to-FPGA AXI bridge, and reading from/writing to it will send a signal to the FPGA that it can interpret and respond to. I think I’ll have to run some experiments when I get my board to convince myself of this. I’ll also need to spend some more time with the Cyclone V manual, it seems.

Finally, I also wrote a small C program to convert 16-bit 32KHz Mono Microsoft PCM Wave audio to pure 8-bit samples. It works with all the wave files I’ve exported from audacity into this format, though I didn’t rigorously test it. I did this so that once the audio system is brought up, we have working audio to make a direct comparison against. The program will also output 8-bit wave form audio in the wave format, so that it can be played on a computer and compared to our FPGA’s output. The source code for the program has been attached as well, though I’ve not tried building it on Windows/Mac.

Program source

Design Notes

This past week, outside of our group meetings, I looked into what would become our requirements for the processor in our handheld. Previously, all we really had nailed down was that we wanted something Arm clocked at at least 16MHz. We can now specify some more detail on that.

 

Based on our projects overall goals of providing a safe development environment, we decided to create a small software kernel for our console. This means our processor must provide the tools to implement such a kernel, namely memory protection. Arm processors do offer memory protection, but as an optional component, so we’ll need to ensure that if we use an Arm processor it offers memory protection. We must also ensure that any processor we use allows us to externally send interrupts to it. This will become important when managing our graphics and sound output. Finally, we’ll need a timing register to allow our kernel to support some basic timing facilities. Currently, I think our best bet is to simply expose a configurable timing interrupt to the user. Such an interrupt would hand off to some user provided function in a specified interval and allow the user to perform some time sensitive operations. Doing so would allow the user to track the passage of time and perform time based actions like multi-threaded code, should they wish to. Due to timing constraints, providing the user with a full threading library is outside the scope of our project.

 

Additionally, I also was able to get more firm requirements on the memory of our console. The GBA offers 256KB of slow ram + 32KB of fast ram, with the latter often used to cache full arm instructions as it was the only ram in the console to use a 32-bit bus. Since our project is aiming to provide a similar experience to consoles like the GBA, we must provide at least 512KB of ram. Since we’ll be including a kernel with our console, we should provide more than that, likely closer to a megabyte. In any case, I doubt this requirement will be difficult to meet. The more interesting one is the long term storage requirement. GBA cartridges ranged in size from 4MB to 32MB. We’ll need to ensure that our console offers long term storage in this range, and preferably said storage will not be unbearably slow. One option could be to ensure that we find an FPGA which offers at least this much flash storage.

 

At this moment, we’re right on schedule. In this next week, we will finish off our proposal presentation and research the hardware we will use for our project.

 

The basic GBA hardware information was obtained here:

https://www.copetti.org/writings/consoles/game-boy-advance/

 

The cartridge size information was obtained from here:

https://projectpokemon.org/home/forums/topic/22987-what-are-all-possible-rom-sizes-for-clean-dumps-gb-gbc-gba-nds/