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.

  • 1
    \$\begingroup\$ Can you post or link to your curriculum / the syllabus? \$\endgroup\$ Dec 5, 2011 at 1:03
  • 1
    \$\begingroup\$ May I suggest you consider an alternative approach? How about using microcontrollers like Arduinos in your labs? \$\endgroup\$
    – JonnyBoats
    Dec 5, 2011 at 3:22
  • 8
    \$\begingroup\$ @JonnyBoats: ... how would that fit in? She's talking about constructing computers from hardware gates. \$\endgroup\$
    – darron
    Dec 5, 2011 at 3:35
  • 2
    \$\begingroup\$ @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?) \$\endgroup\$
    – darron
    Dec 5, 2011 at 22:53
  • 2
    \$\begingroup\$ UPDATE: I am now switching to FPGAs. :-) \$\endgroup\$ Aug 15, 2016 at 22:18

8 Answers 8


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.

  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – The Photon
    Dec 5, 2011 at 18:14
  • 1
    \$\begingroup\$ 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. \$\endgroup\$ Dec 5, 2011 at 19:25
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – darron
    Dec 5, 2011 at 23:11
  • 1
    \$\begingroup\$ 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) \$\endgroup\$
    – darron
    Dec 5, 2011 at 23:16
  • 2
    \$\begingroup\$ @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. \$\endgroup\$
    – mng
    Dec 7, 2011 at 2:21

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
    \$\begingroup\$ +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. \$\endgroup\$
    – ajs410
    Dec 6, 2011 at 22:07
  • 2
    \$\begingroup\$ 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? \$\endgroup\$
    – Jules
    Oct 18, 2018 at 20:45

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.

  • \$\begingroup\$ 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. \$\endgroup\$ Dec 5, 2011 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).

  • \$\begingroup\$ 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. \$\endgroup\$ Dec 5, 2011 at 22:52

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).


Stick with basic TTL devices on the benchtop... at least for the start of the course.

One of the things that is very cool about chaining individual gates together on the desktop - particularly if you use slower devices - is you can have the students put a scope on the inputs/outputs. Make sure your lab notes include unstable designs with feedback to cause oscillation and ask the students to explain why it oscillates.

There's a lot of things that are important here. Rise/fall time is measurable on even a basic scope and so is propagation delay. It's very important that the students learn that digital logic is just an analog process with preset thresholds for "on" and "off". Those real-world behaviors become increasingly important as the transition rate and complexity of the logic increases. For an introduction to computer architecture course where you're building a very basic MCU in a FPGA, propagation time (even inside the FPGA) will place an upper limit on the MCU clock rate before it begins to behave unpredictably.

I found that most students didn't understand the physical reality of digital circuits until they actually saw them on a scope, and it's still too easy to fall into the trap of assuming transitions are instantaneous and waveforms are perfect squares.

You have a whole semester, so you don't need to dedicate more than a couple of weeks of teaching time to ensuring the students understand the real-world implications of the digital circuits they're working with.

