Automated Method of Inserting Pipeline Stages in a Data Path Element to Achieve a Specified Operating Frequency

1. Field of the Invention

The present invention generally relates to techniques for determining delays through datapath elements and, more particularly, to techniques for determining signal delays through stages of multi-stage datapath elements.

Logical units, such as an invertor, typically are elements which operate on each digital bit in a datapath individually. In such units, operations on one bit has little, if any, effect on the operation on another bit in the datapath. However, for high-speed multi-stage arithmetic units, such as multipliers and the like, an operation on one bit in a datapath is often dependent upon the results of an operation on other bits. For example, a typical multiplier might include a plurality of carry-save adders and a final ripple-adder. In such multipliers, a carry bit is often generated during an operation on a low order bit and, then, the carry bit is used in an operation on a higher order bit in the multiplier. Since the carry bit must propagate through all of the bits of the ripple adder, the processing time required by the rippler-adder depends, in part, on the number of bits in the numbers being multiplied.

To provide high frequency operation of arithmetic functional units, so-called pipelining stages can be inserted in the units. Although pipelining stages in arithmetic elements have numerous advantages, they also can increase latency times (the period of time required to completely process a word). In other words, because pipelining stages add additional processing steps to arithmetic elements, the elements require longer periods of time to process each individual word. Nevertheless, an arithmetic element's output frequency (i.e., the number of words processed per unit time) may be increased, despite increased latency, by the insertion of pipelining stages in the element. This result follows from the fact that pipelining stages permit an element to begin operating on the next word before the element completes processing of a previous word. Accordingly, although pipelining stages increase element latency times, they also increase the frequency of operation of arithmetic elements.

Thus, the use of pipelining stages necessitates making performance trade-offs between frequency and latency. To achieve optimal or near optimal performance, it is desirable to insert only the minimum number of pipeline stages needed to achieve a desired operating frequency. Stated somewhat differently, pipeline stages ordinarily should be inserted at maximal distances into a functional element.

Effective placement of pipeline stages in a multi-stage datapath element requires fairly accurate estimates of delays through the individual stages of the element. Furthermore, in order to minimize computational complexity, the placement technique should be relatively simple to implement. Accordingly, it is a primary object of the present invention to present a simple and effective technique for determining delays encountered in datapath elements.

Briefly, the present invention relates to a method for determining delays through multiple stage datapath elements. According to the present invention, the delay through each stage of the datapath element can be estimated in accordance with an equation such as:

where D.sub.s is the estimated stage delay, D.sub.b is a delay associated with communication between bits in one stage, N.sub.b is the number of bits in the datapath element, and C is a constant. Based upon the estimated delays, positions of pipelining stages in the datapath functional element can be calculated.

In the accompanying drawing:

FIG. 1 is a schematic diagram of a conventional 5.times.5 unsigned carry-save array multiplier;

FIG. 2 is a schematic logic circuit illustrating a full adder circuit which may be used with the multiplier of FIG. 1;

FIG. 3 is a schematic logic circuit illustrating a half adder circuit which may be used with the multiplier of FIG. 1;

FIG. 4 is a schematic circuit of a portion of a 5.times.5 unsigned carry-save array multiplier including pipeline stages;

FIG. 5 is a diagram which is provided to assist in explaining a technique for estimating delays encountered in an N.times.M array multiplier;

FIG. 6 is a functional representation of an N.times.M array multiplier with pipelining stages; and

FIG. 7 is a flow diagram illustrating a process for determining the placement of pipelining stages in multi-stage datapath elements.

In the following, the present invention will be described in the context of a carry-save array multiplier. However, this embodiment is merely illustrative of elements which operate on parallel data in a datapath. That is, it should be understood that the present invention is applicable to arithmetic operators other than array multipliers.

A conventional 5.times.5 carry-save array multiplier 2 is illustrated in FIG. 1. The multiplier 2 is designed for high-speed multiplication of two five-bit numbers A and B. In symbolic terms, the number A includes, from least significant bit to most significant bit, bits a.sub.0, a.sub.1, a.sub.2, a.sub.3 and a.sub.4. Likewise, the five bit number B includes bits b.sub.0, b.sub.1, b.sub.2, b.sub. 3 and b.sub.4.

