verilog adders (verilog optimization)

On Aug 29, 6:29*pm, Mike Treseler <mtrese...@gmail.com> wrote:
> jprovide...@yahoo.com wrote:
> > I'm curious as to
> > a) does Verilog some how require this?
>
> I don't see how.
> Both cases sim the same.
>
> > b) what do some other synthesizers do?
>
> Quartus does about the same thing.
> 3 then 2 adders at the rtl level for the same cases
> and a few extra LUTs for the 3 counter case.
>
> * * *-- Mike Treseler

Synplify Pro implements exactly the same thing for both orders (in
vhdl). 12 luts (Xilinx v4). RTL viewer shows three input adder (a1 +
b1 + 10) for both.

As it should be...

Andy

On Sep 2, 7:48*am, Andy <jonesa...@comcast.net> wrote:
> On Aug 29, 6:29*pm, Mike Treseler <mtrese...@gmail.com> wrote:
>
> > jprovide...@yahoo.com wrote:
> > > I'm curious as to
> > > a) does Verilog some how require this?
>
> > I don't see how.
> > Both cases sim the same.
>
> > > b) what do some other synthesizers do?
>
> > Quartus does about the same thing.
> > 3 then 2 adders at the rtl level for the same cases
> > and a few extra LUTs for the 3 counter case.
>
> > * * *-- Mike Treseler
>
> Synplify Pro implements exactly the same thing for both orders (in
> vhdl). 12 luts (Xilinx v4). RTL viewer shows three input adder (a1 +
> b1 + 10) for both.
>
> As it should be...
>
> Andy

Andy -

My question is specific to Verilog, I don't know what the VHDL
language
spec requires. From a Verilog LRM:

All operators shall associate left to right with the exception of
the
conditional operator, which shall associate right to left.
Associativity
refers to the order in which the operators having the same
precedence
are evaluated.

Thus, in the following example B is added to A and then C is
subtracted
from the result of A+B.
A + B - C

So, if A is constant 3 and C is constant 1, does the language *spec*
prevent
Verilog from combining the two constants?

John Providenza

On Tue, 2 Sep 2008 08:27:10 -0700 (PDT), jprovidenza@yahoo.com wrote:

>So, if A is constant 3 and C is constant 1, does the language *spec*
>prevent Verilog from combining the two constants?

I don't believe so. Context-dependent operands of an
arithmetic expression (as are all operands of +, - etc)
are first widened to the context width, BEFORE any
arithmetic is done. Consequently, the order in which
addition-like operations are performed is unimportant,
because everything is done in the same bit-width.

I'm pretty sure (though I haven't yet proved it to my
own satisfaction) that multiplication can similarly be
rearranged algebraically, along with addition and
subtraction, without any effect on the results. But
division, with its potential loss of LSBs, will surely
exhibit some order dependences that would mess up
algebraic rearrangement.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

On Tue, 02 Sep 2008 17:27:57 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

>On Tue, 2 Sep 2008 08:27:10 -0700 (PDT), jprovidenza@yahoo.com wrote:
>
>>So, if A is constant 3 and C is constant 1, does the language *spec*
>>prevent Verilog from combining the two constants?
>

>I'm pretty sure (though I haven't yet proved it to my
>own satisfaction) that multiplication can similarly be
>rearranged algebraically, along with addition and
>subtraction, without any effect on the results.

I don't think this is true when you say "along with addition and
subtraction". Multiplication (& division) has higher precedence than
addition & subtraction so you can't re-arrange it with them. A + B + C
might give the same result whether you calculate (A+B)+C or even
(A+C)+B but this is certainly not true A + B*C. Because of precedence
rules this has to be implemented as A + (B*C) and can't be done as
(A+B)*C.

Muzaffer Kal

http://www.dspia.com

On Tue, 02 Sep 2008 10:01:09 -0700, Muzaffer Kal wrote:

>On Tue, 02 Sep 2008 17:27:57 +0100, Jonathan Bromley
><jonathan.bromley@MYCOMPANY.com> wrote:
>
>>I'm pretty sure (though I haven't yet proved it to my
>>own satisfaction) that multiplication can similarly be
>>rearranged algebraically, along with addition and
>>subtraction, without any effect on the results.
>
>I don't think this is true when you say "along with addition and
>subtraction". Multiplication (& division) has higher precedence than
>addition & subtraction so you can't re-arrange it with them.

No, for sure; that's why I said "rearranged algebraically".
I was thinking of rearrangements such as

A*B + A*C === A*(B+C)

which can often save hardware - in this case, one
multiplier saved with no other cost.

I don't know how effectively the existing synthesis tools
do that kind of thing, though.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley wrote:

> No, for sure; that's why I said "rearranged algebraically".
> I was thinking of rearrangements such as
>
> A*B + A*C === A*(B+C)
>
> which can often save hardware - in this case, one
> multiplier saved with no other cost.
>
> I don't know how effectively the existing synthesis tools
> do that kind of thing, though.

Since brand A+X can't even collect constants,
I would try this experiment on Synplify Pro or Mentor.

-- Mike Treseler

Andy wrote:

> Synplify Pro implements exactly the same thing for both orders (in
> vhdl). 12 luts (Xilinx v4). RTL viewer shows three input adder (a1 +
> b1 + 10) for both.
>
> As it should be...

Indeed. Thanks for posting the results.

-- Mike Treseler

IINM, VHDL has the same left to right evaluation requirements among
equal-precedence arithmetic operators IN SIMULATION as Verilog has.
But we are not talking about a simulation, we are talking about
synthesis. With equal precedence arithmetic operators that do not have
"side effects," order of execution is unobservable (has no external
effect), but amongst those that do have side effects (most commonly
encountered with function calls and logical operators), order is
important.

For synthesis, the execution order rules for simulation do not always
have any meaning. If the results are always equivalent between the LRM
execution ordering and the implementation ordering, it is by
definition legal synthesis. In this context, equivalence is evaluated
at register/IO boundaries, not intermediate expressions or even
assignments. That's why they call it Register Transfer Logic (or
Level).

Restraining the synthesized implementation to maintain the same order
of operations, for no other reason than matching the execution order
from simulation, would eliminate a whole host of beneficial
optimizations. We would then be forced to write code that explicitly
describes an optimal (our choice, not the tool's) implementation. And
register re-timing would be absolutely forbidden.

Andy

On Sep 2, 11:24*am, Mike Treseler <mtrese...@gmail.com> wrote:
> Andy wrote:
> > Synplify Pro implements exactly the same thing for both orders (in
> > vhdl). 12 luts (Xilinx v4). RTL viewer shows three input adder (a1 +
> > b1 + 10) for both.
>
> > As it should be...
>
> Indeed. Thanks for posting the results.
>
> * * * -- Mike Treseler

Yes, thank for posting the info, but I believe it is for VHDL. My
original
question was "does the Verilog language specifically forbid merging
the
constants" as opoosed to "how good is your synthesis tool".

John Providenza

jprovidenza@yahoo.com wrote:

> Yes, thank for posting the info, but I believe it is for VHDL.

I synthesized *your* verilog example.

> My original
> question was "does the Verilog language specifically forbid merging
> the constants" as opoosed to "how good is your synthesis tool".

The answers were NO, NO, and NO, before
the discussion strayed.
This happens sometimes on usenet.

-- Mike Treseler