Data transfer between FFs in a CPU

I was in computer organization lecture and when we wrote what the CPU does during an add instruction (like micro instructions) something got me thinking.

I didn't understand how we let one of the FFs output to the internal bus and tell other FF to latch the data in. If we send the control signals at the same cycle how is the latter one latches the data in at the same time? Isn't it violating the setup and hold time?

• I think one thing to recognize in computer architecture design is that you might model components like the register file as a bunch of flip flops throughout high level design, but at some point, their implementation will be very different than just a bunch of basic identical 7400 series devices copied and pasted on the die and in fact every one can have a lightly different design down to features of each of its transistors to resolve issues. – David Perek Nov 23 '12 at 2:25

Not necessarily. Bonus points for knowing that an input to an FF has as setup and hold time specification, by the way.

But for many designs of FF the hold time can be 0 ns, i.e. you don't need to hold the data for ANY time after the clock edge. (When designing the FF, you can guarantee this - just make sure you use slower transistors or longer wires on the input, and faster on the clock!)

Now the clock latches the data, but that process takes some time - called propagation delay, or clock-output delay - and then the wire to the next FF adds some delay of its own. So the next FF doesn't see its input changing until AFTER this time, certainly greater than 0 ns, so this is safe. (If it isn't greater than the actual hold time you ARE in trouble!)

The setup time is less important at this stage; since the previous FF output changes just after the clock edge, it has almost a whole cycle to get here. Calculate clock cycle time - clock-output delay - wire delay - setup time and if the number is positive, that's safe too.

Setup time matters when you start adding gates or long wires between FFs; these add more delay. So when that sum becomes zero, the clock is too fast!

(There is another aspect; clock pulses arrive at different FFs at different times; for an accurate calculation you need to account for this "clock skew" in both setup and hold time calculations).

So you're not wrong; these are real issues but they have solutions. And chip design involves a LOT of these calculations (mostly automated by the tools, in FPGA design) - called "static timing analysis".

I've reverse engineered old microprocessors (6502, Z-80, 8085) and the trick to data transfer is they use two-phase clocks. Some flip flops are updated during the first phase, and the others are updated during the second phase. The first set of flip flops only depend on values in the second set, and vice versa. Thus, you don't have a problem with flip flop inputs and outputs changing at the same time.

Genuine flip flops are fairly rare in these chips due to their relative complexity. Instead, the CPUs use a lot of dynamic logic with pass transistors; this holds values with wire capacitance rather than a latch. And there are a lot of two-inverter latches, with pass transistors controlling updates.