Patent Description:
A floating-point number comprises a mantissa (m) having a bit length of 'b' bits, an exponent (e) having a bit length of 'a' bits and optionally a sign bit (s) to represent a binary number. In some widely used formats the exponent is biased (i.e. offset) by a value (c) so as to represent numbers smaller than <NUM> and is used to encode exceptional values at its end points. For non-extremal values of e, the floating-point number x is said to be normalized and the number x is represented as (-<NUM>)s<NUM>e-c(<NUM> + <NUM>-bm). When e = <NUM>, the floating-point number x is said to be denormal and the number is represented as (-<NUM>)s<NUM><NUM>-c<NUM>-bm. This includes the value <NUM> which is obtained by letting m = <NUM>. Thus, floating point numbers can be used to represent very small or very large numbers precisely using scientific notation, in binary or in some other base. The use of floating-point numbers in arithmetic computations provides varying degrees of precision depending on the bit length or type of floating-point format used.

Computations involving sums of large arrays of real valued numbers occur commonly in the solution of various numerical problems. For example, such sums can occur as part of a dot product calculation. It is therefore advantageous to have hardware dedicated to performing summations in high performance computing systems, graphic processing systems, neural network accelerators and the like. Conventionally, there are different ways to achieve this, with different benefits and drawbacks.

A known method in computing systems, to do addition of a set of floating-point numbers is by accumulation. This form of sequential summation uses a floating point adder and adds each input number in turn into a floating point accumulator. An adder unit <NUM> using this principle is shown in <FIG>. The adder unit <NUM> comprises a multiplexer <NUM>, and an adder <NUM>. An array of floating-point numbers x<NUM>, x<NUM>,. xn are provided as input to the multiplexer <NUM>. The multiplexer <NUM>, in each cycle, provides a floating-point number as a first input to the adder <NUM>. The adder <NUM> accumulates or adds each floating-point number to a second input. The output (sum) generated by the adder <NUM> is fed back to the adder as the second input. The output from the adder in each step is rounded which causes a rounding error in the output generated in each cycle. The rounding error is a characteristic feature of floating-point calculations.

Thus, each floating-point number is added to a previously calculated output (sum) to generate a new or cumulative output. In other words, the overall sum is performed as a sequence of individual sums of two numbers. A final output (y) generated after adding all the floating-point numbers in the array is provided as the output of the adder unit <NUM>. Thus, performing the sequential summation will yield of throughput of <NUM>/(n-<NUM>) in the case of n input numbers. Further, when very small numbers are added to very large values, large cancellation errors may occur by rounding.

Architectures that provide more throughput can be obtained by using multiple floating-point adders. For example, using n-<NUM> floating point adders one can accumulate the sum of n floating point numbers in a pipelined manner, with a throughput of <NUM>. Further, using a sequential chain of floating point adders will give a latency of (n-<NUM>) cycles as for accumulation.

Hence, existing methods and architectures for processing floating-point numbers have drawbacks. <CIT> relates to an integrated circuit that performs floating-point addition or subtraction operations involving at least three floating-point numbers. The floating-point numbers are preprocessed by dynamically extending the number of mantissa bits, determining the floating-point number with the biggest exponent, and shifting the mantissa of the other floating-point numbers to the right. Each extended mantissa has at least twice the number of bits of the mantissa entering the floating-point operation. The exact bit extension is dependent on the number of floating-point numbers to be added. The mantissas of all floating-point numbers with an exponent smallerthan the biggest exponent are shifted to the right. The number of right shift bits is dependent on the difference between the biggest exponent and the respective floating-point exponent. <NPL>) relates to the design of a component to perform parallel addition of multiple floating-point (FP) operands, in particular, a <NUM>-input FP adder. <NPL>) relates to a multi-operand adder for performing algorithms including a lot of addition operations.

A method and system for processing a set of 'k' floating point numbers to perform addition and/or subtraction is disclosed herein. Each floating-point number comprising a mantissa (mi) and an exponent (ei). The method comprises receiving the set of 'k' floating point numbers in a first format. The method further comprises creating a set of 'k' numbers (yi) based on the mantissas of the 'k' floating-point numbers. The method includes identifying a maximum exponent (emax) among the exponents ei, aligning the magnitude bits of the numbers (yi) based on the maximum exponent (emax) and processing the set of 'k' numbers concurrently.

According to a first aspect there is provided a method of processing a set of 'k' floating point numbers to perform addition and/or subtraction as claimed in claim <NUM>.

Optionally, the set of 'k' floating point numbers comprises unsigned floating point numbers that explicitly include a leading bit.

Optionally, the set of 'k' floating point numbers comprises unsigned floating point numbers that implicitly includes a leading bit and x ≥ <NUM>.

Optionally, the set of 'k' floating point numbers comprises signed floating point numbers that explicitly include a leading bit and x ≥ <NUM>.

Optionally, the set of 'k' floating point numbers comprises signed floating point numbers that implicitly includes a leading bit and x = <NUM>.

Optionally, adding the extra most-significant bits comprises adding at least <MAT> number of the most-significant bits.

Optionally, adding the extra least-significant bits comprises adding at least <MAT> <NUM> number of the least-significant bits.

Optionally, adding the extra most-significant bits comprises adding a leading bit if the received set of 'k' floating point numbers in the first format implicitly include a leading bit.

Optionally, the method comprises forming the magnitude bits of the numbers (yi) by prefixing the bits of the mantissa mi of the floating-point number with the leading bit.

Optionally, the method further comprises: calculating an output value by processing 'k' numbers (yi); renormalizing the output value; and rounding the output value to represent the output value as a floating-point number.

Optionally, aligning the magnitude bits of the numbers (yi) to be based on the maximum exponent (emax) comprises the steps of, for each floating-point number (i): calculating the difference (ed) between the maximum exponent (emax) and exponent (ei); and shifting the magnitude bits of the corresponding number (yi), to the LSB side, based on the calculated difference (ed).

Optionally, further to shifting the magnitude bits of the numbers, the method further comprises truncating the bits of the numbers that are shifted outside the bit-length of the number.

Optionally, the method further comprises determining a two's complement of the magnitude bits of the numbers, based on a sign bit (si) of each corresponding number, if the set of 'k' floating point numbers comprises signed floating point numbers.

Optionally, identifying the maximum exponent is performed by determining the largest value among the exponents ei in the set of `k' floating point numbers.

Optionally, processing the 'k' numbers comprises calculating a sum value by performing an 'n' bit carry save addition.

Optionally, processing the set of 'k' floating point numbers generates the same output value irrespective of the order in which the set of 'k' floating point numbers are provided as inputs.

According to a second aspect, there is a provided a hardware implementation for processing a set of k floating point numbers to perform addition and/or subtraction as claimed in claim <NUM>.

Optionally, the format conversion unit receives the set of 'k' floating point numbers in a first format comprising unsigned floating point numbers which explicitly includes a leading bit.

Optionally, the format conversion receives the set of 'k' floating point numbers in a first format comprising unsigned floating point numbers which implicitly includes a leading bit and x ≥ <NUM>.

Optionally, the format conversion unit receives the set of 'k' floating point numbers in a first format comprising signed floating point numbers which explicitly includes a leading bit and x ≥ <NUM>.

Optionally, the format conversion receives the set of 'k' floating point numbers in a first format comprising signed floating point numbers which implicitly includes a leading bit and x ≥ <NUM>.

Optionally, further comprises a renormalizing unit configured to: renormalize the output value; and round the output value to represent the output value as a floating-point number.

Optionally, the format conversion unit converts the mantissa (mi) by adding a leading bit, if the received set of 'k' floating point numbers in the first format implicitly include a leading bit.

Optionally, the format conversion unit prefixes each mantissa (mi) with the added leading bit while creating the numbers.

Optionally, the alignment unit aligns the magnitude bits of the numbers to be based on the maximum exponent (emax), wherein the alignment unit comprises: a plurality of subtraction units,
wherein each subtraction unit is configured to calculate the difference (ed) between the maximum exponent (emax) and exponent (ei) for each floating-point number (i); and a plurality of shifter units, each shifter unit configured to shift the magnitude bits of the corresponding number, to the LSB side, based on the calculated difference (ed).

Optionally, the alignment unit further truncates the bits of the numbers that are shifted outside of the bit length of the numbers.

Optionally, the alignment unit further comprises a plurality of complementing units configured to determine two's complement of the magnitude bits of each number, based on a sign bit (si) of the corresponding number, if the set of 'k' floating point numbers comprises signed floating point numbers.

Optionally, the format conversion unit converts the mantissa (mi) of the set of 'k' floating point numbers to the set of 'k' numbers by adding at least <MAT> number of extra most-significant bits to the mantissa (mi).

Optionally, the format conversion unit converts the mantissa (mi) of the set of 'k' floating point numbers to the set of 'k' numbers by adding at least <MAT> number of extra least-significant bits to the mantissa (mi).

Optionally, the plurality of shifter units perform the shifting of magnitude bits in parallel, reducing the delay to a considerable extent.

Optionally, the plurality of shifter units and the plurality of the complementing unit are implemented one after the other in any order.

Optionally, processing unit is a carry save adder circuit capable of adding `k' the numbers to generate a sum value as the output value.