The multiplier 2 in FIG. 1 comprises a plurality of rows, or stages, of full adders each designated by the letters FA. Thus, the first row of the multiplier includes full adders 12, 14, 16 and 18; the second row includes full adders 22, 24, 26 and 28; the third row includes full adders 32, 34, 36 and 38; and the fourth row includes full adders 42, 44, 46 and 48. The final stage of multiplier 2 is a ripple-carry adder 50 comprised of a row of full adders 52, 54, 56 and 58.

In operation of multiplier 2 of FIG. 1, each full adder receives three bit inputs and produces a sum output and a carry output. The bit inputs to the various adders in FIG. 1 are listed in Table 1. The sum outputs of the full adders are designated by the subscript "s" and the carry outputs are designated by the subscript "c". Thus, for example, the sum and carry outputs of adder 14 are designated 14s and 14c, respectively. The "a.sub.i b.sub.j " inputs listed in Table 1 designate the respective bits of numbers A and B which are logically combined by the AND operation at each of the adders.

In a typical system employing multiplier 2 of FIG. 1, an input buffer would be provided prior to the multiplier to store the multiplicands and multipliers which are processed by the multiplier. Additionally, a typical system would employ AND gates connected between the input buffer and the adder stages to assure that the a.sub.i b.sub.j inputs to the multiplier are appropriately delayed to achieve synchronization between the stages. Such buffers and gate circuits are known in the art and, for that reason, are not further described herein.

The operation of multiplier 2 will now be explained. For purposes of such explanation an example will be provided in which the binary numbers A=10011 and B=01100 are multiplied. (For numbers with the base ten, A=19 and B=12.) With paper and a pencil, the multiplication could be written as follows:

Accordingly, the process of multiplying two binary numbers can be understood to be achieved by successive additions and shifting. In the above-illustrated multiplication process, it should be noted that the successive bits of the multiplier ar looked at with the least significant bit first. If the multiplier bit is a ONE, the multiplicand is copied down; otherwise ZEROs are copied down. Then, the numbers in successive rows are shifted one position to the left from the previous row. Finally, the numbers are added, with the sum equalling the product of the multiplication operation.

To illustrate multiplication of the numbers AxB=P by multiplier 2 of FIG. 1, the inputs and outputs for each successive stage will be set forth. In the first stage the adders 12, 14, 16 and 18 would receive input sets (0,0,0), (0,0,0), (0,0,0), (0,0,0), respectively, and would provide respective output sets (sum, carry) of (0,0), (0,0), (0,0), (0,0). The least significant bit of the product P is P.sub.o =a.sub.o b.sub.o =0. Bit P.sub.1 would be the sum output of adder 12 which, in this example, is ZERO. In the second stage, adders 22, 24, 26 and 28 would receive input sets (0,0,1), (0,0,1), (0,0,0), (0,0,0) and would provide output sets (1,0), (1,0), (0,0), (0,0). Bit P.sub.2 is the sum output of adder 22, which is ONE in this case. The respective inputs to the third stage adders 32, 34, 36 and 38 would be (0,1,1), (0,0,1), (0,0,0), (0,1,0) and the respective outputs would be (0,1), (1,0), (0,0), (1,0). Bit P.sub.3 is the sum output of adder 32, which is ZERO. Next, the fourth stage inputs would be (1,1,0), (0,0,0), (0,1,0), (0,1,0) and the respective outputs would be (0,1), (0,0), (1,0), (1,0). Bit P.sub.4, the sum output of adder 42, is ZERO in this example.

Further in operation of multiplier 2 of FIG. 1 according to the preceding example, the first adder 52 of ripple carry adder 50 receives input set (1,0,0) and provides output (1,0). Thus, bit P.sub.5 is ONE. The adder 54 receives, in turn, the input set (0,1,0) and outputs (1,0). Bit P.sub.6 is thus ONE. Adder 56 receives (0,1,0) and outputs (1,0); and adder 58 receives (0,0,0) and outputs (0,0). Accordingly bits P.sub.7 and P.sub.8 are ONE and ZERO, respectively. As can be seen, the product P (P.sub.8 P.sub.7 P.sub.6 P.sub.5 P.sub.4 P.sub.3 P.sub.2 P.sub.1 P.sub.0) is 011100100, which corresponds with the result illustrated above obtained by the successive addition and shifting technique.

