Daily Learning Notes for January 9, 2016

First things first: after finishing 100 video blogs in 100 days, it feels great to not do any filming or video editing for a change! So for the first time in ages, I’m publishing my first blog post without any video!

These daily blog posts will serve as a public version of my personal notes, a place to share what I’m learning and what I’m working on. I don’t expect anyone to read this, but making it a public project motivates me to document what I’m doing, which in turns helps me remember things better, learn more, and keep going even when I feel like giving up!

Today I worked on two projects: my Learn to Code LA meetup group and the NAND2Tetris course on computer science from first principles.

NAND2Tetris Learning Notes

I’m still on the first week of the course and have yet to finish the first project, but I finally got around to reading about the Hardware Description Language (HDL) that they use for the course! So far it looks pretty straightforward.

Notes for Appendix A of the course book (PDF), sections A1 to A6:

  • Hardware Description Language (HDL): “a formalism for defining and testing chips”
  • Chips: “objects whose interfaces consist of input and output pins that carry Boolean signals, and whose bodies are composed of interconnected collections of other, lower-level, chips.”
  • When designing a chip, its internal parts are considered black boxes that have already been implemented. This keeps the designs short and easy to read.
  • Each chip has its own file, and the filename corresponds to the chip’s name (A chip named Xxx is defined in file Xxx.hdl).
  • A chip definition has two parts: the header, which acts as an API to document its interface; and the body, which defines its implementation.
  • The body of a chip definition defines the chip’s internal parts, the names of each part’s input and output pins, and how the parts are connected (which outputs are piped into which inputs).
  • Internal pins are defined as needed to connect the internal parts’ inputs and outputs; they don’t require any special declration.
  • Each part’s input pins can be fed from one of three sources: an input pin of the chip being designed, another internal pin, or the constants true or false (representing 1 or 0).
  • For multi-bit buses, “widths of internal pins are deduced implicitly, from their connections.”
  • A chip can be loaded into the hardware simulator by the user directly, but the hardware simulator also automatically loads the files for chips listed in the loaded test script or listed as internal parts of another loaded chip.
  • By default, pins are assumed to be a single bit. A multi-bit bus uses the notation pinName[w], where w is the width of the bus, indexed from 0 to w - 1 (which I recognize from arrays in other programming langauges).

Example of an HDL program defining a chip:

/** Checks if two 3-bit input buses are equal */
CHIP EQ3 {
IN a[3], b[3];
OUT out; // True iff a=b

PARTS:
Xor(a=a[0], b=b[0], out=c0);
Xor(a=a[1], b=b[1], out=c1);
Xor(a=a[2], b=b[2], out=c2);
Or(a=c0, b=c1, out=c01);
Or(a=c01, b=c2, out=neq);
Not(in=neq, out=out);
}

Notes for Hardware Description Language (HDL) Survivor Guide by Mark Armbrust:

  • These terms are all used interchangeably: “HDL file”, “HDL program”, and “HDL implementation”.
  • People are often confused by the syntax a=a that often occurs in HDL files. This guide has a nifty diagram explaining that the a on the left represents the pin of the individual part, and the a on the right represents the pin of the chip being designed. (This is how you would connect the chip’s inputs to the inputs of its internal parts.)
  • Any unconnected pins default to false or 0, which can cause mysterious errors if you miss it!
  • Be sure to read the chip’s output file (.out) when debugging any errors.
  • HDL is a declarative language, so the order in which you define your chip’s parts doesn’t matter.
  • There’s no such thing as an “uninitialized variable” in HDL, and apparently this is important in Chapter 3.
  • Hardware bits are numbered from right to left, so if sel=110, then sel[2]=1, sel[1]=1 and sel[0]=0. Wow! I’m glad I read this, because that’s the opposite of what I’m used to from working with arrays in other programming languages! But then this article also stressed that HDL is not a programming language.

Questions:

  • What does it mean for a chip to be 4-way or 8-way, as in the “Or8Way” chip that I need to implement for the first project?
    • Answer from Chapter 1: The basic gates can be called “2-way logic gates”, so a 4-way or 8-way gate performs the same function but with more inputs. An n-way Or gate outputs 1 when at least one of its n inputs is 1.
  • Why isn’t HDL a programming language?
  • How is a programming language different from other types of computer languages?

Learn to Code LA Notes

  • One year anniversary! I decided to host a little party at my place to celebrate, sort of a cross between a potluck and a hackathon!
    • TODO: Figure out how many people can fit in my living room.
    • TODO: Invite friends
  • Southern California Linux Expo (SCALE 14x): I bought a ticket to attend SCaLE for the first time! It’s the “largest community-run open-source and free software conference in North America” and I hear it’s a really fun event!
    • DONE: Posted it on our meetup calendar to let others know about it.
    • TODO: Organize a “Birds of a Feather” informal gathering at the conference.
  • Repair Cafe: I discovered Repair Cafe from my friend who invited me to be a guest speaker at a local high school yesterday for Girls Who Code. I love the idea! It’s basically a pop-up makerspace where people can get their items repaired for free and learn how to do their own repairs or just meet other DIY enthusiasts.
    • DONE: I reached out to one of their organizers about possibly collaborating or at least helping out with their events!
    • DONE: I signed up to volunteer at their January 30th event in Pasadena.
    • TODO: Post then event on our meetup page if they say that’s OK.
  • Makerden collaboration: Yesterday I also met one of the organizers of a makerspace in Pasadena called Makerden!
    • DONE: Followed up about possibly collaborating on an event to play with both software and hardware!
  • NAND2Tetris Study Group: I definitely want to try hosting a study group for the NAND2Tetris, and so far I have one friend who’s interested!
    • TODO: Send out an email to members to gauge their interest or just post an event and see if anyone RSVPs.
  • Next beginner’s JavaScript workshops: As always, I’m experimenting with new formats and project ideas for these workshops. I’m also planning to try running a paid workshop within the next couple of months to see if it’s worthwhile for both our members and for me personally. Doesn’t hurt to give it a try!
  • Documentation: This came up in my conversation last night with two of the mentors who help run the Girls Who Code after-school program at that high school I spoke at. (They also work at JPL and are really cool! What a fun and geeky conversation we had!) Anyhow, they reminded me of just how fundamental documentation is to any project or organization. This has been on my to-do list for almost a year now and I’ve yet to carve out a block of time to actually work on this! So it needs to be done.
    • TODO: Write an outline of what documentation we need for Learn to Code LA, especially to help other people join as volunteers, mentors or teachers.
    • TODO: Decide where to host it (Google Docs, a page on Meetup, etc)
    • TODO Later: start making the website!

Time breakdown

  • NAND2Tetris reading and review: 1 hour 30 min
  • Learn to Code LA planning: 1 hour 15 min
  • Updating my website: 15 min