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.
Not really an answer but a "what would I do"
I used to work for a department where many bright people worked for many years to design a microcontroller based DCDC converter. They could not get it to work properly under all circumstances ! For sure the demands on that design were more complex than yours.
The reason why I bring this up is that I doubt if it is a good idea to try to implement this with an FPGA or microC. instead of using a dedicated SMPS controller. For sure that would be far easier and above all SAFER !
Of course the decision is yours but I know what I would do (use a dedicated SMPS controller).
Best Answer
I've used a product line called the Electronically Programmable Analog Circuit (EPAC), probably more than ten years ago by now, which claimed to be the analog equivalent of an FPGA, and Cypress has for years produced a line called the PSoC (Programmable System On Chip) which incorporates a switchable arrays of both analog and digital circuitry. Note that in both cases the devices have a moderately small number of functional blocks (3 to 24 or so in the case of the PSoC) with somewhat limited routing options, rather than providing hundreds or thousands of blocks with enough interconnects to allow essentially arbitrary routing.
One reason that analog FPGA's don't offer anywhere near the design flexibility of digital devices is that even if one passes a digital signal through dozens or hundreds of levels of routing and logic circuitry, each of which has a 10dB signal-to-noise ratio (SNR), meaning there's 1/3 as much noise as signal, the resulting signal can be clean. By contrast, getting a clean signal from an analog device requires that every stage the signal goes through must be clean. The more complex the routing, the more difficult it is to avoid picking up stray signals.
In applications that aren't too demanding, having a small amount of analog circuitry combined into a chip can be useful. For example, I've designed a music box which uses a PSoC to drive a piezo speaker directly; the PSoC includes a DAC, a fourth-order low-pass filter, and output amplifier. It wouldn't have been hard to use a separate chip to do the filtering and amplification, but using the PSoC avoided the need for an extra chip.