FIG. 2 shows an example of a full adder. In this example, the full adder is implemented by a combination of two XOR gates 60 and 62, two AND gates 64 and 66, and an OR gate 68. The sum of bits X.sub.i and Y.sub.i and an input carry bit C.sub.i can be expressed as X.sub.i .sym.Y.sub.i .sym.C.sub.i =(X.sub.i .sym.Y.sub.i).sym.C.sub.i. Thus, bits X.sub.i and Y.sub.i are supplied to the input gates of first XOR gate 60. The output of XOR gate 60 is then supplied to an input terminal of XOR gate 62, which receives the bit C.sub.i as a second input. The output of XOR gate 62 represents the sum of the input bits.

Further with regard to FIG. 2, it should be understood that the carry output may be expressed as C.sub.i+1 =X.sub.i Y.sub.i +X.sub.i C.sub.i +Y.sub.i C.sub.i. By manipulating this expression according to the rules of Boolean algebra, the carry output can be expressed as C.sub.i+1 =X.sub.i Y.sub.i +(X.sub.i .sym.Y.sub.i)C.sub.i. Thus, in the system of FIG. 2, bits X.sub.i and Y.sub.i are supplied to the input terminals of AND gate 64. An AND gate 66 has input terminals connected to the output of XOR gate 60 and to input carry bit C.sub.i to produce the resulting expression (X.sub.i .sym.Y.sub.i)C.sub.i. Finally, the outputs of AND gate 64 and AND gate 66 are connected to the input terminals of OR gate 68 to produce the output carry bit C.sub.i+1.

Referring again to FIG. 1, it can be seen that full adders 12, 14, 16 and 18 each have one input set at ZERO. This allows the first stage of each of the full adders to be replaced by a stage of half-adder circuits to minimize circuitry. An example of a suitable half-adder circuit is shown in FIG. 3. The illustrated half-adder circuit includes a XOR gate 70 and an AND gate 72, each having input terminals connected to receive input bits X.sub.i and Y.sub.i. The XOR gate 70 determines the sum output S.sub.i =X.sub.i .sym.Y.sub.i, and the AND gate 72 determines the output carry C.sub.i+1 =X.sub.i Y.sub.i.

In practice, a carry-save array multiplier 2 such as illustrated in FIG. 1 can produce the product of two numbers A and B relatively quickly. In other words, such circuits have relatively little latency as expressed in terms of clock cycles. However, such circuits are also characterized by the fact that they must completely process one set of numbers before they can begin multiplying a new set of numbers. More specifically stated, the multiplier 2 of FIG. 1 must wait at least for the carry bit from adder 12 to propagate completely through adders 22, 32, 42, 52, 54, 56 and 58 before the most significant bit P.sub.8 of the product P is determined. Then, and only then, can the multiplier begin processing another set of numbers to be multiplied. Thus, despite its high speed with respect to multiplying any given pair of numbers, the output frequency of the multiplier 2 of FIG. 1 is relatively slow in terms of the number of different numbers which can be multiplied in a given time period. Additionally, it can be said that the overall efficiency of the circuit of FIG. 1 is low because the individual full-adders in the circuit are idle during most of the processing cycle.

To increase the output frequency of multi-stage datapath elements such as multiplier 2 of FIG. 1, pipelining stages can be inserted between one or more of these stages. These pipelining stages are, in essence, storage registers which store partial results produced by a preceding functional stage. Also, in multipliers, pipelining stages can be used to store the multiplier and multiplicand for processing in the late adder stages. In its simplest implementation, a pipelining stage usually consists of two to four D-type flip-flops where each flip-flop functions to temporarily store a single output bit from the previous adder stage as well as a single input bit for a following stage. The advantage of inserting a pipelining stage in a multi-stage datapath element such as a multiplier is that, after an adder stage transfers its partial products to a pipelining stage, the adder stage is freed to being processing another set of numbers.

FIG. 4 shows a carry-save array multiplier having pipelining stages inserted between its adder stages. For the sake of simplicity, only the first few stages of the multiplier are shown. By use of the pipeline stages, the multiplier of FIG. 4 can provide a higher output frequency, since the multiplier is able to begin processing a second pair of numbers before it completes the processing of a first pair of numbers. The pipelining stages, however, increases the number of stages through which the partial products must propagate in the multiplier. Accordingly, the pipelining stages will ordinarily increase the latency of the multiplier.

