Talk:Carry-lookahead adder

The layout of this article is backwards

Someone looking to learn carry look-ahead adders is going to first want a review on how binary addition works, the difference between generation and propagation, then how a ripple-carry adder handles the propagation of carries. Then the reader would be able to better understand the introduction to the theory of operation, the method behind looking ahead, and then finally an in-depth explanation to the implementation of the method, and the grouping of look-ahead units.

The entire article is backwards to how a reader wants to learn about this. The fact that a large Verilog paste comes before any explanation to the basic principle behind looking ahead - and even before just a review of ripple-carry adders - is clear evidence to this.

I've restructured the article in my recent edit to reflect a natural progression. If we're going to keep the old structure at least justify it first.

- Alex

2600:1700:FCE0:A890:350E:238E:31CE:8D1D (talk) 01:09, 11 July 2023 (UTC)

More editing needed

The section with all the logic formulae has been copied verbatim from a textbook without proper thought being given to it. For example, the logic diagram refers to "the previous diagram" when there isn't one. The constant tone of "this is really complicated, children, so don't worry about it" doesn't belong in an enyclopaedia entry, especially since CLA is really rather simple.

I've deleted the whole section on CLA requiring O(n^2) logic gates or O(n^3) transistors because it's quite simply wrong.

JoeBruno (talk) 09:28, 7 April 2008 (UTC)

Real life

No one uses this basic form of CLA in real life. I've started a page on kogge-stone, though. Perhaps we should just do one on prefix adders in general. There is a school with some very good slides on prefix adders. PSU copied their kogge-stone diagram for a homework assignment. The homework assignment is one of the top hits for kogge-stone if anyone is interested in looking. —The preceding unsigned comment was added by 141.213.66.199 (talk • contribs) 20:57, 19 September 2006 (UTC)

I placed links to the Kogge-Stone and Brent-Kung architectures in the introduction. However, this article is still useful for its generic information. Bakkster Man (talk) 19:42, 4 May 2010 (UTC)

Bad examples

The examples given have errors, please double check, i.e. does not make sense!

Let's try a little experiment. Here is a series of numbers. See how long it takes you to find the most significant digit (the number to the far left).

 345678987 + 6543210123456

The most significant digit is 9. How can we tell? We can look at the far left digits being added. 3 + 6 = 9. If we were to add 1 to this value, the most significant digit would be 1 (9 + 1 = 10). So, we have to look at the digit to the right of this one, to see if there is a carry. Do the same for the following problem: —The preceding unsigned comment was added by 66.129.224.36 (talk • contribs) 18:32, 28 September 2006 (UTC)

I'm not sure I follow this. You're adding a 9 digit number to a 13 digit number, so you can't simply look at the left-most digits. 345,678,987 + 6,543,210,123,456 = 6,543,555,802,443. The most significant digit thus remains as 6. I can't even see an example like this in the article. I suggest this entire talk section is inaccurate and irrelevant. Mesdale (talk) 15:52, 16 March 2012 (UTC)

Thanks for the description of method - it was really easy to understand after that!

Matty2002 (talk) 11:31, 21 November 2007 (UTC)

"or" or "xor" to calculate P

Article says:

For binary arithmetic, or is faster than xor and takes less transistors to implement, and therefore $P(A,B)$ is usually used instead of $P^{\prime }(A,B)$.

Surely as the full adder calculates A xor B as part of its process, it's more efficient to use that partial result (which is then xored with the resulting carry to give the output of the adder) than add an extra or gate? 87.75.164.162 21:00, 19 October 2006 (UTC)

Efficient, yes. But not as fast, which is the main deal. —Preceding unsigned comment added by 141.213.52.83 (talk • contribs)

Why not as fast? The xor must be calculated anyway before the output can stabilise, so surely there's no additional delay from using its results for the propogate signal? Or does the propogate signal need to be produced faster than the output signal? JulesH 09:29, 10 March 2007 (UTC)

Verilog implementation

I've got an implementation of a 4-bit CLA adder in verilog. Does anyone think it would be a useful addition to the article? 87.75.164.162 21:53, 19 October 2006 (UTC)

       // pgadder is a full adder that generates propogate & generate outputs
       // rather than a carry bit
       module pgadder (a, b, c, o, p, g);

       input a, b, c;
       output o, p, g;

       assign g = a & b;       // generate a carry bit if a & b are both 1
       assign p = a ^ b;       // propogate a carry bit if either a or b is 1

       assign o = p ^ c;       // output is a^b^c.
 
       endmodule

       // main module
       module cla_adder_4 (a, b, c_in, out, c_out);

       input [3:0] a, b;       // input to sum
       input c_in;             // carry in
       output [3:0] out;       // output
       output c_out;           // carry out

       wire [3:0] out;         // used to connect adder output to our output
       wire c_out;             //            "                 "

       wire [3:0] c;           // carry bits from look-ahead to adders
       wire [3:0] p;           // propogate bits from adders to look-ahead
       wire [3:0] g;           // generate bits from adders to look-ahead

       // adders
       pgadder pga0 (a[0], b[0], c[0], out[0], p[0], g[0]);
       pgadder pga1 (a[1], b[1], c[1], out[1], p[1], g[1]);
       pgadder pga2 (a[2], b[2], c[2], out[2], p[2], g[2]);
       pgadder pga3 (a[3], b[3], c[3], out[3], p[3], g[3]);

       // carry prediction
       assign c[0] = c_in;
       assign c[1] = g[0] | p[0]&c_in;
       assign c[2] = g[1] | p[1]&g[0] | p[1]&p[0]&c_in;
       assign c[3] = g[2] | p[2]&g[1] | p[2]&p[1]&g[0] | p[2]&p[1]&p[0]&c_in;
       assign c_out = g[3] | p[3]&g[2] | p[3]&p[2]&g[1] | p[3]&p[2]&p[1]&g[0] 
                           | p[3]&p[2]&p[1]&p[0]&c_in;

       endmodule

Long Introduction

I have shortened the introduction. If nobody objects or does it first, I will remove the tag for a long introduction in one week. Bakkster Man (talk) 19:33, 4 May 2010 (UTC)

Been a little more than a week, removed it. 140.211.137.82 (talk) 17:26, 25 October 2010 (UTC)

Oops, forgot about this... ;) Thanks! Bakkster Man (talk) 17:38, 25 October 2010 (UTC)

Left/right reversed in Implementation details section?

The Implementation details section currently says:

Note that the numeric value determines the signal from the circuit above, starting from 0 on the far left to 3 on the far right:

I assume that the "circuit above" is the image at the top of the page. In that image, 0 is on the right and 3 is on the left.

Am I missing something or do people agree that the current text is backwards?

Asteriskman (talk) 21:30, 16 January 2015 (UTC)

Carry lookahead method uses + for both addition and logical or, which might be quite confusing

Not sure how best to resolve this, though the way it is written currently was a little confusing to me at first. Marvk (talk) 20:56, 25 January 2024 (UTC)