According to a third aspect, there is a provided computer readable code configured to cause the method of the first aspect to be performed when the code is run.

According to a fourth aspect, there is a provided a computer readable storage medium having encoded thereon the computer readable code of the third aspect.

The hardware implementation of an adder according to the first aspect discussed above may be embodied in hardware on an integrated circuit. There may be provided a method of manufacturing, at an integrated circuit manufacturing system, an adder. There may be provided an integrated circuit definition dataset that, when processed in an integrated circuit manufacturing system, configures the system to manufacture an adder. There may be provided a non-transitory computer readable storage medium having stored thereon a computer readable description of an adder that, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit embodying an adder.

There may be provided an integrated circuit manufacturing system comprising: a non-transitory computer readable storage medium having stored thereon a computer readable description of the a hardware implementation of an adder according to the first aspect discussed above. ; a layout processing system configured to process the computer readable description so as to generate a circuit layout description of an integrated circuit embodying the adder; and an integrated circuit generation system configured to manufacture the adder according to the circuit layout description.

When improving the computation performance of processing floating-point numbers, such as performing addition or subtraction, the accuracy of the output generated, and the computational speed are the two primary criteria considered.

Some arrangements of floating point adders providing faster computation include arrangements for performing parallel summation. These can be also be used to reduce the latency of the network. For example, a particular implementation of a network of floating point adders for performing parallel summation and aimed at reducing latency is shown in <FIG>. The tree adder <NUM> in <FIG> comprises a plurality of adders 202a, 202b. <NUM>, arranged in a balanced structure. Each adder is configured to receive two inputs and generate an output (sum) of the two inputs. Using the tree adder <NUM>, addition of 'n' floating-point numbers can be realized using <MAT> stages.

In the example given in <FIG>, an array of <NUM> floating-point numbers (x<NUM>, x<NUM>,. x<NUM>) is provided as input to the tree adder <NUM>. In a first stage, two (different) inputs of the array are provided to each of four adders (primary adders) in the plurality of adders. Thus, <NUM> floating point numbers are provided as input to four primary adders (202a, 202b, 202c and 202d). Each adder generates a first output value y, thereby generating four first output values (y<NUM>, y<NUM>, y<NUM> and y<NUM>). During a second stage, two (different) values of the first output values are provided as input to each of two adders (secondary adders) among the plurality of adders. Thus, four first outputs are provided as inputs to two secondary adders (202e and 202f). Each secondary adder (202e and 202f) generates a secondary output, thereby generating two secondary output values (ys and y<NUM>). Further, in a third stage, the two secondary output values are provided as input to a tertiary adder <NUM>. The tertiary adder <NUM> generates a final output y<NUM> which is the sum of the array of <NUM> floating-point numbers. Thus, the addition of <NUM> floating point numbers can be performed in <MAT> stages (i.e. <NUM> stages).

Further, in generalized examples the tree adder need not be a balanced structure as shown in <FIG>. The tree adder can instead add the floating-point numbers using a single adder at every different stage. For example, any two floating point numbers are added in a first stage to generate a first sum value. Further, the first sum value is added to another floating-point number in a second stage using a second adder to generate a second sum value and so on. The latency of the arrangement increases in this example compared to a balanced tree adder.

However, in all these examples and the example provided in the background, in each stage the output values are rounded or truncated in order to fit the output value into its finite representation. Multiple rounding may result in dramatic cancellations. For different orders in which each input is provided to a tree adder, different outputs are generated. A dramatic cancellation can occur when very small numbers are added to very large ones, and may cause significant bits of the result to be lost due to rounding. , when summing a large positive number, P, the corresponding negative number, -P, and two small positive numbers Q and R, the precise value of the sum is (Q+R). An arrangement of floating point additions summing P and -P in a first primary adder and Q and R in a second primary adder ought to give the final result (Q+R). However, if the inputs are ordered differently and the primary adders perform the sums (P+Q) and (-P+R), and P is much larger than Q and R, then the outputs of the primary adders could be rounded to P and -P, giving an overall output of <NUM>. Similar effects can be observed in an accumulator architecture.

As discussed above, the existing methods of processing floating point numbers, such as performing addition using accumulators or binary tree adders, generate output values of varying precision based on the order in which the numbers are provided as the input. That is, a certain order of providing the inputs generates the best result which is the closest approximation to the actual sum of the numbers. Other orders of providing the inputs may generate results which are not so close to the actual sum of the numbers. Thus, based on the order in which the inputs are provided, there could be a range of results obtained, around the actual sum of the floating-point numbers.

The varying precision of the results obtained is due to reasons such as truncation errors or rounding errors, and dramatic cancellation as discussed earlier. Also, the delay in performing addition using an accumulator for a large array of numbers is drastic, as the addition happens sequentially. Even though the method of performing addition using a binary tree adder enables parallel summation, the addition still needs to be performed in various stages to generate a final output value. Further, re-normalizing and rounding is performed in each stage, which increases the delay in generating the output value. Therefore, there is a need for a method of processing a set of floating-point numbers more precisely and with less delay.

Described herein is a hardware implementation and method of processing a set of k floating-point numbers concurrently. The method includes converting each floating-point number, received in a first format, to a number in a second format for processing. Further, the method includes processing the numbers in the second format concurrently (e.g. obtaining a sum by performing a single sum over all the numbers in the set, in contrast to performing multiple sums across the set) to generate an output value.

<FIG> is a block diagram illustrating an example of an implementation of an architecture for processing a set of k floating-point numbers. The architecture <NUM> is an adder performing addition or subtraction of the set of k floating-point numbers (x<NUM>, x<NUM>, x<NUM>. xk-<NUM>) to generate an output value. The architecture is particularly suitable for adding large arrays of numbers, but can be used to add two, or more than two, numbers as required. The architecture <NUM> comprises a format conversion unit <NUM>, a maximum exponent detection unit <NUM>, an alignment unit <NUM>, a processing unit <NUM>, and a re-normalizing unit <NUM>. Each number in the set of 'k' floating-point numbers comprises a mantissa mi with a bit length of 'b' bits and an exponent ei with a bit length of 'a' bits. The set of 'k' floating-point numbers may be signed numbers or unsigned numbers. In the case of signed numbers, the numbers would also each comprise a sign bit si as well as the mantissa and exponent. However, some floating-point formats (e.g. unsigned formats) may not include a sign bit.

The set of 'k' floating-point numbers (x<NUM>, x<NUM>, x<NUM>. xk-<NUM>) can be received in an input unit <NUM>. The input unit <NUM> can be a storage or a memory unit that can store the received inputs. The set of 'k' floating-point numbers (x<NUM>, x<NUM>, x<NUM>. xk-<NUM>) are stored in an incoming, first, format, and are hereinafter referred to as numbers in the first format. The format conversion unit <NUM> receives mantissas (m<NUM>, m<NUM>, m<NUM>. mk-<NUM>) of the set of 'k' floating-point numbers from the input unit <NUM>. The format conversion unit <NUM> converts mantissas (m<NUM>, m<NUM>, m<NUM>. mk-<NUM>) to 'k' numbers in a different, second format (y<NUM>, y<NUM>, y<NUM>. yk-<NUM>), as described in more detail below.

