# What are the advantages of using FPGAs over TTL in intro computer architecture?

I teach the one and only computer architecture course at a liberal arts college. The course is required for the computer science major and minor. We do not have computer engineering, electrical engineering, other hardware courses, etc. My primary goal in the course is for students to understand all the way down to the gate level how computers work, which I believe they learn best through a hardware lab and not just through a textbook (Computer Organization and Design by Hennessy and Patterson). My secondary goal is to excite them about computer architecture and increase their excitement about computer science. Preparing them directly for industry is not a goal, although motivating them to study more computer architecture is. The students have generally not had any experience building anything or taking a college-level lab course. Typically, 10-15 students take the course per semester.

I have been teaching the course since 1998 in a manner similar to how I was taught computer architecture and digital electronics back in the late 1980s at MIT: using DIP TTL chips on powered breadboards. On the first hardware lab assignment, students build a full adder. About halfway through the semester, they start building a simple computer with an 8-bit instruction set. To reduce wiring, I provide them with a PCB with some of the electronics (two D flip-flops, two 4-bit LS 181 ALUs wired together to act as an 8-bit ALU, and a tri-state buffer). On the first of these labs, they derive the (very simple) control signals for the two instruction formats and build the circuit, entering instructions on switches and reading results from lights. On the second of the labs, they add a program counter (2 LS163s) and an EPROM (which my original question was about, before it switched to how I should teach intro architecture). On the final lab, they add a conditional branch instruction. While the students spend a fair amount of time wiring and debugging, I feel that's where much of the learning takes place, and students leave with a real sense of accomplishment.

People on this forum have been telling me, though, that I should switch to FPGAs, which I haven't worked with before. I'm a software engineer, not a computer engineer, and have now been out of school for a while, but I am capable of learning. I wouldn't be able to get much money (maybe a few thousand dollars) for replacing our existing digital trainers. We do have a single logic analyzer.

Given my goals and constraints, would you EEs recommend that I stick to my current approach of switch to one based on FPGAs? If the latter, can you give me any pointers to materials with which to educate myself?

As requested, here is a link to the syllabus and lab assignments.

Addition: Yes, it is a digital logic course too. When I got to my college, students were required to take one semester of each of computer architecture and digital logic, and I combined them into a single semester. Of course, that's a statement about the past, not the future.

• Can you post or link to your curriculum / the syllabus? – Kevin Vermeer Dec 5 '11 at 1:03
• May I suggest you consider an alternative approach? How about using microcontrollers like Arduinos in your labs? – JonnyBoats Dec 5 '11 at 3:22
• @JonnyBoats: ... how would that fit in? She's talking about constructing computers from hardware gates. – darron Dec 5 '11 at 3:35
• To answer your question - virtually no one builds hardware gates, they buy chips with gates already implemented. With FPGAs one does not build gates in hardware, they sets them up in software. – JonnyBoats Dec 5 '11 at 19:18
• @JonnyBoats: FPGAs are constructing digital designs from hardware gates (LUTs being programmable gates). The gates exist as hardware, and your design functions in an entirely physical way. With TTL you're not "building gates" by that standard either... they're pre-built gates. The only difference is the gate functions are programmable, the routing is programmable (but still physical), and there's many orders of magnitude more of them. I still don't see how an Arduino fits in a course for digital logic design at all. (Unless you meant for her to change the purpose of the course itself?) – darron Dec 5 '11 at 22:53

Given the goals of the class, I think the TTL approach is fine, and I say this as an "FPGA guy". FPGAs are a sea of logic and you can do all sorts of fun stuff with them, but there's only so much that's humanly possible to do in a semester.

Looking at your syllabus, your class is a mix of the logic design and "machine structures" courses I took in undergrad. (Plus, it's for CS majors. I'm all for CS majors having to face real hardware--letting them get away with writing code seems like a step back.) At this introductory level, where you're going over how assembly instructions are broken down, I see no real benefit to having students do things in code versus by hand. Doing HDL means learning the HDL, learning how to write synthesizable HDL, and learning the IDE. This is a lot more conceptual complexity and re-abstraction. Plus you have to deal with software issues.

Generally the point of a course that uses FPGAs is to practice creating logic that is useful--useful for talking to peripherals, serial comms, RAM, video generators, etc. This is valuable knowledge to have, but it seems very much out of the scope of your course. More advanced classes in computer architecture have students implement sophisticated CPUs in FPGAs, but again, this seems out of the scope of your course.