At this juncture, it should be realized that it is not necessarily required or practical to insert pipelining stages between each adder stage in an arithmetic unit such as a multiplier. Also, it should be realized that the delays through the different adder stages in the multiplier of FIG. 1 are not necessarily the same. For instance, the ripple carry adder 50 typically requires more time to complete its processing cycle than does any one of the first four adder stages and, hence, has a greater delay. Accordingly, rather than placing pipelining stages between each of the stages of the multiplier, it might be more practical, for instance, to place pipelining stages only after the second and fourth adder stages. In that case, the operating frequency of the multiplier would be determined by the maximum delay through the processing stages that are located between two pipeline stages. According to this example, hardware requirements would be reduced while, nevertheless, increasing the multiplier's output frequency and minimizing the increase in its latency.

To determine the minimal, or near minimal, number of pipeline stages which are required to be added to a multi-stage element such as the multiplier of FIGS. 1 and 4, it is necessary to determine the delay through the individual stages of the element. One way of estimating those delays is by modelling an element at the gate level (i.e., gate by gate). According to the gate-level modelling method, datapath elements are considered in terms of their component individual gates, each having an associated delay; the, the sum of the delays through all of the gates along a path provides an estimate of the total delay of the datapath element. For example, the delay through the full adder of FIG. 2 could be estimated by summing the delays along the path comprised of the two XOR gates 60 and 62. However, the gate-level approach to modelling delays is not always efficient. The inefficiencies in the methodology arise because, in elements having parallel data paths, gates can be sometimes removed without changing the maximum delay of the overall element. Moreover, gate-level modelling usually is time-consuming and calculation intensive. Because of such deficiencies, gate-level modelling is considered to be impractical in most circumstances.

Another known method of estimating delays through datapaths is by modelling the delays of a datapath element-by-element. However, such element-level modelling has the shortcoming that it does not indicate whether the timing of the datapath will change when pipeline stages are added to the elements in the datapath. Moreover, element-level modelling does not indicate the positions in elements at which pipeline stages should be added to decrease the cycle time of a datapath.

Thus, a modelling method is needed for estimating delays encountered in individual stages of multi-stage datapath elements. In one modelling method which meets this need, the delay through the stages of datapath elements can be modelled by a functional relationship depending, inter alia, upon the number of bits in communication with a stage of a datapath element. For example, one particularly suitable modelling equation is:

where D.sub.s is the stage delay, D.sub.b is a delay which is proportionate to the number of bits in the datapath element, N.sub.b is the number of bits in the datapath element, and C is a constant which represents a delay which is independent of the number of bits in the datapath. For stages in which operations upon a bit are not dependent operations on other bits, D.sub.b is set equal to zero.

The preceding equation (1) can be readily applied to ripple-carry adders such as are typically found in adders, ALU's and multiplier elements. Such adders have delays which result from communications within the elements and which, therefore, can be estimated as being proportionate to the number of bits in the datapath element. On the other hand, components of elements which do not exchange or communicate signals do not have delays which are proportionate to the number of bits in the datapath. Thus, for components of an element that have no bit-dependent delay, the parameter D.sub.b can be set to zero.

To illustrate the use of equation (1) for estimating delays through multi-stage datapath elements, reference will be made to FIG. 5. In FIG. 5, an N.times.M bit array multiplier consists of M columns of carry-save adders and an N bit column composed of a ripple-carry adder. An input buffer is provided before the first adder stage to temporarily store the multiplicand and the multiplier. As illustrated in FIG. 5, the input buffer stage has an estimated stage delay D.sub.s equal to C, each carry-save adder has an estimated delay of A, and the final ripple-carry adder has an estimated delay of BN+D.

By applying equation (1) to the multiplier of FIG. 5, the delay through the first four stages can be modelled s C+3A. The delay through the three middle stages can be modelled as 3A. the delay through the final ripple-carry adder can be modelled as BN+D. Finally, the entire N.times.M bit multiplier could be modelled as having total estimated delay of AM+BN+C+D, where A is the constant delay through the carry-save adder, B is the delay per bit for the ripple-carry adder, C is the input buffer delay, and D is the constant delay of the ripple-carry adder.