The bit-length of the mantissa and exponent of the numbers in the first format is identified based on the type of the floating-point number format. The first format may be a predefined format that the architecture <NUM> is designed to receive, or may be identified on a task-by-task basis (e.g. by a controller, not shown). Examples of various types of the floating-point number formats include but are not limited to IEEE formats including half precision floating-point numbers (<NUM> bit float), single precision floating-point numbers (float) and double precision floating-point numbers (double), or other formats such as a brain floating-point numbers (bfloat16). In some of the examples below, we consider IEEE single precision floating-point format as the first format having a mantissa mi with a bit length of <NUM> bits and an exponent ei with a bit length of <NUM> bits. In some other examples given below, we consider brain floating-point format as the first format having a mantissa mi with a bit length of <NUM> bits and an exponent ei with a bit length of <NUM> bits for the explanation of the method. However, it is understood that the invention is not limited to these formats and a person skilled in the art would understand that the architecture <NUM> could be implemented to use numbers in any type of the floating-point number format to perform the method described herein.

The format conversion unit <NUM> converts the floating-point numbers in the first format to numbers in the second format. This comprises converting the mantissa 'mi' of each floating-point number in the set of 'k' floating-point numbers to a number 'yi'. On receiving the set of 'k' floating-point numbers with all the numbers as unsigned floating point numbers, the format conversion unit converts the mantissa to create a set of k unsigned numbers. Similarly, on receiving the set of 'k' floating-point numbers as signed floating point numbers, the format conversion unit converts the mantissa to create a set of k signed numbers. The format conversion unit <NUM> converts the mantissa mi having a bit length of 'b' bits (in first format) to create the number 'yi' with a bit length of 'n' bits (to represent a second format). The bit length of 'n' bits is obtained by adding both one or more extra most-significant bits (MSBs) and one or more extra least-significant bits (LSB) to the mantissa (mi) of bit length 'b' bits in the first format. Thus, the bit length 'n' is always greater than the bit length `b' of the original mantissa.

If the set of 'k' floating-point numbers are unsigned floating point numbers, then the representation of unsigned numbers created, with a bit length of 'n' bits includes n magnitude bits. If the set of 'k' floating-point numbers are signed floating point numbers, then the extra MSBs added to the mantissa of the first format can comprise a bit representing a sign bit. Thus, the representation of signed numbers created, with a bit length of 'n' bits includes a sign bit and (n-<NUM>) magnitude bits. Often floating point formats will not explicitly encode the leading bit (i.e. a bit representing a digit occurring before the radix point) as it can be assumed to be <NUM> in binary floating point numbers, and thus can be implicitly coded (and so is also referred to as a 'hidden bit'). Thus, where the leading bit is a 'hidden bit' in the first format, the second format adds a bit to account for the leading bit to the bit-length of the number 'yi' in the second format. The format conversion unit forms this particular magnitude bit of the number 'yi' by prefixing the bits of the mantissa of the floating-point number with a leading bit having a value based on the value of the floating point number encoded (i.e. whether it is a normal or denormal number). In this second format, as output by the format conversion unit, each number could be considered to effectively be a combination of a sign bit (if added) with a floating point mantissa of extended bit width, with the radix point occurring at the same position with respect to the bits representing the magnitude of the mantissa in the first format - the second format just includes extra bits both before and after where the radix point would occur.

The numbers in the first format are converted to numbers in the second format based on the number of floating-point numbers (k) in the set. That is, the number of extra MSBs and LSBs added to the mantissa (mi) of the first format is determined based on the number `k'. The mantissa mi is extended to the MSB side by at least a logarithmic amount of the number 'k' ( <MAT>) bits and to the LSB side by at least a logarithmic amount of the number `k-<NUM>' ( <MAT>) bits to obtain the number 'yi'. Preferably, assuming the first format is a signed floating point number that has an implicit leading bit and treats any sign bit as separate from the mantissa, <MAT> extra MSBs and <MAT> are added on either side of the bit length `b' of mantissa mi. That is, two additional bits (other than the <MAT>) bits) in the extra MSBs added are assigned for the implicit leading bit (or hidden bit) and the sign bit si. The additional bit (other than the <MAT>) bits) in the extra LSBs added is a precision bit, for obtaining extra precision. The extra MSBs and LSBs added prevents overflow or underflow of bits, while processing the set of 'k' numbers which is explained in detail later. The numbers of extra MSBs and LSBs added to each side could be same or different in different examples. In general, the bit length 'n' of the number 'yi' in the second format can be obtained as <MAT> Where x is an integer and preferably x ≥ <NUM>, where the value of x depends on the number of extra bits added to represent leading bit, sign bit and precision bits, if any.

<FIG> illustrates the representation of mantissa (mi) in a first format and <FIG> illustrates the representation of signed number 'yi' in a second format. In <FIG>, the first format is shown as a brain floating point number with a mantissa bit length, b, of <NUM> bits. <FIG> shows the signed number represented in a second format. The representation in the <FIG> illustrates signed number 'yi' with a bit length of <MAT>. This is obtained by adding log<NUM>(k) + <NUM> extra MSBs and log<NUM>(k - <NUM>) + <NUM> extra LSBs to the bit-length 'b' of the mantissa. Thus, in an example when a set of <NUM> floating point numbers, of bit length <NUM> as shown in <FIG>, are added, i.e. k=<NUM>, then the signed number in the second format will have a bit length of n=<NUM> bits.

It is clear from the example in <FIG>, that the number 'yi' represented in a second format, as defined herein, comprises a bit assigned for representing a sign bit (si), a bit assigned for representing a leading bit (LB) (i.e. hidden bit, not explicitly coded in the first format for the sake of efficiency) and a further <MAT> bits as extra MSBs, and <MAT> extra LSBs. As such, the number 'yi' of the second format is a signed number and comprises both a sign bit and magnitude bits (i.e. the bits indicating the absolute magnitude of the represented value). The sign bit is assigned as a '<NUM>' or '<NUM>' bit based on whether the number is a positive or negative number. As explained above, if all the floating-point numbers in the set of 'k' floating-point numbers in the example were unsigned numbers, then the second format could be represented by adding <MAT> extra MSBs comprises a bit representing a leading bit and <MAT> bits. Further, if all the floating-point numbers in the set of 'k' floating-point numbers represented in the first format in the example were unsigned numbers and contained an explicit leading bit, then the signed number 'yi' could be represented by adding <MAT> extra MSBs to the bit-length b of mantissa mi.

In the example shown in <FIG>, the number 'yi' comprises <MAT> extra LSBs added to the mantissa mi. The number 'yi' could comprise <MAT> extra LSBs added to the mantissa (mi), where r is any integer, r≥<NUM>. Preferably, the number 'yi' comprises <MAT> extra LSBs added to the mantissa (mi). The extra LSBs added to the mantissa mi increases the precision of the result obtained and reduce underflow of mantissa bits while aligning the number 'yi' which is explained in detail below.

Thus, in the example described in the above paragraphs where the first format is a signed floating point number that has an implicit leading bit, the number of additional bits x ≥ <NUM>. Further, in another example assuming the first format is a signed floating point number that has an explicit leading bit, <MAT> extra MSBs and <MAT> are added on either side of the bit length `b' of mantissa mi to create the number 'yi', thus making the number of additional bits x ≥ <NUM>.

Similarly, in another example case, assuming the first format is an unsigned floating point number that has an implicit leading bit, <MAT> extra MSBs and <MAT> extra LSBs are added on either side of the bit length `b' of mantissa mi to create the number 'yi', thus making the number of the additional bits x ≥ <NUM>. Further, in another example case, assuming the first format is an unsigned floating point number having an explicit leading bit, <MAT> extra MSBs and <MAT> extra LSBs are added on either side of the bit length `b' of mantissa mi to create the number 'yi', thus making the number of additional bits x ≥ <NUM>.

