At my school we have Synopsis "design_vision" in the computer labs. I don't know how to use any of the features so to me it's just a schematic-drawing tool.
Out of curiosity, I hand-coded in Verilog an 8-bit carry-lookahead adder, and then asked design_vision to compile it. The result looks a lot like a ripple-carry adder.
Now, the ripple-carry adder uses fewer gates, but it is so much deeper. Why does design_vision prefer the ripple-carry?
What technology were you targetting?
If it was an FPGA, the synthesizer may have been so clever that it knew that ripple carry is more efficient (in terms of LUT count, and probably performance also) as the carry chain is there for free.
If the ripple-carry adder is fewer gates and satisfies timing constraints, why should the synthesizer not prefer it? In many cases, the most efficient way to generate a carry chain is to use a mixture of ripple-carry and lookahead units. For example, if one is implementing a 32-bit adder with a 16-gate-delay timing budget, rendering it as two eleven-bit sections and a ten-bit section may require fewer gates than the fastest possible arrangement while still meeting the timing requirements.
I'd suggest figuring out how to play with timing constraints; I would guess you'd find that independent of whether you design in a ripple-carry or carry-lookahead adder, the mix of ripple- and lookahead-carry generated by the compiler would vary with the constraints specified. If you wish to maintain a particular arrangement of carry logic, you can explicitly tell the compiler that you want certain signals generated (since this is a fictional design anyway, routing them to I/O pins might be a good way to do that). I suppose a compiler might still decide to ignore the P and G signals even if it was forced to generate them, but hopefully it would be smart enough not to do that.
