Graduation and Wrapping up Gem5 Research
The last time I wrote about Gem5 and memristors was in July 2023. You can see my blog series for all of the posts about this project. Since then, I completed my research, wrote my thesis, and graduated with a Master of Sciences in Electrical & Computer Engineering.
So I thought I should write a finale that wraps up the series and include anything I may have left out.
Writing a thesis
With my research complete, I moved to the phase where I wrote my thesis. I think this can be intimidating to many people, but I don’t mind writing. I’m writing this blog post right now.
It helps to use Overleaf. My college has a LaTeX template that I could easily import and I could take advantage of that so I didn’t have to think about formatting. I just could focus on the writing (and diagrams) and the layout was generated for me.
This also extends to generating my bibliography through BibTeX. I had already been reading a lot of papers and there are even more that I pulled from journals as they were published. I even found a few pre-prints that were published about a week before my thesis defense.
It took a few weeks and many revisions to arrive at the final draft before doing my thesis defense. Then, I took the paper and converted it into a slide deck to do the defense. Overall the defense went okay, though I did get a lot of good feedback that I incorporated into a next revision.
One point was to focus a bit more on the circuit diagram, so I recreated it as shown above. This shows how the N-bit memristor component can be built and connected to the CPU.
A question that was raised was around the definition of “random”. How do I know something is statistically random versus not? To figure it out, you need to generate a large sample and take a look at the distribution of results. If it’s significantly distributed, then you can consider it random.
One issue with Gem5 is that it really isn’t setup for randomness. I've noticed this in the past, that even the built-in RNG always generates the same numbers. This makes it difficult to test my simulated memristors too, since the randomness isn’t what you’d see with a real CPU.
So I ran a simulation using the Gem5 default rand() function, the simulated STT-MTJ, and ran the same program just on my regular Windows PC in order to see the real-world results. My simulated component is more random than Gem5, and is under the threshold. But in a real-world situation it would probably be faster than on Windows.
A key measurement that I illustrate in my thesis is that using memristors would also be faster and consume less energy.
After the thesis was finalized, I submitted it to the university and can get it professionally printed. My copy is in the mail. It’ll be a nice keepsake.
Future Work
At the end of every research paper, there is a section for future work. I think it’s fun to dream about the future, but how often do these things pan out? Now that I’ve graduated, am I really going to keep doing this research? I’d like to, but life often finds other priorities for us.
But I am generally bullish on this technology. In my research there are a lot of fascinating hardware innovations that are not quite ready for commercialization yet.
Improved analog-to-digital converters mean a single memristors can store 10-bits of data, leading to a large potential reduction in physical size. Production innovations are improving yields while reducing costs.
The challenge we face then, as an industry, is around the hardware-software level. How do we develop better software to take advantage of this hardware if it’s available? How do we design the best hardware components to accelerate software the most?
In my example, I mainly focused on random number generation as a way to prove out the hardware architecture design. Throughout this process I learned about RISC-V and Gem5 and other modern hardware simulation platforms. Having expertise at this level is going to be critical for anyone who wants to do more with memristors in the future.
One thing that I didn’t do was focus on the compiler and C-language syntax. It did feel like a distraction and something that could easily be mitigated by writing a library wrapper around some assembly code. But eventually I could anticipate some value in language support for non-volatile pointers versus volatile pointers.
As for now, I’m happy to be done. I can turn my attention to other endeavors like not writing a thesis. Ah, but I’m already productive enough. Maybe one day I will loop back around. As I have uncovered in my research, there are many other people working on these topics so I look forward to seeing what happens next.
