It’s my second day at the Southern California Linux Expo (SCaLE), my first tech conference! I’m learning a lot about tech culture and all the buzz words and gurus and memes associated with each niche, like devops and infosec, webdevs and sysadmins… Fun stuff! I’ll probably type up my notes tomorrow or Sunday.
But right now, I want to get my program counter working! I’m almost done with week 3 of the NAND2Tetris course on computer science from first principles!
Fixing my program counter
Sometime after testing a couple bad designs yesterday, I realized that my first design was mostly correct, after all! My register needs to be the last piece in my chain of chips. What I failed to realize was that I need another chip to control what goes into the load bit, because unlike my RAM chips, this program counter has three inputs that all must toggle on the load chip of its internal register.
So, I just sketched out a new design. I’m pretty sure I finally got it right, but we’ll let the hardware simulator be the judge. Let’s test it out…
Oh no! A new bug! I’m not sure if I’m getting closer to the answer or farther away from it. Well, this time it worked for the first seven tests, which is much better than my previous attempts! So, that’s something.
Here’s the new problem: my program counter increments the new input instead of the previous input, even though the load bit isn’t set! Once again, I misunderstood the specifications. I made an inaccurate assumption. Again.
A couple hours later: I have a little more downtime at the conference again, so I reviewed the specs one more time and wrote them out on paper in more detail. So now I think I finally understand them! The reset bit has top priority; if it’s set to 1, I need to reset my program counter regardless of what the other inputs are! My pervious designs didn’t work that way. The control bits have a hiearchy: the reset bit gets top priority, followed by the load bit, followed by the increment bit.
I’m familiar with how to implement a cascade of conditional statements like this in software – I would use if and else if statements, just like the specifications for this chip.
But how do I implement that with hardware? I had said this before and I’ll say it again: a mux is the hardware equivalent of a conditional statement! My 4-way mux solution wasn’t working because it treats all of the conditions equally. So to implement a cascade of conditions, I should be able to use a cascade of muxes! I also realized that I need a feedback loop in order to increment whatever number is stored in the register. OK, done and done.
Now let’s try out this new design… Fingers crossed, praying to the hardware simulator gods! Running the script… deep breath…
Success! Aw yeah, I’m done with week 3! Just in time, before I start the fourth week of January! It feels good to be back on track. I want to try to finish this course in the span of one college semester, one unit per week. But for the next couple days I’ll be busy geeking out at this tech conference.
Learning summary (#TIL)
- I finally designed a working program counter, finishing the third week of NAND2Tetris!
Next steps
- Start learning the material for week 4, probably after this tech conference is over.
Time breakdown
- Study time: 1 hours 4 min
- Building third project: 1 hour 4 min