Multipliers, dividers, adders etc....

[asparnique]

Hi,

Generally as nwbie with verilog, after sifting through a few relevant sites
I couldn't help noticing requests/aid/help on various implementations of
multipliers, dividers, look-ahead-carry adders .. and generally such things
that are widely used & necessary. However verilog does provide *, /, +, -
etc. as operators that will presumably be synthesizable into real hardware.
I presume different synthesis tools have different ways of generating and or
optimizing the hardware representing these common operations, so why should
there be a need to specifically use customized verilog code to implement
multipliers, dividers etc. ?? Is this an issue of IP ownership ? i.e. who
may/may not end up being the real owner of the generated hardware ?? Or do
people just prefer customising such operations for their specific
applications ? Can't see the real point of "re-inventing the wheel" if it's
there ...

M

 

[Jonathan Bromley]

On Wed, 30 Dec 2009 19:33:34 +0100, "asparnique" wrote:

Generally as nwbie with verilog, after sifting through a few relevant sites
I couldn't help noticing requests/aid/help on various implementations of
multipliers, dividers, look-ahead-carry adders .. and generally such things
that are widely used & necessary. However verilog does provide *, /, +, -
etc. as operators that will presumably be synthesizable into real hardware.
I presume different synthesis tools have different ways of generating and or
optimizing the hardware representing these common operations, so why should
there be a need to specifically use customized verilog code to implement
multipliers, dividers etc. ??

If you read answers to such posts here on comp.lang.verilog you will
generally see exactly the answer you would expect: At first, leave it
to the synthesis tool. It will usually do a good job. Only in very
extreme cases, where you have some wild or special requirement, it is
possible that the synthesis tool will miss an opportunity and you may
need to re-invent some wheels on its behalf. Even if synthesis
results are sub-optimal, if they are "good enough" (i.e. they meet
your area and timing requirements) then there is no need to improve
them manually.

The big exceptions to this are floating-point arithmetic, and
dividers. Bear in mind that synthesis must implement the operators
as logic that works in a single clock cycle. Both for FP and for /
there is no sensible combinatorial implementation; any realistic
hardware would perform the operation over multiple cycles, and
you must describe that operation explicitly to synthesis.

As has been pointed out on many occasions, synth tools are often
quite smart about pipelining operations when they get the chance.
For example:

reg [N-1:0] MultInA, MultInB;
reg [2*N-1:0] Quotient;

always @(posedge clock) begin
MultInA <= A;
MultInB <= B; // Register the multiplier's inputs
Quotient <= MultInA * MultInB; // Register its output
end

A synthesis tool can see that the result appears on Quotient
two clock cycles after it is presented on inputs A,B. It may
then choose to push the MultIn registers into the multiplier,
making it pipelined. The value on the primary output Quotient
remains correct after this is done; the values in MultIn...
are, however, very different from what you would see in simulation.
This is OK provided you don't use those input registers anywhere
else in the design.

This technique of "pushing logic through registers" is a neat
way of allowing synth tools the freedom to create pipelined
hardware.

Is this an issue of IP ownership ? i.e. who
may/may not end up being the real owner of the generated hardware ??

Not as far as I'm aware.

Or do people just prefer customising such operations for their
specific applications ? Can't see the real point of "re-inventing
the wheel" if it's there ...

Masochism is out there....
--
Jonathan Bromley

 

[asparnique]

Hi,

Thanks for confirming what I was thinking. Generally I notice such verilog
code for *, /, + etc. is used a point of explaining the use of the language
and implementation with simulation in mind, and generally in text books. I
came across this in quite a few text books on verilog, and having a
background in C/C++ this was never an issue for obvious reasons. However it
is clearly possible to use either the synthesised *, / or +, - for the
specific device Altera, Xilinx etc. or code your own verilog as you wish.
The later is generally not what I was after, as I wish to spend my energy &
time on the implementation of the actual application and the algorithms etc,
and leave the rest to the simulation and synthesisers to implement etc.
With regards to floating point, well if one can get away with integers, that
is perfectly fine with me. However division is also an operator in the same
context as *, so would it be so much different for the synthesisers to
produce an optimised (for speed or gate count) divide operation ?? Just
wondering ...

Regards, M