I would at the very least devote a lecture to FPGAs. Run through a few demos with a dev board and show them the workflow. Since you're at Mills, perhaps you could contact the folks at Berkeley who run CS150/152 and go see how they do things.

• I can say that in the early 90's, CS150 was taught basically the way OP describes her coursework at MIT -- mostly 74xx gates, culminating in construction of a simple 8-bit (or 4-bit?) CPU. We did have a brief project using FPGA's designed in a schematic capture tool (no HDL). It looks like the current syllabus is mostly HDL-based. – The Photon Dec 5 '11 at 18:14
• Good point that the class is a mix of logic design and machine structures. As I added to the question description, there used to be two separate courses, which I combined into one. Thanks very much for your help. I will research FPGAs and at the very least add a lecture on them. At UCB, Dave Patterson created a new approach to intro architecture that is much higher level. I'm keeping an eye on it but don't plan to make that big of a change. – Ellen Spertus Dec 5 '11 at 19:25
• I've been considering the complexity of the FPGA environments and perhaps I don't really disagree that it might be too much for an introductory course. It just seems like a real shame to not teach with modern workflows. I played with TTL myself, and it wasn't until I got into FPGAs that I started to really understand how (relatively simple) computers work. The coursework looks better than what I had to work with, so maybe she gets the concepts across better. However, from the perspective of TTL logic chips, a "real" processor looks very far away. After FPGAs, it's conceivable to make one. – darron Dec 5 '11 at 23:11
• By "how computers work" I mean how to actually build them, not a fuzzy "clocks and flops" concept... which of course TTL is sufficient for. (and again, her coursework looks like it may teach this well... my issue is teaching the concepts on hardware that has almost no real application, instead of teaching on hardware that is actually used) – darron Dec 5 '11 at 23:16
• @darron, TTL is basically obsolete, but it is conceptually clean--there is no language or IDE to complicate things, just diagrams and point-to-point wiring. It gets messy when your word size goes up, but 8-bit stuff is not too bad. If the class went further, or if there was a follow-up class, FPGAs would make sense, but I think it'd be an unnecessary complication given the material being covered. – mng Dec 7 '11 at 2:21

I very much agree with Photon. There are many advantages to using FPGAs. Here are a few interesting points to consider:

1) Easy platform for trying out a gate design very quickly, without hours or potentially days of work wiring things up. FPGAs allow potentially very complex digital designs quite easily. (MUCH more theory, less busywork)

2) Significant portions of a student's work could be done in simulation outside of the lab.

3) The software environment is free (generally including the simulator).

4) There are many relatively cheap FPGA platforms around. Academic pricing should help. Something like the Terasic DE0-Nano is $59 for a complete kit (and it looks pretty good).$50-60 looks to be the per-board range you'd be looking at.

5) There's a lot of really cool stuff to do with FPGAs. There are sites like OpenCores that provide hundreds of prebuilt modules for use with FPGAs. There's FPGA4Fun, which has a lot of tutorials and projects. For pure entertainment, FPGA Arcade is dedicated to building games with FPGAs. Depending on what you set up around the FPGA boards, this could make for a really fun class.

6) Some boards have digital design classes apparently ready-made for them: Intro to Digital Design (warning: large download) using a slightly old Xilinx Spartan 3E-based board. (Although that one's based on ActiveHDL, I'd personally prefer a more standard VHDL or Verilog) The major FPGA vendors also have university programs: Xilinx University Program, Altera University Program, Lattice University Program.

7) The workflow is much closer to how professional design work happens these days. Working knowledge in FPGA development is an immediately marketable skill.

• Thanks very much. I'll definitely try these out. FWIW, if I had a second semester of hardware lab, I'd definitely do FPGAs or Arduino with them. – Ellen Spertus Dec 5 '11 at 19:30

I think that nowadays if you're dealing with things at the gate level, you're not working in the area of "computer architecture", you're really just doing basic digital electronics. But also, you can't teach everything there is to know from gate-level digital electronics up to caching algorithms, parallel computing architectures, SIMD, networking, etc, etc in a single semester.

So it really comes down to what you want to teach. If you want to focus on gate-level digital electronics, then working with gate-level chips will give students something hands-on to work with and give them a stronger understanding of that material. But if you want to teach computer architecture, they probably need to be working at a much higher level of abstraction than AND and OR gates.