Thus, although it might be expected that more than b additional bits would be required to preserve the desired precision, in fact (as confirmed by the mathematical proof presented later) it is possible to achieve the desired precision with less than or equal to b additional bits, and in the examples above the desired precision can be achieved with the number of additional bits x less than or equal to three bits.

Thus, in a generalized example, x ≥ <NUM> and x ≤ 'b' bits, making the maximum bit length of number 'yi', <MAT>.

The extra MSBs and LSBs added to the mantissa other than the sign bit and the leading bit are initially assigned '<NUM>' bits in the second format. The sign bit is assigned as a '<NUM>' or '<NUM>' bit based on whether the number is a positive or negative number. The leading bit is assigned as a '<NUM>' bit or '<NUM>' bit based on the type of the floating-point number format. In an example, a '<NUM>' bit is added as the leading bit when the floating-point number is a normalised non-zero number and a '<NUM>' bit is added as the leading bit when the floating-point number is a zero or denormalised number.

Further, the exponent 'ei' (e<NUM>, e<NUM>, e<NUM>, e<NUM>. ek-<NUM>) of each number in the first format is provided as an input to the maximum exponent detection unit <NUM>. The input 'ei' to the maximum detection unit is provided from the input unit <NUM> as shown in <FIG>. In some other arrangements, the exponents may be passed through the format conversion unit to the maximum exponent detection unit <NUM>.

The maximum exponent detection unit <NUM> identifies the maximum exponent (emax) from the exponents of the set of k numbers. The maximum exponent detection unit <NUM> detects the maximum exponents using various methods or functions. An example of a method of identifying the maximum exponent is using a binary tree structure. A method of identifying the maximum exponent (emax) is described in detail, below, with reference to <FIG>. However, which option is preferable may depend on the available resources (e.g. parallel processing may be faster overall, but more computationally intensive).

In addition to being provided to the maximum exponent detection unit <NUM>, the exponent values ei are provided, from the input unit <NUM>, as input to the alignment unit <NUM>. The alignment unit <NUM> receives the exponent 'ei' of each floating point number in the first format as a first input. The alignment unit <NUM> further receives the maximum exponent (emax) from the maximum exponent detection unit <NUM> as a second input and the number 'yi' from the format conversion unit <NUM> as the third input. The alignment unit <NUM> aligns the magnitude bits of each number 'yi', thereby converting the number 'yi' to a different number (or integer pi) with a bit-length of n bits based on the maximum exponent. The method of aligning the number 'yi' is explained in detail with reference to <FIG>, but in summary the numbers in the second format are adjusted to be based on the maximum exponent, and the adjusted numbers (p<NUM>, p<NUM>, p<NUM>. pk-<NUM>) are treated for convenience as integers for the subsequent processing in the processing unit <NUM>.

Thereafter, the k integers (p<NUM>, p<NUM>, p<NUM>. pk-<NUM>) thus generated are provided to the processing unit <NUM>. The processing unit <NUM> is an adder unit. The processing unit <NUM> processes the k integers (i.e. the k aligned numbers) concurrently. That is the processing unit performs a process on all the integers in the set at the same time rather than, for example, processing elements of the set sequentially. The processing unit <NUM> performs addition and/or subtraction of the k integers to generate an output value q. It is noted that addition of a negative number to a positive number is equivalent to performing a subtraction, and so the term processing is used herein to cover the acts of both addition and subtraction, alone or in combination.

The output value q from the processing unit <NUM> and the maximum exponent from the maximum exponent detection unit <NUM> is further provided into the re-normalizing unit <NUM>. The renormalizing unit <NUM> converts the output value from the processing unit to a floating-point number, for example represented in the first format (but optionally represented in a different format, e.g. a third format, if desired), with a mantissa mi and exponent 'ei'. The output unit <NUM> stores the converted output value (i.e. the output floating point number).

<FIG> is a block diagram illustrating the different units in the implementation of the architecture <NUM> in <FIG>. Consider a scenario where the set of k floating point numbers in the first format comprises four numbers, i.e. k=<NUM>. The format conversion unit <NUM> receives the set of four floating point numbers xi (x<NUM>, x<NUM>, x<NUM>, xs) as input. The format conversion unit <NUM> converts the set of <NUM> numbers in the first format to four numbers yi in the second format as described with reference to <FIG>. In this example, consider the set of k floating point numbers in the first format are four signed floating point numbers with an implicit leading bit. Therefore, the set of k floating point numbers are converted to four signed numbers having a bit-length of n bits including a sign bit si and (n-<NUM>) magnitude bits fi. In other example cases, the set of k floating point numbers in the first format could be unsigned floating point numbers.

The exponent 'ei' of each number (e<NUM>, e<NUM>, e<NUM>, and e<NUM>) from the input unit <NUM> is provided to the maximum exponent detection unit <NUM>.

The maximum exponent detection unit <NUM> in <FIG> comprises three maximum function logics 504a, 504b and 504c. This is by way of example only, and other implementations may have a different structure for finding the maximum exponent, or similar structures but with a different number of logics to account for a different number of inputs.

In the depicted example, the maximum function logic (max1) 504a receives the exponents e<NUM> and e<NUM>. The maximum function logic (max2) 504b receives the exponents e<NUM> and e<NUM>. The maximum function logic 504a identifies the maximum exponent value among e<NUM> and e<NUM>. The maximum function logic 504b identifies the maximum exponent value among e<NUM> and e<NUM>. Further, the output of the maximum function logic 504a and the maximum function logic 504b are provided to the maximum function logic (max3) 504c. The maximum function logic 504c identifies the maximum exponent value among the output of the maximum function logic 504a and the maximum function logic 504b to detect the emax i.e. the maximum exponent among the input exponents e<NUM>, e<NUM>, e<NUM>, and e<NUM>.

As mentioned above, the maximum detection unit <NUM> can be implemented in different other ways. For example, maximum detection unit <NUM> can be implemented using a binary search tree.

Returning to the depicted example, the maximum exponent identified by the maximum detection unit <NUM> is provided as input to the alignment unit <NUM>. Further, the exponents of the four numbers in the first format are provided as input to the alignment unit <NUM>. Further the four signed numbers 'yi' in the second format are provided as input to the alignment unit <NUM>. The alignment unit <NUM> aligns the magnitude bits fi of each signed number 'yi', based on the maximum exponent and the respective exponent of the number in the first format corresponding to the signed number. In other words, the magnitude bits of the signed numbers for which the corresponding floating point number did not already have the maximum exponent are shifted to account for the difference in exponent of the number in the first format compared to the maximum exponent (effectively adding zeros before the first (or, at least, the first non-zero) magnitude bit, and removing trailing bits as required, to realign the magnitude bits as appropriate). The alignment unit <NUM> thus converts each signed number ('yi') to another integer (pi) that is output by the alignment unit <NUM>. The integer pi is considered as a fixed point number format. Similarly, in case of unsigned numbers the alignment unit shifts the magnitude bits of the unsigned numbers based on the maximum exponent and the respective exponent of the number in the first format corresponding to the unsigned number.

The conversion of the signed number 'yi' to an integer pi is illustrated with examples shown in <FIG>. It will be appreciated, in describing this series of figures, that the starting point is the signed number 'yi' in a second format number, as output by the format conversion unit <NUM>, and the end point is the converted signed number pi (integer pi) mentioned above. However, for ease of reference, the intermediary stages may also be referred to as signed numbers in the description below.

Consider an example of a floating-point number in a first format with an implicit leading bit and a sign bit separate to the mantissa. Each number has a mantissa mi having a bit length of <NUM>-bits in the first format (such as bfloat <NUM>). Thus, in this example, each number in a set of <NUM> numbers, when converted to the second format comprises a signed number yi having a bit length 'n' (including a sign bit si), where <MAT>.

<FIG> illustrates the signed number 'yi' in the second format with a bit length of <NUM> bits. In an example, consider that the number shown <FIG> represents a signed number y<NUM> provided as input to the alignment unit <NUM>. The alignment unit <NUM> comprises a plurality of subtraction modules <NUM>. The alignment unit <NUM> further comprises a plurality of shifter units <NUM> and a plurality of complementing units <NUM>.

