We Get Signal

Oh man, I'm such a nerd.

Anyways, the blogs have now been linked to the HMC Admissions website. Wheee!

As if anyone read this thing before.

So, onto the topic of the day: signals.

Now, this could go plenty of different ways. I could talk about signaling each other. Which would in turn be about communication. Or, I can ramble about my High-Speed PCB Design class and all the lovely troubles I'm having.

But, I think I'm going to go with the VLSI project.

VLSI is an acronym for Very-Large Scale Integration. Yeah, kinda lame. It basically translates into chip design. Way back in the day, building a simple analog circuit was the coolest thing. Then people got creative and started doing logic. And later, memory. Jump forward a bunch of years and you've got millions and billions of tiny transistors on a 1 inch silicon chip doing everything from accessing external memory to doing a linear transformation, not to mention dealing with internal signals and cached memory and figuring out what it should do next with the instruction we just fed it. So, yeah, Very-Large Scale Integration.

This particular class is very interesting. In E85: Intro to Digital Design, we learned about digital systems and logic and all that. So, how to build something that works. Now, we're learning how to build something from idea to schematic to layout to fabrication, and make sure it doesn't guzzle giant amount of electricity nor takes forever to do anything (i.e. minimize delay). Also, if you follow the microprocessor wars, you'll know that every little bit counts. Basically, it's a class on how to make a good chip.

The bulk of the class is taken up by a project where the entire class builds a chip. That's 14 students trying to build something. This year it's a 6502 processor, the thing in the Apple II and the NES game system, with a fun research component called a Razor latch. The idea is we run the chip so fast that it break (i.e. gets the wrong answer) in the worst-case scenario. However, most of the time, it works. And when it breaks, we detect it and pay a penalty to fix this issue. So, we're running this right on the edge of failure, instead of padding a little margin of error. As I said, every little bit counts.

Now that you know the back story, here's the main event.

It's a 14 person team.

Our professor David Harris was talking with a friend and they talked a bit about how the VLSI project works. The other professor, after hearing what's going on, asks, "Is this one of those only at Harvey Mudd things? I mean, what if one of the students doesn't do the work?" I'm sure you're familiar with this, that chance that one person drops out or slacks off and everyone else has to pull the extra weight. However, David Harris has been doing this at Mudd for every year since he's gotten here (well, maybe not his first year, but you get the idea) and not once has anyone dropped out of the project. Usually they drop during the first few weeks of class, pre-project time.

But basically, it's weird. At least to me. I mean, at Mudd, when you think about it, there's this weird feeling of letting others down. Thus, even in a giant project with 14 people, students don't want to let their team down, so they all try their hardest to make the project work. That is just awesome. I mean, I've always held a strong conviction about my work and ownership of a product, probably why I did so well on projects back in High School, but it didn't click until recently that elsewhere, sometimes people don't care about the team or the project and essentially screw everyone else over. Kinda cool that at Mudd we don't worry about that.

However, it's not all fun and games. We're talking about trying to build a processor with 14 students in about 8 weeks. This has several components to the process, all divided amongst different teams, and huge dependencies everywhere. We really felt that last week. One team didn't realize how much several other teams needed certain tests. The problem was exasperated by the fact the RTL (basically code that outlines the idea of how things work) wasn't quite finished yet. In fact, it's still not quite finished yet. Thus, even if they built a comprehensive test, they couldn't check if the test even worked. I eventually got in contact with these guys (one of them lives down the hall, and is a girl) and we hammered out what I wanted for the test, and how we could move forward even with stuff in a state of flux on the RTL side. We eventually got a simple starter test, and have since been able to start slowly moving forward again.

So, here's the lesson. When you've got something this big and complex, make sure you talk to each other. Plan ahead, figure out what you need when and make sure others know you need it. One of the biggest problems has been not getting stuff because people didn't realize others were depending on it. With all of these dependencies, if one end gets stuck, it eventually can bring the whole project grinding to a halt. Not fun. So, it's a learning experience not only on how to make a good chip or team dynamics, but especially one about how to plan ahead and make sure you communicate in a group as large of this.

And you thought classes would only be lectures, homework, and tests, now didn't you?