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.
As the text in the section 3.4.1 states:
All the blocks are asynchronous except the PCounter.
I.e. The registers and the memory are not clocked.
I believe this text is based on the book you are referring to (or they have the same sources), and they have almost the same diagram.
Best Answer
Any logical transformation of N input bits to M output bits can be accomplished by a look-up table with 2N entries (indexed by the input bits) of M bits each. This is effectively joining together M truth tables each using the same N inputs.
Using a look-up table can be simpler (less error-prone) and friendlier to change than using many individual logical operations to generate the same result. In addition, at times the cost of ROM has been much smaller than the cost of arbitrary logic.
In some cases a compromise design is superior. Discrete logic might be used to compress the input to reduce the size of the table, independent portions of the input might each use a smaller table (requiring a little extra logic to parse the input before the look-up), or simple transformations (such as duplicating particular bits or conditionally inverting particular bits) might be applied to the look-up table result allowing a reduction in the number of bits per ROM entry or the number of ROM entries.
(A similar set of tradeoffs exists for a "hardware" implementation of complex instructions versus the use of microcode.)