Each of the subtraction modules receives an exponent ei as a first input from the input unit <NUM>, the maximum exponent as a second input from the maximum exponent detection unit <NUM> and a signed number 'yi' from the format conversion unit <NUM> as a third input. The input unit <NUM> provides the original exponent 'ei' of the four numbers to each subtraction module. Each subtraction module calculates a difference 'edi' between the maximum exponent 'emax' and the exponent 'ei' of a number. In <FIG>, a first subtraction module receives an exponent e<NUM> of a first number from the input unit <NUM> and the maximum exponent emax from the maximum exponent detection unit <NUM>. The first subtraction module calculates a first difference referred to as ed0 in <FIG>. Similarly, the remaining subtracting modules calculate the differences ed1, ed2, and ed3, as shown in <FIG>. As shown, the plurality of subtraction modules calculate the differences edi for each number in parallel, but other arrangements are possible - e.g. a single subtraction module performing each subtraction in series. Returning to the example as depicted, each calculated difference ed0, ed1, ed2, and ed3 from the plurality of subtraction modules <NUM> is further provided to a corresponding shifter unit among the plurality of the shifter units <NUM>.

Each shifter unit among the plurality of shifter units <NUM> receives the calculated difference ed of a number as a first input and the magnitude bits fi of the corresponding signed number 'yi' as the second input. Further, each shifter unit among the plurality of shifter units <NUM> shifts the magnitude bits fi, of the signed number 'yi' based on the corresponding calculated exponent difference. The magnitude bits fi (except the sign bit) are shifted to the least significant bit side (i.e. the right in the depicted format) by a number of positions equal to the calculated exponent difference. <FIG> illustrates that the magnitude bits fi of signed number 'y<NUM>' of the first input include the `b bits' corresponding to the bits of the mantissa of the number in the first format, prefixed by an explicit leading bit '<NUM>'. The remaining extra bits of the signed number 'y<NUM>' are padded with '<NUM>' bits. The original `b bits' as well as the explicit leading bit are shifted by the shifter unit. Further, in <FIG>, the sign bit of the signed number y<NUM> is assigned with a '<NUM>' bit indicating that the signed number y<NUM> is a negative number. The sign bit is not shifted by the shifter unit.

In the example, a first shifter among the plurality of shifters <NUM> receives the first input (magnitude bits f<NUM> of the signed number y<NUM>), from the format conversion unit <NUM>. Further, the first shifter receives the calculated difference ed0 (in an example, for the first number having a mantissa (f<NUM>) shown in <FIG>, consider that the calculated difference ed0 (difference emax and e<NUM>) is equal to <NUM>) from the first subtraction module as the second input. Therefore, the first shifter unit shifts the magnitude bits f<NUM> of signed numbery<NUM> by <NUM> positions to the right. <FIG> illustrates the shifted number. The calculated difference ed is never a negative number. Thus, the magnitude bits fi are always shifted to the least significant bit side (i.e. to the right in the example) based on the calculated difference ed for each number, possibly by zero positions.

Similarly, the other shifter units among the plurality of shifter units <NUM> shift the magnitude bits (f<NUM>, f<NUM> and f<NUM>) of the remaining three numbers based on the corresponding calculated differences ed1, ed2, and ed3. Thus, all the shifter units in the plurality of shifter units <NUM> perform the shifting of magnitude bits fi in parallel whereas in most of the existing architectures for processing floating point numbers, the shifter shifts or aligns the mantissa in sequence as and when required which increases the delay to a considerable extent. Since, in the disclosed architecture, as the shifting or aligning of all the numbers occurs in parallel, the delay in processing could be significantly reduced as the number of floating-point numbers to be processed increases. In another implementation, it is possible that the plurality of shifter units <NUM> perform the shifting of magnitude bits fi in series despite the fact that delay is increased due to limitation on the available resources (e.g. parallel processing may be faster overall, but more computationally intensive).

It can be seen in <FIG> that the shift of the magnitude bits results in <NUM> bits being shifted out of the bit-width of the signed number (and thus out of the stored representation of the number). The shifter units truncate the bits of the signed numberthat are shifted outside the bit length of n bits. The bits corresponding to the mantissa of the original number in the first format are shifted out of the bit length of 'n' bits when the calculated exponent difference for the corresponding number is greater than the number of extra LSBs added to the mantissa mi of the number in the first format when converting to the second format. When the calculated difference is greater than the number of extra LSBs, it causes underflow of bits from the original (first format) mantissa. When the calculated difference is less than the number of extra LSBs, it only causes underflow of 'zero' bits added by the format conversion unit <NUM>. As mentioned above, <FIG> shows the <NUM> bits that are moved out of the bit length of n bits, when the bits were shifted by <NUM> bits. <FIG> illustrates the signed number after performing truncation. It is evident from the figure that though the bits are shifted by <NUM> bits, only <NUM> bits of the actual number (i.e. <NUM> bits of the mantissa of the number in the first format) is lost in this case, due to the extra LSBs that were added during conversion to the second format. Thus, the extra LSBs act to reduce the loss of precision that would occur if, for example, all numbers were shifted to use the same, maximum, exponent in the first format.

The output from the each of shifter unit <NUM> is further provided to a corresponding complementing unit among the plurality of complementing units <NUM>. The complementing units receive the aligned magnitude bits from the shifter units as a first input and the sign bit of the signed number 'yi' as a second input. However, in other arrangements, the function of the complementing unit could be performed before the function of the shifting unit or as a part of adder unit (processing unit <NUM>). In any case, the complementing unit performs the two's complement of the magnitude bits fi for those numbers having a sign bit indicating a negative number. In this case, the shifted positive signed numbers in the set are provided to the processing unit <NUM> (adder <NUM> in <FIG>) without complementing. Further, the two's complements of the negative numbers in the set are provided to the processing unit. The processing unit <NUM> receives the output from the plurality of complementing units <NUM> and processes the aligned signed numbers pi concurrently to generate the output. The output obtained from each complementing unit is an aligned number pi. <FIG> represents the number p<NUM> obtained by complementing the mantissa as shown in <FIG>.

Thus, the alignment unit <NUM> aligns the magnitude bits of the number 'yi' to generate a set of numbers (or integers) pi by performing the steps of shifting and truncating the magnitude bits fi of the number 'yi'. The alignment unit also converts to two's complement representation any numbers with a sign bit indicating the number is negative. In case of unsigned numbers 'yi', the alignment unit performing the steps of shifting and truncating the magnitude bits fi of the number 'yi'. The only difference is that there is no need of performing the step of complementing in case of unsigned number. The alignment unit <NUM> is capable of processing each number in parallel for the steps of shifting, truncating and complementing the bits of the mantissa. The number pi obtained after conversion is an integer. The number pi is represented as <MAT> assuming the exponent bias is <NUM>, in the interest of simplicity.

As shown in <FIG>, the converted numbers i.e. the integers p<NUM>, p<NUM>, p<NUM> and p<NUM> are further provided to the adder <NUM> which is the processing unit <NUM>. The signed integer p<NUM>, thus generated by performing shifting, truncating, and complementing the magnitude bits f<NUM> of the signed number y<NUM> in the example is illustrated in <FIG>. In an example, the adder <NUM> is a carry save adder capable of adding <NUM> 'n' bit integers. The value of the integer pi ranges between <MAT> and <MAT>. The carry save adder performs the addition of <NUM> signed integers pi to generate a sum value q (output).

The magnitude of the summands (i.e. the <NUM> integers pi) is less than <MAT> and hence the sum value will be less than <MAT>and does not overflow the 'n' bits. That is, the largest value integer pi will have a <NUM> in the position corresponding to the hidden bit - i.e. <MAT> bits from the MSB end (accounting for the sign bit), and the sum of k numbers of that value (i.e. considering the extreme case where all the numbers have the maximum exponent) cannot overflow the additional <MAT> bits provided at the MSB end after the sign bit. The adder <NUM> processes the set of 'k' floating point numbers to generate the same output value irrespective of the order in which the set of 'k' floating point numbers are provided as inputs.