In FIG. 6 there is shown a multi-stage datapath element comprising the multiplier of FIG. 5 with pipelining stages inserted such that there is a pipelining stage after every third carry-save adder. Thus, the modified multiplier would include a plurality of segments having a delay of 3A+C and a final segment (i.e., the ripple carry adder stage) having a delay of BN+D. It should be noted that each adder stage would require an additional input buffer to store the multiplicand and multiplier for processing by the particular segment. Also, with the pipeline stages inserted at the indicated locations, the minimum cycle time of the multiplier would be the sum of the delays introduced by the pipeline stages plus the maximum of 3A+C and BN+D.

It can now be understood that the above-described modelling technique reflects the fact that multi-stage datapath elements generally include repetitive logic cells. By recognizing this repetitiveness, the modelling technique provides sufficient detail for determining pipelining stage placement while requiring relatively less processing time or computational capacity than gate-level modelling.

A more generalized technique for inserting pipelining stages in multi-stage datapath elements will be discussed with reference to FIG. 7. This technique may be incorporated, for example, into automated integrated circuit design systems.

The initial step in the process diagrammed in FIG. 7 is to select a maximum desired delay D.sub.M. This delay is normally approximately equal to the inverse of the desired operating frequency of a datapath element and might, for example, be determined by operating frequencies of other functional elements in the datapath. Also initially, an element stage counter I is initialized to zero and an accumulated delay variable D.sub.T is set to zero.

The next step in the process diagrammed in FIG. 7 is to calculate the delay associated with an initially designated stage of the element. In practice, the initially designated stage is usually the last data-processing stage of the element to be analyzed. For the designated stage, the calculated stage delay, D.sub.I, is then compared with the maximum delay D.sub.M. If the delay D.sub.I of the initially-designated stage is greater than the maximum delay D.sub.M, the maximum delay D.sub.M is reset to a value equal to the individual stage delay and the process is begun again. Otherwise, the total accumulated delay D.sub.T is incremented by the stage delay time of the next adjacent stage of the element. The incremented total delay D.sub.T is then compared with the maximum delay time D.sub.M. If the value D.sub.T is less than the value D.sub.M, the stage counter is incremented and the delay is calculated for the next stage.

In practice, the process diagrammed in FIG. 7 is continued until a stage of the datapath element is identified whose addition causes the accumulated delay D.sub.T to exceed the maximum delay D.sub.M. At that time, a pipelining stage is inserted prior to the identified stage and the accumulated delay D.sub.T is set equal to the delay of the identified stage plus the delay inherent to the added pipelining stage. (In terms of data flow through a multi-stage element wherein the initially designated stage is the last data-flow stage, the pipelining stage would be inserted "downstream" from the stage which caused the accumulated delay D.sub.T to exceed the maximum delay D.sub.M.) Then, the stage counter is incremented, and the process is continued with consideration of the next stage of the element. The process proceeds in the above-described manner through each of the individual stages of the datapath element.

At this juncture, it can be appreciated that the essence of the above-described process is that the cumulative delay through a multi-stage datapath element is calculated stage-by-stage and, whenever a considered stage would result in a cumulative delay greater than the desired maximum delay, a pipelining stage is inserted in the element. In this way, the pipelining stages are placed within an element at maximum, or near maximum, distances from one another. The result of the above-described process, therefore, is to increase operating frequency of a multi-stage datapath element with only minimal increase in its latency.

In practice, it is often desirable that the maximum early D.sub.M associated with an initially designated stage of an element reflect, additionally, the delay through an independent element which precedes, or follows, the designated stage on terms of data flow. (Where the initially designated stage of an element is the last data-processing stage of the element, the independent element would be one that followed the initially designated element in terms of data flow; on the other hand, where the initially designated stage of an element is its first data processing stage, the independent element would precede the initially designated element.) Also in practice of the above-described process, account must be taken of set-up and output delay times as well as the delay of any pipelining stages in the element. Such pipelining stages include ones which reside in an element prior to the above-described analyses as well as ones added to the element as a result of the analysis.

Although the principles, preferred embodiments and modes of operation of the present invention have been described in the foregoing specification, the invention which is intended to be protected herein is not to be construed as limited to the particular forms disclosed. Rather, the disclosed forms are to be regarded as illustrative rather than restrictive. Those skilled in the art will recognize that variations and changes may be made without departing from the spirit and scope of the invention.