Ever since I’ve gotten my research position at KOTO, my appreciation for finely crafted research notebooks has significantly increased. My affection for research notebooks first grew out of tragedy. It all began when my internship had tasked me with creating code that would take the experiment’s data and prepare it for transmission to a PC. While I had completed the first version of the code relatively quickly, it had simply refused to work.
Coding firmware is a bit different than coding software. “Simply” put, when you produce code for an FPGA you are essentially mapping out a circuit. This is different than software, where your code amounts to a list of instructions that a processor executes. Because you are creating a circuit in firmware, there are physical constraints you have to factor when coding firmware. For example, certain types of signals need to placed in specific locations in the FPGA, and you need to make sure your signals are traveling fast enough from point to point to insure the circuit behaves as expected. If you don’t properly consider these constraints, you can create code that produces different results in a simulation than when it’s running on an actual board.
This was happening to me, and I went through the steps a typical programmer might take to debug code; re-reading through my code to detect logical errors, perusing books on how to transmit data using an FPGA, and of course going to StackOverflow.com. After weeks of trying anything and everything that could have the tiniest iota of a chance towards making my code work, one night my code was finally transmitting data correctly. Man had triumphed over code, and I looked forward to resuming my work the next morning.
Color me surprised when I returned to my code the next day and it didn’t work. Frantically I scrapped my brain to find out what happened. I had faint recollections of making slight alterations to the code before I left the night before – but nothing concrete. Actually, calling my fleeting memory at that moment “faint recollections” might be too generous; they were more like ghost tormenting my mind. Did I change this bit from a zero to a one? Did I swap the order of these two lines? I couldn’t remember.
I considered looking back at my notes from the day before, but my hopes were crushed when I realized my disorganized chicken scratch was a poor excuse for note taking; I never found out what changes I made and I burned weeks before I finally got my code in working condition again.
Lessons were learned, bad habits were broken, and notebooks were bought. Now I’m probably a bit too meticulous and record more things in my research notebook than necessary, but ever since I started keeping better track of my research the quality of my work has improved.
And this is a skill this internship helped me develop.