The sum value q is further provided to the re-normalizing unit <NUM>. It will be noted that in this example the value q, like the values pi, will be a signed integer in two's complement format. The normalizing unit <NUM> comprises a shifter 510a and a subtractor 510b. The shifter 510a shifts the bits of the sum value q to generate a normalized value (in general format). The shifter 510a represents the sum value q in a normalized format by counting the number of the number of leading '<NUM>' bits or '<NUM>' bits (represented as `d') occurring continuously in the MSB's (i.e. including the sign bit). The number of leading '<NUM>' bits are counted when the sum value obtained is a non-negative number and the number of leading '<NUM>' bits are counted when the sum value obtained is a negative number. The shiftershifts the bits of the number to generate a normalized number (nk) in a normalized format. The number (nk) is further rounded to represent the normalized number (nk) with a desired bit-length - e.g. a bit length of 'b' bits if the output is to be in the same format as the input. The normalized number (nk) is represented as (assuming <MAT> MSBs were added when converting to the second format): <MAT>.

The subtractor 510b receives the maximum exponent as the first input and d (the number of leading '<NUM>'s or '<NUM>'s) and the number of extra LSBs added to the mantissa of the first format) as the input. Further, the subtractor calculates the exponent of the normalized number based on the inputs and represent the exponent over a bitlength of 'a' bits. The exponent of the final output is calculated as (again, assuming <MAT> MSBs were added when converting to the second format) <MAT>.

This is an example and it is not limited to a person skilled in the art that in other examples, different other known methods can be used to calculate the exponent ek. The final output or the sum value obtained is thus represented with a normalized mantissa (nk) and the exponent (ek).

The architecture <NUM> of the adder can be used to add any number of floating point numbers. The example shown in <FIG> is a specific example of the adder <NUM> for adding a set of <NUM> floating point numbers. Further, additional number of elements can be added to each unit in the adder <NUM> in a similar manner, thereby expanding it to add any number of floating-point numbers (for example <NUM> floating-point numbers or <NUM> floating-point numbers) concurrently.

Further the architecture <NUM> can also be used as an accumulator as shown in <FIG>, for adding multiple batches of the set of floating-point numbers, even when there are more floating-point numbers than the input of the adder. <FIG> illustrates the architecture <NUM> implemented as an accumulator design. The accumulator design <NUM> comprises an array gating unit <NUM> receiving a large array of floating point numbers (x<NUM>, x<NUM>. ,xn), an accumulator <NUM> which is an adder (<NUM>) as shown in <FIG> and a register <NUM>. Consider that the accumulator <NUM> is an adder with an architecture <NUM> capable of adding a set of <NUM> floating-point numbers concurrently. If there is an array of <NUM> floating-point numbers (x<NUM>, x<NUM>. ,x<NUM>) to be added, then the accumulator <NUM> adds the <NUM> floating-point numbers in the array in four separate batches in different clock cycles.

During a first cycle, the array gating unit <NUM> provides first <NUM> floating-point numbers in the array to the accumulator <NUM>. The accumulator <NUM> adds the first <NUM> floating-point numbers in the array (x<NUM>, x<NUM>. ,x<NUM>) with an accumulated value (c), where initially c=<NUM>, to generate a first output and store the first output as the accumulated value (c) in the register <NUM>. The first output is generated by performing addition in the same manner as described in <FIG> or <FIG>. In a second cycle, the accumulator <NUM> will add the next <NUM> floating-point numbers (x<NUM>, x<NUM>. ,e<NUM>) with the accumulated value (c) to generate a second output and pass the second output to be stored as the accumulated value. Similarly, the remaining numbers in the array are added in batches of <NUM> numbers with the updated accumulated value in every clock cycle. Thus, in a pipelined design, the addition of an array of <NUM> numbers will cost only three extra addition cycles.

<FIG> is a flowchart illustrating a method of processing a set of 'k' floating point numbers. The method includes performing addition and/or subtraction, using a hardware implementation of an architecture. Each floating-point number among the set of 'k' floating point numbers comprising a mantissa (mi) and an exponent (ei).

In step <NUM>, the method includes receiving the set of 'k' floating point numbers in a first format. Each floating-point number in the first format comprising a mantissa (mi) having a bit-length of 'b' bits and an exponent (ei) having bit-length of 'a' bits. The bit-length 'b' bits of the mantissa (mi) and the bit-length 'a' bits of the exponent (ei) in the first format is identified based on the type of the floating-point number format. Further the floating-point numbers could be signed or unsigned number with an implicit or explicit leading bit. For example, a single precision (<NUM> bit) floating point number in a first format, may typically be a signed number with an implicit leading bit that comprises a mantissa having a bit-length of <NUM> bits without including the leading bit, an exponent having bit length of <NUM> bits and an extra sign bit (si). In other examples a single precision (<NUM> bit) floating point number in a first format may be a signed number with an explicit leading bit, and then the mantissa has a bit length of <NUM> bits including the explicit leading bit.

When the single precision (<NUM> bit) floating point number in a first format is an unsigned number with an implicit leading bit there would not be any extra sign bit and the mantissa could be represented by a bit length of <NUM> bits (without including the leading bit). Further when the single precision (<NUM> bit) floating point number in a first format is an unsigned number with an explicit leading bit, the bit length of <NUM> bits of mantissa includes an explicit leading bit.

On receiving the set of 'k' floating point numbers in the first format, at step <NUM>, the method includes converting the mantissa (mi) each of the set of 'k' floating-point numbers to a number (yi). The numbers (yi) are obtained by adding both extra MSBs and extra LSBs to the bit-length 'b' of the mantissas (mi) in the first format. The bit length of b bits is extended based on the number `k' (the number of floating-point numbers in the set). In an example with the set of 'k' floating point numbers in a first format as signed numbers adding extra MBS and LSBs comprises adding preferably <MAT> number of the most-significant bits and <MAT> number of least-significant bits. The number of extra MSBs and extra LSBs added to the bit-length b of the mantissa could be the same or different. The extra MSBs added include, in this example, a bit representing a sign bit and another bit representing a leading bit. Thus, the signed number is represented with a bit-length of 'n' bits including the sign bit si and a leading bit (LB). The bit length 'n' is represented as <MAT> where x is an integer and preferably x ≥ <NUM>.

Further, the method at step <NUM> comprises identifying a maximum exponent (emax) among the exponents (ei) of the set of 'k' floating point numbers. The maximum exponent (emax) is identified by a maximum exponent detection unit <NUM>. The maximum exponent detection unit <NUM> implements an algorithm such as a maximum function for identifying a maximum value among a set of values (exponents, ei). Step <NUM> could be performed before or after the step <NUM> or could be even performed in parallel to the step <NUM>.

The method further comprises, at step <NUM>, aligning the magnitude bits of the numbers 'yi' to be based on the maximum exponent (emax). The number 'yi' is an integer represented as a fixed-point number having a bit length of n-bits. The method of aligning the magnitude bits of the numbers is discussed with respect to <FIG>. Aligning the magnitude bits of the numbers based on the maximum exponent is performed by an alignment unit <NUM>. The alignment unit <NUM> thus generates an aligned number which is an integer pi.

The method further comprises, at step <NUM>, processing the set of 'k' aligned numbers pi concurrently to generate an output value q. The processing of the integers pi includes performing addition and/or subtraction of the k numbers. It is noted that addition of a negative number to a positive number is equivalent to performing a subtraction, and so the term processing is used herein to cover the acts of both addition and subtraction, alone or in combination. The processing of the k numbers is performed concurrently. That is the processing unit performs a process on all the integers in the set at the same time rather than, for example, processing elements of the set sequentially or processing the elements of the set in pairs. The processing unit <NUM> performs addition and/or subtraction of the k integers to generate an output value.

Further, at step <NUM>, the method includes renormalizing and rounding the output value q to represent the output value as a floating-point number in a first format or any other format with a normalized mantissa nk and an exponent ek. The method includes renormalizing the output value to represent the output value q as a standard normalized number. Further, the method performs rounding the normalized number nk to represent the number with a mantissa having a particular bit-length. In an example, the normalized number is rounded to a bit length of 'b' bits, in order to represent the number in the first format, as the received input, having a mantissa of bit length 'b'. In other examples, the output values are represented in a different floating-point number format compared to the inputs received. The normalizing is performed by initially counting the number of recurring '<NUM>' bits or '<NUM>' bits on the MSB side. The recurring '<NUM>' bits are counted when the output value 'q' is a non-negative (i.e. positive) number. The recurring '<NUM>' bits are counted when the output value 'q' is a negative number. Further, the normalizing is performed by shifting the bits of the output value q to the LSB side around the radix point to represent the signed number as a standard normalized number. Further, the method calculates an exponent value based on the maximum exponent and the counted number of recurring bits. The exponent value thus calculated is represented with a bit-length of 'a bits as explained above with reference to <FIG>. Thus, the output 'q' is normalized to be represented as a floating-point number in the first format.

<FIG> is a flowchart illustrating a method of aligning the number (yi) based on the maximum exponent.

The method includes, at a first step <NUM>, calculating, for each floating-point number in the set of 'k' floating point numbers, the difference (ed) between the maximum exponent (emax) and exponent (ei). The difference ed is calculated for each input floating point number by a subtractor unit in the alignment unit <NUM> The alignment unit <NUM> comprises a plurality of subtractor units for calculating the difference ed.

The method includes at step <NUM> shifting the magnitude bits of the corresponding number, to the LSB side, based on the calculated difference of the corresponding floating point number. Aligning the magnitude bits by shifting position of the bits causes an underflow of the original `b bits' from the mantissa of the number in the first format if the calculated difference ed is greater than the number of extra LSBs added while converting the mantissa mi in the first format to the number.

