They say you remember 10% of what you hear, 30% of what you read, something something something, and 90% of what you teach. Those specific numbers may be apocryphal, but the concept makes sense. When you must actively reconstruct what you know into a coherent narrative for the uninitiated, you cement that knowledge in your own mind. It's a signal to the brain that the stuff is important. That's what I'll be doing throughout the Master of Science in Electrical and Computer Engineering course through the University of Colorado, Boulder, via Coursera. This should help me crystallize my own thoughts on the subject matter and consolidate what I've learned as I progress.
Let me first explain the course structure and why I chose this particular program.
MS-ECE, CU Boulder
I look around and see tech companies starving for talent, and I also see candidates starving for a job. Those two can coexist together, and the operative word is "talent." Unfortunately, employers are not facing a shortage of applicants, but rather a shortage of qualified applicants. I am under no illusions that a degree or two automatically qualifies you for a high-paying job (see my last post), so I am determined to do it differently this time. Necessary but not sufficient, an advanced degree is nonetheless an excellent place to start.
So I started looking around. I had my AI buddies come up with a list, the required steps to apply and approximate odds of getting in, and general notes about each. By far the most attractive for the format alone was Boulder's program. Performance-based, full stop, meant that I didn't need to jump through any unnecessary hoops (GRE, letters of recommendation, etc.). Excel in the first few classes, and you're in. Although I would prefer in-person, online meant I could start right away. No move, no lock-in, and if I needed to take a semester off, I could do that. The price is attractive too, about $20k soup to nuts.
The way it works is that students sign up for a specialization, take the first three credits, then gain admission and build the rest of the curriculum from the course catalog. The options are: power electronics, embedding sensors & motors, FPGA (field-programmable gate array) design, optical engineering, and semiconductors. Reason number 692 why having an AI to bat things around with pays dividends is because were it not for Claude, I might not have had confidence in my choice. I have a distinct memory, well over a decade ago now, of trying to decide between Computer Engineering at Wentworth and Computer Engineering Technology. Ask me today what the difference is and I still couldn't tell you. Ask me back then, and one had less calculus attached to it, so that's the one I chose. Anyways, Claude helped me understand what an FPGA was and that it is still a very attractive competency to possess. It mapped to my past experiences, provided a high ceiling and maximum optionality in the workforce, and was a genuinely useful skill for all manner of machine learning/robotics design. Obviously, subsequent research confirmed all of this. Were it not for this conversation, I might have chosen semiconductors. This way, I feel confident that I made the right call.
A whiff of staleness
I was immediately taken aback by the introductory video. Apparently, FPGAs were "projected to reach $10B by 2020." At this point, I'm hoping that the rest of the course would be a little more current, and that they simply had little incentive to reshoot the intro. The first of the program's required readings, FPGAs for Dummies by Andrew Moore (an Intel Special Edition of the Wiley series, with Intel's Ron Wilson as editor-in-chief), followed the same theme.
That said, I am a huge fan of the "For Dummies" style of writing. The way that they establish context before overloading you with information is in stark contrast with the typical way that tech people like to teach. For Dummies puts the bottom line up front, gives you just enough to master the basics, and sprinkles historical factoids throughout (the book claims that the term "bug," meaning an error in a program, comes from a literal moth that got stuck inside an early machine — though this is disputed).
Having some concerns the material was a little dated (2017), I sent Claude the document and asked which parts I could skip and which parts I should read deeply. Claude said that one chapter, essentially amounting to a prediction about the industry (and an Intel SDK plug) failed to materialize, and I could thus safely content myself with a mere skim of this section. The rest, according to Claude, was foundational and timeless, which put my fears of memorizing stale information to bed.
What actually landed
Several other aspects of this introductory reading material landed well. The authors provided a real-world example of using an FPGA to transmit data from its source at a camera in the back of a car to its destination at the screen in front of the driver. The example goes something like this: let's say company A constructs their data pipeline using an FPGA, programmable by definition, whereas company B opts to use a non-programmable interface to accomplish the same task, saving a few bucks in the short-term. Both designs operate with a latency of 250 milliseconds. Years later, long after the respective designs have been rolled into production, a new government regulation requires latencies below 100 ms. Company A can simply reprogram their design, taking advantage of algorithmic efficiencies to get below the threshold, whereas company B must incur a much greater expense to replace the entire circuit. This is an example of how budgeting for flexibility down the line can save on long-term costs and an undisputed win for FPGA. One wonders why the engineers wouldn't have opted for the more efficient algorithm in the first place, were that an option, but that's beside the point.
I had heard the term ASIC before, courtesy of being an early Bitcoin enthusiast, but never the term ASSP. ASSP stands for application-specific standard product. In contrast to ASIC, or application-specific integrated circuit, an ASSP is made for a commonly-used purpose and sold to a wide array of companies as-is. These products are mentioned to stand distinct from FPGA, which is field-programmable, emphasizing its ability to defer taking its final form until after the customer purchases the device and decides on its application. This made intuitive sense to me, which was a nice confidence boost in a gentle introduction to the core concepts.
Having dabbled in software of many kinds, I was already familiar with the idea of packages and libraries. These are essentially ways to build off the backs of those who have gone before you, allowing the designer to operate at a higher level. This mental model helped me understand the idea of "existing IP." For example, adding together two numbers is a feature likely to be needed by nearly all logic circuits in production. Instead of reinventing the wheel, an RTL engineer can take a single element called an adder, itself made up of several logical sequences, and think of it as a confined package with deterministic inputs and outputs. It's this concept that allows today's FPGAs to scale into the billions and trillions of operations without overwhelming the human engineer.
Other course content
This brings us to my reflections on the actual content of the rest of the course, and to be honest, it was a mixed bag. I'm not doing this to encourage or discourage the course itself, but rather to codify insight into my thought processes. Some of it was straightforward — the kind of content you would expect from an engineering course, with right answers and wrong answers — if only not explained very well. Had I not had a background in this very type of work already, I would have likely been completely lost. Most of it was memorization of an alphabet soup of acronyms for which I had no existing reference (choosing all that apply from a list of adjectives as they relate to a device I had never heard of until 5 minutes ago, or reconstructing a flowchart that was shown briefly on the screen while the instructor read from the slides the whole time). Did you know that a PAL has a fixed OR plane with a programmable AND plane, while a PROM has a fixed AND plane with a programmable OR plane? Me neither.
It took me much longer than I care to admit to realize that a LUT (lookup table) was actually a physical data-mapping construct that you placed on-chip instead of deriving the possibilities from logic. One sentence up front would have made that clear. It's the kind of thing that's obvious once you get it, but not before.
If I remember anything from undergrad, it's the feeling that college isn't about paying someone to provide you with information that you lack — it's about getting yourself into an environment where you have sufficient motivation for self-learning. The most successful students actually enjoy this process, not just accomplish the bare minimum. At the end of the day, you shouldn't take the course for the piece of paper or the letter grade. You should take it because you genuinely need the skillsets (and the relationships) that it cultivates, then take those skills and build something with them. In my case, I'm not going to stress over poorly-worded questions or ambiguous instructions. Instead, I'll treat this as ground truth of the state of the industry and what's actually valuable to invest my time into learning, then go about learning it in the best way I know how.
"This doesn't seem so hard"
All in all, I got the feeling that I was going to do alright. The foundations I built in undergrad are still sturdy all these years later. I was reminded that the first module is nothing more than a teaser, a confidence booster before the real work begins. I knocked it out in one sitting. If I can maintain this pace, maybe I can be done with the pathway credits before the summer is out? Surely, Nvidia will be calling me with a job offer this time next year, right?
I'm going to wrap up this article and get started on module 2. Judging by what I've seen so far, it shouldn't be that difficult. Famous last words.