Chris and I did more thinking today about the waterfets. I'm revisiting this now, since I'm taking 18-322, which is the CMOS/VLSI circuit design and layout course (and which I really wish wasn't at 0930). In particular, we decided that milling deep channels sucks a lot, and it'd be much better if we could mill shallow, wide channels (or better, shallow, narrow channels). So if we cut the depth to, say, 1/8 inch, then we could save a lot of time on milling (perhaps even enough to use the noob CNC mill), and have to pump a lot less volume to get the things to work (good if we want to run it on compressed air instead of water).
I also did some more thinking. I learned that CMOS D-type flip flops are usually implemented using transmission gates, instead of logic gates. Transmission gates are very weird things -- usually in a CMOS design, you see each NFET paired with a PFET on the top. The output is always actively being driven by a chain of logic to either Vcc (high) or Vdd (low). But a transmission gate, on the other hand, is just two FETs with their drain and source connected together, and their gates connected to selectors. In effect, they can set an output to their input, or they can be chosen to set their output to nothing (i.e., pass nothing either direction).
This is a cool trick. It doesn't provide the big win to CMOS -- restoring logic, which means that the signal is "reconditioned" each time you pass it through a CMOS gate, but it makes it very inexpensive to make multiplexed logic. This is what happens in a CMOS D-type flip flop -- the output does eventually get reconditioned, but the flop is actually constructed of four transmission gates (herein TGs), and four inverters (which happen to be the most basic structure that you can get in CMOS that actively reconditions). You can play with a flip-flop with this Java applet to get a better idea of how this works.
So, it seems obvious that a D-type flipflop is the next thing for us to try to build. But there's a fly in the ointment -- the TGs depend on a specific property of FETs. Although we name the three pins on a FET "drain", "gate", and "source", and we pretend that if we drive gate high relative to source, then the NFET conducts from drain to source, this isn't actually the case on logic FETs. The dirty secret about logic FETs, though, is that they're symmetrical. That picture makes it quite clear -- the drain and the source are exactly the same.
But, if they're symmetrical, how is it the case that if we drive gate high relative to source, it's different from when we drive gate relative to drain? And if it's not different, which do we pick? Well, as it turns out, the FET actually conducts when we drive the gate relative to either the drain or the source. The FET is quite a bit better at conducting one way than it is at conducting the other, so one will certainly work out better; but there you have it.
This poses a bit of a problem for us. My WaterFET design can only be driven relative to drain or source -- not both. (That's what the angle on the piston is there for.) What to do? Well, this is where Chris had the critical insight. He noted that our WaterFETs don't have to be exactly analogous to silicon; it'd be perfectly OK if we optimized the TGs into a single transistor-alike that is driven "push-pull". Compare that to the current design, which is driven "single-ended"; there's only a single pressure that is really controlling the motion of the gate (relative, that is, to Vcc or Vdd in a normal system). If we drive it "push-pull", then that means that the piston would have a signal on one side, and the inversion of the signal on the other side. Since the TGs are already set up to require this, we would have had to route the inverted signal anyway, so this is an optimization that saves us one transistor, at no cost of routing more signals.
So, this is starting to seem more feasible. The problems that I can forsee are actually pretty mundane; for instance, how are we going to pressurize and test the thing? In the past, I drove it with a nozzle off of an air compressor, but that can only be hooked up to one input at a time; and if we need to potentially drive Vcc, clock, and input signal all at once, then that could start to get ugly. Also, is it time to switch away from driving it with air? Air is difficult because it leaks absolutely everywhere; water would require us to flow much less volume also because it is more viscous. How do we drive it with water, though? The solution might be a switchbox of some kind, but I'm not really sure at this point in time.
...yeah.
That really needed more pictures, and probably more context too, but I hope you can figure it out. You're all smart.