Further to shifting the magnitude bits of the number, the method at step <NUM> comprises truncating the bits of the numbers that are shifted outside the bit-length of the number. That is all the bits of the number that are shifted outside the bit-length 'n' are truncated. The method only truncates bits of the number corresponding to bits of the mantissa of the original first format number when the calculated difference is greater than the number of extra LSBs added. Any fair rounding scheme can be used for truncating the bits of the number. The error caused by the truncation of bits while processing the floating point numbers is insignificant as the mantissa (mi) is already extended by adding number of extra LSBs to mitigate the effect of underflow while performing the steps of shifting or truncating the bits of the number.

The method at (an optional step <NUM>) further comprises determining two's complement of the numbers, based on a sign bit (si) of each corresponding number. This step is optional if the received set of 'k' floating point numbers in a first format as signed numbers. A signed number is complemented when the sign bit (si) of the number indicates a negative number. The positive numbers are left unchanged and the all the numbers are then processed concurrently. Processing the 'k' numbers in an example includes calculating a sum value by performing an 'n' bit carry save addition. The sum value is further normalized and rounded to represent the output in a floating-point number format.

<FIG> is a graph illustrating a comparison of the implementation of the architecture <NUM> with other standard architectures for processing a set of floating-point numbers. In the <FIG> a graphical representation of results of a first experiment comparing the implementation of the architecture <NUM> explained in <FIG> with other standard architectures is shown. The first experiment includes comparing area versus delay trade-offs of the different architectures. As shown in <FIG>, in the first experiment, three architectures (arch <NUM>, arch <NUM> and arch <NUM>) are used for comparison. The arch <NUM> is an architecture of a balanced tree of floating-point adder implementation (with pairwise round to nearest and tie to even implementation). The results obtained for arch <NUM> are represented by cross (+) symbols on a first curve in <FIG>. The arch <NUM> is another architecture of a balanced tree of floating-point adder implementation (with pairwise fair rounding implementation). The results obtained for arch <NUM> are represented by circle (o) symbols on a second curve shown in <FIG>. The arch <NUM> is the implementation of the architecture <NUM> disclosed in this document (with fair rounding implementation). The results obtained for arch <NUM> are represented by square symbols on a third curve in <FIG>. In the first experiment, the three architectures are implemented in software using VHDL.

In the first experiment, a set of floating-point numbers in a first format of single precision (<NUM>-bit) floating point number was used as input. Each floating-point number comprised a mantissa mi having bitlength of <NUM> bits (b=<NUM> bits), exponent 'ei' having a bitlength <NUM> bits (a=<NUM> bits) and a sign bit. The first experiment included synthesising the three architectures for various timing targets so as to observe area versus delay trade-offs. From the graph in <FIG> it is observed that the arch <NUM> (architecture <NUM>) has the least delay and least area. In particular, the fastest circuit synthesized from architecture <NUM> uses less than <NUM>% the area and has less than <NUM>% the delay of the fastest circuits synthesized from the other architectures under consideration.

Further, the complexity of the hardware implementation of the different architectures are compared. The complexity of the hardware implementation such as the critical path is expressed using the Big O Notation. For the architecture <NUM>, the maximum exponent detection unit <NUM> is implemented with O(log(k) log(a)) gates on the critical path. Further, the alignment unit <NUM> is implemented with O(log(b)) gates on the critical path. The processing unit (<NUM>) i.e. the adder <NUM> is implemented with O(log(k) + log(b)) gates on the critical path. The normalizing unit <NUM> is implemented with O(log(a)) gates on the critical path. Thus, the total hardware implementation could be implemented with O(log(k) log(a) + log(b)) logic gates on its critical path. For increasing array size k and mantissa width b, the critical path is asymptotically shorter than architectures of a balanced tree of floating-point adders.

For the same input of the set of k floating point numbers in the first format, a straightforward implementation of a multiple-input adder consisting of a binary tree of floating-point adders (with a fixed rounding mode, for instance rounding towards zero) is explained below. By construction, the implementation produces a pairwise fairly rounded sum. The critical path in a balanced tree of floating-point adders goes through O(log(k)) adders, each adder featuring O(log(ab)) gates on its critical path. In total, architectures of a balanced tree of floating-point adders thus have O(log(k) log(ab)) logic gates on their critical path.

Further, the implementation of the architecture <NUM> generates output having a precision not worse than the worst case of the pairwise addition performed while using the architecture of binary tree adders or accumulator adder with fair rounding. A mathematical proof for the precision of the architecture <NUM> is provided later. It is shown that the accuracy of the result is not lower than the worst-case pairwise floating-point addition with a fair rounding scheme. This means that for any given input array, performing pairwise addition by iteratively replacing two terms in the array by their sum rounded to the nearest larger or smaller representable value can always yield a result less precise or equal to the result generated by addition using the architecture <NUM> disclosed. An imprecise choice of ordering the inputs and for performing the step of rounding, in known architectures, is to add numbers in increasing magnitude to the largest one and always round in the same direction. The precision of output obtained by the architecture <NUM> is not less precise than that the result obtained by making these choices.

The delay and area performance of the architecture <NUM> dramatically improves compared to a tree of floating-point adders by removing intermediate normalisation steps and replacing intermediate carry propagation steps with a single carry-save addition as shown in <FIG>. The empirical precision of the architecture <NUM> as described above is shown to significantly outperform trees of floating-point adders as measured on Gaussian distributed inputs centred around zero.

Finally, the architecture <NUM> for addition is commutative. Any order of inputs yields the same output. This leads to better reproducibility of result, as the order in which floating point numbers in a set are bound to the inputs to the architecture <NUM> does not influence the result.

A mathematical proof for the precision of the architecture <NUM> is provided below. In the section below it is demonstrated that the precision of our algorithm is not less than the worst-case iterated pairwise addition with fair rounding.

Firstly, some basic property of fair rounding schemes are defined and proved. Let F<NUM>, F<NUM> ⊆ R u { ± ∞} be two number formats and r ∈ R ∪ { ± ∞} be a number. We say that q is a fair rounding of r in format F, written q ≈F r, when q is the least upper bound or the greatest lower bound of r in F.