"Jonathan Bromley" wrote in message
news:fsjnj5l5shl0ulu28r5dmpidjmnp4luo9r@4ax.com...

On Wed, 30 Dec 2009 19:33:34 +0100, "asparnique" wrote:

Generally as nwbie with verilog, after sifting through a few relevant
sites
I couldn't help noticing requests/aid/help on various implementations of
multipliers, dividers, look-ahead-carry adders .. and generally such
things
that are widely used & necessary. However verilog does provide *, /, +, -
etc. as operators that will presumably be synthesizable into real
hardware.
I presume different synthesis tools have different ways of generating and
or
optimizing the hardware representing these common operations, so why
should
there be a need to specifically use customized verilog code to implement
multipliers, dividers etc. ??

If you read answers to such posts here on comp.lang.verilog you will
generally see exactly the answer you would expect: At first, leave it
to the synthesis tool. It will usually do a good job. Only in very
extreme cases, where you have some wild or special requirement, it is
possible that the synthesis tool will miss an opportunity and you may
need to re-invent some wheels on its behalf. Even if synthesis
results are sub-optimal, if they are "good enough" (i.e. they meet
your area and timing requirements) then there is no need to improve
them manually.

The big exceptions to this are floating-point arithmetic, and
dividers. Bear in mind that synthesis must implement the operators
as logic that works in a single clock cycle. Both for FP and for /
there is no sensible combinatorial implementation; any realistic
hardware would perform the operation over multiple cycles, and
you must describe that operation explicitly to synthesis.

As has been pointed out on many occasions, synth tools are often
quite smart about pipelining operations when they get the chance.
For example:

reg [N-1:0] MultInA, MultInB;
reg [2*N-1:0] Quotient;

always @(posedge clock) begin
MultInA <= A;
MultInB <= B; // Register the multiplier's inputs
Quotient <= MultInA * MultInB; // Register its output
end

A synthesis tool can see that the result appears on Quotient
two clock cycles after it is presented on inputs A,B. It may
then choose to push the MultIn registers into the multiplier,
making it pipelined. The value on the primary output Quotient
remains correct after this is done; the values in MultIn...
are, however, very different from what you would see in simulation.
This is OK provided you don't use those input registers anywhere
else in the design.

This technique of "pushing logic through registers" is a neat
way of allowing synth tools the freedom to create pipelined
hardware.

Is this an issue of IP ownership ? i.e. who
may/may not end up being the real owner of the generated hardware ??

Not as far as I'm aware.

Or do people just prefer customising such operations for their
specific applications ? Can't see the real point of "re-inventing
the wheel" if it's there ...

Masochism is out there....
--
Jonathan Bromley

 

[Jonathan Bromley]

On Thu, 31 Dec 2009 14:04:46 +0100, "asparnique" wrote:

is clearly possible to use either the synthesised *, / or +, - for the
specific device Altera, Xilinx etc. or code your own verilog as you wish.
The later is generally not what I was after, as I wish to spend my energy &
time on the implementation of the actual application and the algorithms etc,
and leave the rest to the simulation and synthesisers to implement etc.

Agreed 100%. Don't keep a dog and bark yourself.

With regards to floating point, well if one can get away with integers, that
is perfectly fine with me. However division is also an operator in the same
context as *, so would it be so much different for the synthesisers to
produce an optimised (for speed or gate count) divide operation ?? Just
wondering ...

Well..... Others may correct me here, but I think this is
roughly right.... It is comparatively easy to parallelize
many of the various operations required for a multiplication,
but division is inherently sequential and therefore the hardware
required to perform a combinational divide operation is likely to
have very long combinational delay paths in it. Consequently,
divide blocks are almost always designed to work over a number
of clock cycles, and therefore can't be represented by the /
operator in standard RTL synthesis. On the other hand,
fully combinational multipliers are possible and well-known
(albeit quite large and complicated), so a synthesisable *
operator makes good sense. This is, of course, especially
true in the many modern FPGAs that have dedicated fast
multiplier blocks on-chip.

It may be that there are synthesis tools that can infer
combinational hardware from the / operator, but I'm not
aware of any myself.

Of course, divide by a constant power of 2 is a simple
right shift and can be synthesised by most tools.
--
Jonathan Bromley