At the very least, you probably owe it to yourself to learn an HDL and implement an FPGA-based design or two, so that you (as the education expert here) can assess how those skills would fit into your goals for your students. I expect that other answers will give lots of pointers to low and no-cost materials that will let you get up to speed on FPGA design in a short time. (Hint: Xilinx and Altera both offer free software design tools and simulators, along with tons of application notes and other teaching materials).

• I disagree that the class as is doesn't teach computer architecture. The students learn how to implement an ISA, which is definitely part of computer architecture, and I also teach about pipelining and caches. I agree that there's more to architecture than what I teach in the one course. I took several other architecture courses as a student, have done academic and industry research in architecture, etc. I appreciate the encouragement to look into HDLs and FPGAs. – Ellen Spertus Dec 5 '11 at 22:52

One benefit of using TTL though would be that for the very elementary circuits, the details of the HDL would sort of mask the actual circuitry, and most students would simply spend most of the time writing and learning HDL. I think TTL's for the first part and then FPGA for the architecture part would be better, since it's hard to actually make a programmable system with TTLs.

• +1 HDL hides circuitry. There are a few different ways to write multiplexors in HDLs, and most of them have very little or nothing to do with how the gates are arranged to create a mux. – ajs410 Dec 6 '11 at 22:07
• This is the key point -- it's way too easy to write code for an FPGA without actually understanding at a fundamental level how it works. Now, there are ways of avoiding this, e.g. Altera's IDE includes a schematic entry mode that can help you concentrate on the gate level design, but by sticking with this you also end up not really able to exploit the power of FPGAs, so would there actually be any point in switching? – Jules Oct 18 '18 at 20:45

Fully appreciating the importance of some hands-on experience with physical circuit assembly, I think it's also important to recognize that you cannot cover modern computing practices without some level of something that "feels like" simulation or hide-too-much abstraction, so the best you can do is to try to do some work at each level before adding in enough abstraction to make attempting the next level of complexity plausible. The MIT course to which you refer for example, at one point started doing a software simulation of a 32-bit RISC machine running atop of the chips & modules 8 bit microprogrammed machine that was physically "built". At that point, I'd argue it's more effective to just implement such a machine in an FPGA (something I suspect they've probably done since).

In light of this, my temptation would be to try to include both a chips & wires phase early on, and an FPGA phase later in the course. Since you already have the breadboard kits you could just keep the early labs on that, and use either an FPGA board or maybe a breadboardable FPGA module for the later labs. Building a hybrid machine where the FPGA depends on some outboard circuity implementing part of the processor would be possible, but would feel very artificial - just switching technologies entirely at the point where the complexity exceeds one breadboard piece might be most realistic.

You should be able to source existing stand alone FPGA boards for less than \$100/ea at educational pricing.

Another option, could be to construct your own as part of the class, perhaps building an FPGA serial-loading interface as the first part of the project. A nice advantage of this is that the cost would come in low enough that the students could keep their boards instead of having to turn them in at the end of the term, which would hopefully result in ongoing interest and awareness amongst a handful.

• Thanks very much. I was aware of the change at MIT. In fact, I got started out at my current institution with old 6.004/6.111 lab kits that MIT no longer needed. My students, however, aren't MIT students and can't absorb as much in a semester, so I have to be selective. (Actually, I found at MIT that most students couldn't absorb as much as was thrown at them either, but that's another discussion.) The lower cost of FPGA boards is definitely attractive. – Ellen Spertus Dec 5 '11 at 19:34

I think the right approach would be to start with building a few gates out of relays, which are easy to see and understand but are obviously too slow and power hungry for modern applications. Then show how transistors may be used to do the same thing more compactly, more quickly, and more efficiently, and packaged gates [e.g. "quad nand"] can do it even better yet. Once you've gotten to that point, I'd suggest that you show how to build a things like multiplexers and latches out of gates, and then how somewhat larger structures can be built out of packaged multiplexes, latches, etc. Nobody is going to build a computer nowadays by physically soldering together countless thousands of discrete transistors, but the internal operation of a computer is very much like that of the transistors except that everything is much smaller.

One major benefit I think students would get from this sort of instruction is an understanding of why many things work as they do. For example, if one were "simulating" an instruction set which didn't need to have any practical physical realization, there would be no need to have a "load memory" instruction take three cycles while most other instructions take one. Some things could be understood without going down to the transistor level, but a few can't (e.g. the significance of synchronous versus asynchronous inputs).