We say that F1 is finer than F2 in the neighbourhood of r when the least upper bound and greatest lower bound of r in F2 belong to F1. The following proposition follows straightforwardly. Proposition <NUM>: If F1 is finer than F2 in the neighbourhood of r then for all values q1, q2 such that q<NUM> ≈F<NUM> r and q<NUM> ≈F<NUM> q<NUM> we have q<NUM> ≈F<NUM> r.

Now let F be a floating-point format with 'a' exponent bits, 'b' mantissa bits and an exponent bias `c' used at the input and output of our computation. Further, a set of 'k' floating point numbers in format F as input. The algorithm proceeds by conversion to a fixed-point format G aligned on the largest exponent emax in the array.

Let l be an index such that el = emax is the maximum exponent. Numbers in format G are given as a signed integer p over <MAT> bits, taking its value in the range <MAT> and representing the real number <MAT>. Each input floating point number xi is converted to a fixed point value <MAT>, where the choice of rounding is left to the implementation.

The fixed point values are then added together and their sum converted back to the original format hence producing the result <MAT>, where the choice of rounding is again left to the implementation.

For the purpose of this analysis numbers in the input array are classified in two categories: small numbers, whose exponent is less than <MAT>, and large numbers, whose exponent is between <MAT> and el. The input array is partitioned into an array of small numbers <MAT> and an array of large numbers <MAT>. The count k' of small numbers verifies <NUM> ≤ k' ≤ k - <NUM>. For all i = <NUM>,. , k - <NUM>, <MAT> and <MAT> denotes the significand and exponent of <MAT> respectively, and <MAT> the conversion of <MAT> to the fixed-point format G, such that <MAT>. Remark that while small numbers may incur a rounding error, large numbers are represented exactly.

A sequence wi is constructed by letting <MAT>, wi = wi-<NUM> + <MAT> for i = <NUM>,. , k - <NUM>, and wk-<NUM> = y. Recall that <MAT>, hence <MAT>. Two lemmas regarding the magnitude of intermediate sums is proved in this decomposition. First, it is demonstrated that no underflow can happen in format G when adding small numbers to the one with largest exponent.

A similar reasoning applies for denormal values of xl. In that case all intermediate sums are representable in G, so that only the final rounding incurs a loss of precision. As previously this final rounding preserves the ordering. Infinite or NaN input values of xl result in an infinite or NaN output value, which does not involve rounding.

<FIG> shows a computer system in which the graphics processing systems described herein may be implemented. The computer system comprises a CPU <NUM>, a GPU <NUM>, a memory <NUM> and other devices <NUM>, such as a display <NUM>, speakers <NUM> and a camera <NUM>. A processing block <NUM> (corresponding to processing blocks <NUM>) is implemented on the GPU <NUM>. In other examples, the processing block <NUM> may be implemented on the CPU <NUM>. The components of the computer system can communicate with each other via a communications bus <NUM>. A store <NUM> (corresponding to store <NUM>) is implemented as part of the memory <NUM>.

While <FIG> illustrates the implementation of a graphics processing system, it will be understood that a similar block diagram could be drawn for an artificial intelligence accelerator system - for example, by replacing the GPU <NUM> with a Neural Network Accelerator (NNA), or adding the NNA as an additional unit. In such cases, the architecture <NUM> of the adder can be implemented in the NNA.

The adder described herein may be embodied in hardware on an integrated circuit. Generally, any of the functions, methods, techniques, or components described above can be implemented in software, firmware, hardware (e.g., fixed logic circuitry), or any combination thereof. The terms "module," "functionality," "component", "element", "unit", "block" and "logic" may be used herein to generally represent software, firmware, hardware, or any combination thereof. In the case of a software implementation, the module, functionality, component, element, unit, block, or logic represents program code that performs the specified tasks when executed on a processor. The algorithms and methods described herein could be performed by one or more processors executing code that causes the processor(s) to perform the algorithms/methods. Examples of a computer-readable storage medium include a random-access memory (RAM), read-only memory (ROM), an optical disc, flash memory, hard disk memory, and other memory devices that may use magnetic, optical, and other techniques to store instructions or other data and that can be accessed by a machine.

The terms computer program code and computer readable instructions as used herein refer to any kind of executable code for processors, including code expressed in a machine language, an interpreted language, or a scripting language.

A processor may be any kind of general purpose or dedicated processor, such as a CPU, GPU, NNA, System-on-chip, state machine, media processor, an application-specific integrated circuit (ASIC), a programmable logic array, a field-programmable gate array (FPGA), or the like.

It is also intended to encompass software which defines a configuration of hardware as described herein, such as HDL (hardware description language) software, as is used for designing integrated circuits, or for configuring programmable chips, to carry out desired functions. That is, there may be provided a computer readable storage medium having encoded thereon computer readable program code in the form of an integrated circuit definition dataset (which may also be referred to as a hardware design) that when processed (i.e. run) in an integrated circuit manufacturing system configures the system to manufacture a computing device comprising any apparatus described herein. An integrated circuit definition dataset may be, for example, an integrated circuit description.

Therefore, there may be provided a method of manufacturing, at an integrated circuit manufacturing system, an architecture of adder as described herein. Furthermore, there may be provided an integrated circuit definition dataset that, when processed in an integrated circuit manufacturing system, causes the method of manufacturing an adder to be performed.

An example of processing an integrated circuit definition dataset (e.g. a hardware design) at an integrated circuit manufacturing system so as to configure the system to manufacture an adder will now be described with respect to <FIG>.

<FIG> shows an example of an integrated circuit (IC) manufacturing system <NUM> which is configured to manufacture an adder as described in any of the examples herein. In particular, the IC manufacturing system <NUM> comprises a layout processing system <NUM> and an integrated circuit generation system <NUM>. The IC manufacturing system <NUM> is configured to receive an IC definition dataset/ hardware design (e.g. defining an adder as described in any of the examples herein), process the IC definition dataset, and generate an IC according to the IC definition dataset (e.g. which embodies an adder as described in any of the examples herein). The processing of the IC definition dataset configures the IC manufacturing system <NUM> to manufacture an integrated circuit embodying an adder as described in any of the examples herein.

The layout processing system <NUM> is configured to receive and process the IC definition dataset/ hardware design to determine a circuit layout.

In other examples, processing of the integrated circuit definition dataset at an integrated circuit manufacturing system may configure the system to manufacture an adder without the IC definition dataset being processed so as to determine a circuit layout. For instance, an integrated circuit definition dataset may define the configuration of a reconfigurable processor, such as an FPGA, and the processing of that dataset may configure an IC manufacturing system to generate a reconfigurable processor having that defined configuration (e.g. by loading configuration data to the FPGA).

In some embodiments, an integrated circuit manufacturing definition dataset/ hardware design, when processed in an integrated circuit manufacturing system, may cause an integrated circuit manufacturing system to generate a device as described herein.

In the example shown in <FIG>, the IC generation system may further be configured by an integrated circuit definition dataset/ hardware design to, on manufacturing an integrated circuit, load firmware onto that integrated circuit in accordance with program code defined at the integrated circuit definition dataset or otherwise provide program code with the integrated circuit for use with the integrated circuit.

Claim 1:
A method of processing a set of 'k' floating point numbers to perform addition and/or subtraction, k ≥ <NUM>, using a hardware implementation, each floating-point number comprising a mantissa (mi) and an exponent (ei), wherein the method comprises:
receiving the set of 'k' floating point numbers in a first format (<NUM>), each floating-point number in the first format comprising a mantissa (mi) with a bit-length of 'b' bits;
creating a set of 'k' numbers (yi) based on the mantissas of the 'k' floating-point numbers (<NUM>), the numbers having a bit-length of 'n' bits obtained by adding both extra most-significant bits and extra least-significant bits to the bit length `b' of the mantissa (mi), wherein the 'n' bits comprises a number of magnitude bits, wherein 'n' is <MAT> bits, where x is an integer, and x ≥ <NUM> and x ≤ <NUM>;
identifying a maximum exponent (emax) among the exponents (ei) (<NUM>);
aligning the magnitude bits of the numbers (yi) based on the maximum exponent (emax) (<NUM>); and
processing the set of 'k' numbers concurrently (<NUM>).