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.
You may have several pipelines (say one for integer, one for floating point) but if you never issue more than one instruction per cycle, you don't have a superscalar processor.
To have a superscalar processor, it has to be able to issue several instructions in the same cycle, which implies to have several, more or less independent, execution units (which are probably pipelined).
Best Answer
Not all of the CPU instructions have the same complexity. When instructions are particularly complex (like some x86 instructions), it is more convenient to implement them as a series of elementary instructions that are contained in a very fast internal memory. When a microcoded instruction is executed the microprocessor split it into a series of simple hardware coded instructions and execute them in series.
So microcode is used in more complex instructions, while simple instructions are directly executed. For example today Intel microprocessors uses microcode in order to execute some old legacy instructions. The x86 microprocessors, that on the paper are CISC, internally uses an architecture that is more like RISC in order to boost the performance and they offer support to the legacy instructions through microcode.
You can find many RISC CPUs that don't use microcode. This is essentially due to their reduced instruction set, that makes more convenient implement all the instructions in hardware. An example of microprocessor that doesn't use microcode is the MOS 6502.