Then move onto translating that to HDL and building things in FPGAs if it's where you want to go, but there's no substitute for building things on the bench and examining their real-world behavior.

  • 2
    \$\begingroup\$ I think you may overestimate how much you can do in a semester. I'm not sure you can take students from "no clue what a karnaugh map is" to "making a processor in an HDL" in one semester, especially not if you want them to really understand what they're doing. \$\endgroup\$
    – Hearth
    Jan 26, 2021 at 5:43
  • \$\begingroup\$ I taught second year EE digital logic some years ago. The syllabus was prescribed by the university, but I say from experience thwt You certainly can bring a group of students from essentially zero to basic MCU in a semester. Admittedly we taught through schematic capture rather than HDL. \$\endgroup\$
    – Adam Hawes
    Jan 26, 2021 at 7:49
  • \$\begingroup\$ Remember that if you're going that route you will have to teach students how to use VHDL or Verilog from scratch, and you'll have to deal with preconceptions about it being a "programming language" (which it isn't, and it works very differently from one). \$\endgroup\$
    – Hearth
    Jan 26, 2021 at 14:06
  • \$\begingroup\$ Thank you for your answer, although @Hearth is right that I have a lot of material to cover. This is the sole architecture/OS course in a CS (not CE or EE) program, so I also cover assembly language, computer arithmetic, caches, and virtual memory. I realize this forum is geared to EEs. \$\endgroup\$ Jan 27, 2021 at 17:44

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.

  • \$\begingroup\$ 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. \$\endgroup\$ Dec 5, 2011 at 19:34

Discrete TTL devices are not a bad idea, but I think that discrete CMOS 4000 is an even better idea for teaching introductory digital stuff.

There are definitely benefits to the almost-50-year-old CD4000 family in the context of a lab-based course.

  1. all the relevant parts are still available from TI in DIP packages, and usually are in stock
  2. they are CMOS devices, just as pretty much all of digital logic made today (vs. the bipolar TTL)
  3. they have low power consumption that's proportional to clock speed - when stopped, they are essentially open circuits, and at audio frequencies they are micropower and can run from 3V coin cells or 2x1.5V button cells
  4. the inputs are essentially open circuits at DC, and about 5pF at AC; the static fanout is infinite (vs. the pain that it is in TTL)
  5. they run just fine from unregulated power supplies
  6. they work from 3V to 15V supplies, and the supply voltage modulates their speed: at 3V those are slow and benign devices, and a 10-20MHz oscilloscope is all you need to accurately represent the signals!
  7. 12V supply will assure highest speed achievable with that family, without the worry of destroying the chips if the supply is a couple volts off
  8. 9V-12V supplies are typical and guarantee as good a performance as you'll get from that family
  9. the output slew rates are 1-2 orders of magnitude slower than those of more modern logic families: there are few if any signal integrity problems even when designs are laid out on solderless breadboards
  10. the noise margins are very generous at higher supply voltages
  11. the outputs are short-circuit-proof
  12. the outputs can be paralleled for higher drive strength - just as you would in an ASIC by changing the channel width of the output stage - and are "weak" enough to observe such effects easily even with crude measurement techniques
  13. the CD4007UB chip with 3 PMOS and 3 NMOS transistors allows gentle introduction to techniques relevant in transistor-level logic design: weak vs. hard drivers, transistor stacking for two-three input gates, Schmitt triggers, pass gates, etc.
  14. AND, OR, NAND, NOR are available in 2, 3, 4 and 8-input variants
  15. many devices in the family work in sub-threshold nanopower regime at voltages much below 3V; sub-threshold operation is in production use in nanopower circuitry and is quite relevant
  16. there is enough variety to demonstrate more advanced techniques, e.g.:
  • CD4048 is a wide programmable gate, for implementing complex programmable combinatorial logic equivalents, or makes a convenient "universal building block" with up to 9 inputs

  • CD4089 and CD4527 rate multipliers allow (slow) digital facsimiles of analog computers - you can be solving differential equations, etc.

  • CD4068, 78, 85, and 86 wide-input gates allow 1:1 implementation of programmable combinatorial logic (unregistered PALs)

  • CD4007, 16, 53, and 66 are pass gates (in more or less disguise)

As of January 2022, the following devices were orderable in PDIP from TI - they all are CD4xxxBE part numbers unless indicated otherwise:

4001-4002, 4007, 4009UBE, 4010-4031, 4033, 4035, 4040, 4041UBE, 4042--4048, 4049UBE, 4050-4056, 4060, 4063, 4066, 4068, 4069UBE, 4070-4073, 4075-4078, 4081-4082, 4085-4086, 4089, 4093-4094, 4098-4099, 40102-40103, 40105-40107, 40109-40110, 40117, 40147, 40160BF (CDIP), 40161, 40174-40175, 40192-40194, 40257, 4502-4504, 4508BNS, 4510-4512, 4516-4518, 4520-4522, 4527, 4532, 4536, 14538, 4541, 4555-4556, 4572UBE, 4585, 4724.

The above also happen to be the widely applicable devices in the CD4000/MC14000 family. Some of them are hard to find using the function searches on the TI website, and it took me a while to collect the list above.

About the only function that's sadly missing from that list -- and not in regular manufacture today -- are the parallel adders. If you insist on having them, and can buy about a hundred at a time, I'm sure Rochester Electronics may have some. Otherwise, it's not too hard to build them from the variety of gates available.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.