Different synthesis results for an adder

[igor_kh]

Good day,

My question is more of curiosity nature, please advise on the following if you have an interest.

I am playing with different HDL descriptions of ripple-carry adder up to the level of elaborated design ans synthesis. I follow structural modelling at the gate level with Verilog to describe full adder and then the full adder is used as a building block for the ripple-carry adder modelling.

I model full adder in two ways:

1. With two-level logic in some of products (type 1).

2. And using XOR, AND and OR functions (type 2).

Both models of full adder elaborate to the netlists of generic gates accordingly to descriptions differing only in the types of gates.

Synthesis processes for both models produces equivalent schematic shown below

and it is clear for me - both models describe the same function and the implementation of combinational logic is deployed on LUTs.

On the next step, I am modelling two 32-bit ripple-carry adders in a structural way with previously described full adder models as the building blocks. As result of synthesys, I expected to see equivalent netlists for both RCAs since each of the full adder models resulted in an equivalent netlist. But actually, the resulted netlists are different and occupies different resources.

RCA built with full adder (type 1) requires 146 cells and 211 nets.

RCA built with full adder (type 2) requires 177 cells and 242 nets.

Can you please give me a hint, what why it happens in this way. I would expect an equivalent netlist for both, and if I can set up the tool produce equivalent netlist.

Thank you for your help!

[drjohnsmith]

which tools are you using ?

A thing that trips up many when thy are starting out, is the tools do not optimise the circuit,

The tools make the circuit that meets your timing constraints and your logic, and then STOP.

If you have two designs, the tools will work from two different start points. For a very small design, the difference is still liable to give the same result, but as designs give the tools more freedom by being bigger, the results could well be different.

As far as the tools are concerned, they have meet your timing constraints , so stopped.

Its a good exercise to do what your doing, as you are learning design styles that make efficient designs,

If you had tighter timing constraints, then the design produced might well be different.

[igor_kh]

Thank you for your clarification, the situation is less confusing for me now. 

I am using Vivado 2019.1

And one more thing that did not mention in original post. The design is relaxed in terms of user specified timing constraints. I simply did not specify them.

[avrumw]

More importantly - neither of these is the way to implement a wide adder - the proper way is to use the '+' operator.

When using the addition operator, the tools will implement the adder "the right way", which is using the built-in fast carry lookahead logic built into the CLBs. This will be significantly faster and smaller than any adder implemented as pure LUT based logic - a 32 bit adder should be implemented in something like 64 LUT5s, which can be mapped into 32 LUT6, taking only 8 CLBs (or something like that) and the dedicated fast carry cells. It appears that the tools are not able to take a low level description of a RCA and realize it is an addition operation and implement it in the fast carry lookahead cells...

I understand if you are playing with the RCA implementations just to see what the tool will do with them, but in a "real" design, you should always use the + operator.

Avrum

[igor_kh · Accepted solution]

@drjohnsmith, @avrumw 

Thank you for all your comments and clarifications, they led me to finish my exercise with all goals set up as achieved. I gained deeper understanding of the distinct features of the design flow with FPGA , and I also got quite detailed knowledge of the CLB architecture and the primitives.