WEBVTT 00:00:00.719 --> 00:00:05.759 Let's see if we can improve the throughput of the original combinational multiplier design. 00:00:05.759 --> 00:00:10.120 We'll use our patented pipelining process to divide the processing into stages with 00:00:10.120 --> 00:00:15.610 the expectation of achieving a smaller clock period and higher throughput. 00:00:15.610 --> 00:00:21.159 The number to beat is approximately 1 output every 2N, where N is the number of bits in 00:00:21.159 --> 00:00:23.989 each of the operands. 00:00:23.989 --> 00:00:28.089 Our first step is to draw a contour across all the outputs. 00:00:28.089 --> 00:00:33.500 This creates a 1-pipeline, which gets us started but doesn't improve the throughput. 00:00:33.500 --> 00:00:37.350 Let's add another contour, dividing the computations about in half. 00:00:37.350 --> 00:00:41.600 If we're on the right track, we hope to see some improvement in the throughput. 00:00:41.600 --> 00:00:44.550 And indeed we do: the throughput has doubled. 00:00:44.550 --> 00:00:48.650 Yet both the before and after throughputs are order 1/N. 00:00:48.650 --> 00:00:52.420 Is there any hope of a dramatically better throughput? 00:00:52.420 --> 00:00:58.050 The necessary insight is that as long as an entire row is inside a single pipeline stage, 00:00:58.050 --> 00:01:02.980 the latency of the stage will be order N since we have to leave time for the N-bit ripple-carry 00:01:02.980 --> 00:01:05.790 add to complete. 00:01:05.790 --> 00:01:08.360 There are several ways to tackle this problem. 00:01:08.360 --> 00:01:12.670 The technique illustrated here will be useful in our next task. 00:01:12.670 --> 00:01:15.690 In this schematic we've redrawn the carry chains. 00:01:15.690 --> 00:01:20.260 Carry-outs are still connected to a module one column to the left, but, in this case, 00:01:20.260 --> 00:01:22.580 a module that's down a row. 00:01:22.580 --> 00:01:27.300 So all the additions that need to happen in a specific column still happen in that column, 00:01:27.300 --> 00:01:31.470 we've just reorganized which row does the adding. 00:01:31.470 --> 00:01:36.658 Let's pipeline this revised diagram, creating stages with approximately two module's worth 00:01:36.658 --> 00:01:38.658 of propagation delay. 00:01:38.658 --> 00:01:43.710 The horizontal contours now break the long carry chains and the latency of each stage 00:01:43.710 --> 00:01:49.670 is now constant, independent of N. Note that we had to add order N extra rows 00:01:49.670 --> 00:01:54.240 to take of the propagating the carries all the way to the end - the extra circuitry is 00:01:54.240 --> 00:01:57.130 shown in the grey box. 00:01:57.130 --> 00:02:03.280 To achieve a latency that's independent of N in each stage, we'll need order N contours. 00:02:03.280 --> 00:02:09.259 This means the latency is constant, which in order-of notation we write as "order 1". 00:02:09.259 --> 00:02:14.510 But this means the clock period is now independent of N, as is the throughput - they are both 00:02:14.510 --> 00:02:16.450 order 1. 00:02:16.450 --> 00:02:23.040 With order N contours, there are order N pipeline stages, so the system latency is order N. 00:02:23.040 --> 00:02:27.450 The hardware cost is still order N^2. 00:02:27.450 --> 00:02:32.170 So the pipelined carry-save multiplier has dramatically better throughput than the original 00:02:32.170 --> 00:02:36.910 circuit, another design tradeoff we can remember for future use. 00:02:36.910 --> 00:02:41.680 We'll use the carry-save technique in our next optimization, which is to implement the 00:02:41.680 --> 00:02:45.400 multiplier using only order N hardware. 00:02:45.400 --> 00:02:50.170 This sequential multiplier design computes a single partial product in each step and 00:02:50.170 --> 00:02:52.820 adds it to the accumulating sum. 00:02:52.820 --> 00:02:57.000 It will take order N steps to perform the complete multiplication. 00:02:57.000 --> 00:03:01.790 In each step, the next bit of the multiplier, found in the low-order bit of the B register, 00:03:01.790 --> 00:03:06.410 is ANDed with the multiplicand to form the next partial product. 00:03:06.410 --> 00:03:10.650 This is sent to the N-bit carry-save adder to be added to the accumulating sum in the 00:03:10.650 --> 00:03:12.770 P register. 00:03:12.770 --> 00:03:18.260 The value in the P register and the output of the adder are in "carry-save format". 00:03:18.260 --> 00:03:24.120 This means there are 32 data bits, but, in addition, 31 saved carries, to be added to 00:03:24.120 --> 00:03:26.849 the appropriate column in the next cycle. 00:03:26.849 --> 00:03:31.280 The output of the carry-save adder is saved in the P register, then in preparation for 00:03:31.280 --> 00:03:36.129 the next step both P and B are shifted right by 1 bit. 00:03:36.129 --> 00:03:41.450 So each cycle one bit of the accumulated sum is retired to the B register since it can 00:03:41.450 --> 00:03:44.990 no longer be affected by the remaining partial products. 00:03:44.990 --> 00:03:49.910 Think of it this way: instead of shifting the partial products left to account for the 00:03:49.910 --> 00:03:56.550 weight of the current multiplier bit, we're shifting the accumulated sum right! 00:03:56.550 --> 00:04:00.540 The clock period needed for the sequential logic is quite small, and, more importantly 00:04:00.540 --> 00:04:05.860 is independent of N. Since there's no carry propagation, the latency 00:04:05.860 --> 00:04:12.420 of the carry-save adder is very small, i.e., only enough time for the operation of a single 00:04:12.420 --> 00:04:15.080 full adder module. 00:04:15.080 --> 00:04:19.839 After order N steps, we've generated the necessary partial products, but will need to continue 00:04:19.839 --> 00:04:25.860 for another order N steps to finish propagating the carries through the carry-save adder. 00:04:25.860 --> 00:04:30.979 But even at 2N steps, the overall latency of the multiplier is still order N. 00:04:30.979 --> 00:04:36.560 And at the end of the 2N steps, we produce the answer in the P and B registers combined, 00:04:36.560 --> 00:04:41.880 so the throughput is order 1/N. The big change is in the hardware cost at 00:04:41.880 --> 00:04:47.970 order N, a dramatic improvement over the order N^2 hardware cost of the original combinational 00:04:47.970 --> 00:04:50.430 multiplier. 00:04:50.430 --> 00:04:53.860 This completes our little foray into multiplier designs. 00:04:53.860 --> 00:04:58.330 We've seen that with a little cleverness we can create designs with order 1 throughput, 00:04:58.330 --> 00:05:01.520 or designs with only order N hardware. 00:05:01.520 --> 00:05:06.690 The technique of carry-save addition is useful in many situations and its use can improve 00:05:06.690 --> 00:05:11.800 throughput at constant hardware cost, or save hardware at a constant throughput.