# VHDL: difference between using "+" or writing our own adder

I would like to know what would be the difference between between using "+" or writing an adder for adding two numbers:

library ieee;
using ieee.std_logic_1164.all

component f_a  -- suppose we have a full adder
port ....
end component;

FA: for i in 0 to n generate     -- suppose we just carry chain the full adders
FA_i: f_a PORT MAP ...
end generate;
end;


VS

library ieee;
using ieee.std_logic_1164.all
using ieee.numeric_std.all

out <= A + B;
end;


What would be the difference? What would happen during synthesis? What would be the consequences on a FPGA?

Thank you.

Both have their uses: The second gives potentially better hardware in a real-life scenario, the first can be given to students as coursework for a course named "history of hardware" or something equivalent.

For the second example, the synthesis tool will implement an addition in whichever way works best for the set boundary conditions. This might be a full adder, this might be an XOR-gate, it might be a DSP block, or anything in between.

If you have to ask, you won't beat the synthesis tool, so write the second.

• The second example also has far better code readability for whoever has to maintain your project in the future Oct 2, 2019 at 9:29
• @scary_jeff Readability is in the eye of the beholder: someone that's used to instantiating full adders (as many hardware designers still are, sadly) won't pause for the first example, but will have some 23 year old doubt about the whether the second can be synthesized, despite it not being a problem for over 2 decades. Oct 2, 2019 at 9:32
• So it is always better to write the simplest code and let the synthesis tool do its work? For example, even for a simple multiplexer, it is better to write a with/select instead of writing booleans equations? Oct 2, 2019 at 9:50
• @Wheatley It's better not to think about a multiplexer, just write the logic of the algorithm and let synthesis decide what should be a multiplexer, your decision would be suboptimal in roughly 30% of the cases anyway, and you'd never know. Combinatorial stuff like with/select is inferior to a clearly written one or two process style that will infer everything. Oct 2, 2019 at 10:10
• @Wheatley To me, the bottom line is that you tell the synthesis tools your intent...how you want the system to behave. Then let the synthesis tool figure out the best way to accomplish that. Oct 2, 2019 at 14:42

In the end: nothing.

Synthesis tools are so good that they will optimize your code to what ever fits best.

"Best" then depends on of you have set e.g. optimise for area or speed. In most cases they will try to use the least amount of logic which still meets your timing specification.

In real designs you really, really do not want to instance primitives. Your development time will become exponential slower and more difficult.

So it is always better to write the simplest code and let the synthesis tool do its work?

It comes down to: do you think you can do a better job then the synthesis tool?

This might be the case for some special exotic piece of code.

But all standard code like multipliers, adders, muxes etc. have been subject of extensive academic studies. The synthesis community keeps track of those and incorporates the best results in their tools. Beating those will be very, very difficult and you probably spend your time better elsewhere.

• So it is always better to write the simplest code and let the synthesis tool do its work? For example, even for a simple multiplexer, it is better to write a with/select instead of writing booleans equations? Oct 2, 2019 at 9:46
• Ok I understand. I don't know how a synthesis tool really works, but I can rely on it. Oct 2, 2019 at 10:33
• I think your answer is a bit simplistic. Yes, synthesis tools are very good but the hierarchy of modules is different in these two cases. Sometimes optimization across module boundaries does not work well or is not done at all. Depending on how the OP implements the adder, the synthesis tools may or may not recognize it as an addition operator. For architectures that have specific hardware support for addition this will make a huge difference. Oct 2, 2019 at 14:41