Why more area occupation for less logic usage ????

[Oleg]

Hi
I am using synplify pro v 7.5 to synthesis my design and here i have a
big paradox : i made 2 versions of my design. The 1st one does note
use any pipeline. The 2nd one is using more registers for pipelining 2
Successives main arhetmetic operations in the design and aftres
synthesis (even after PAR) i have more area occupation in the design
that doesnt have pipeline Why ?
Is it because the synthesis tool is traying hard to obtaine max
frequency so he is using more logic for that goal. For the other
design (that use pipeline) the tool dont need to make a lot of effort
to reach the desired freq ???
Any one help
Tanks in advence.

Here is the reports result :

Design without pipelining
----------------------------
Resource Usage Report for Decoder_for_synth_np

Mapping to part: xc2v6000ff1152-5
Cell usage:
FD 4 uses
FDE 3993 uses
FDR 3 uses
FDRS 5 uses
GND 73 uses
MUXCY 384 uses
MUXCY_L 4100 uses
MUXF5 5563 uses
MUXF6 2602 uses
MUXF7 19 uses
MUXF8 4 uses
RAMB16_S18 1 use
RAMB16_S2 2 uses
RAMB16_S36_S36 16 uses
VCC 5 uses
XORCY 1796 uses

I/O Register bits: 0
Register bits not including I/Os: 4005 (5%)

RAM/ROM usage summary
Block Rams : 19 of 144 (13%)


Mapping Summary:
Total LUTs: 17563 (25%)


Design with piplining
----------------------
Mapping to part: xc2v6000ff1152-5
Cell usage:
FD 5 uses
FDE 3924 uses
FDR 3 uses
FDRS 5 uses
GND 73 uses
MUXCY 384 uses
MUXCY_L 4100 uses
MUXF5 5752 uses
MUXF6 2602 uses
MUXF7 19 uses
MUXF8 4 uses
RAMB16_S18 1 use
RAMB16_S2 2 uses
RAMB16_S36_S36 16 uses
VCC 5 uses
XORCY 1796 uses

I/O primitives: 42
IBUF 39 uses
OBUF 3 uses

BUFGP 1 use

I/O Register bits: 0
Register bits not including I/Os: 3937 (5%)

RAM/ROM usage summary
Block Rams : 19 of 144 (13%)


Global Clock Buffers: 1 of 16 (6%)


Mapping Summary:
Total LUTs: 17315 (25%)

 

[Ralf Hildebrandt]

Oleg wrote:

big paradox : i made 2 versions of my design. The 1st one does note
use any pipeline. The 2nd one is using more registers for pipelining 2
Successives main arhetmetic operations in the design and aftres
synthesis (even after PAR) i have more area occupation in the design
that doesnt have pipeline Why ?
Is it because the synthesis tool is traying hard to obtaine max
frequency so he is using more logic for that goal. For the other
design (that use pipeline) the tool dont need to make a lot of effort
to reach the desired freq ???

This could be one possibility. -> Synthesize for area only to test.

Another possibility would be, that some combinational logic could be
transformed into some more states in a state machine. Let me explain:
If you have quite a buch of nested if-then and case statements, this
_could_ be a lot of combinational logic. If you use more states for your
state machines instead, the logic may be simpler.


Ralf

 

[Oleg]

Oleg wrote:



This could be one possibility. -> Synthesize for area only to test.

Another possibility would be, that some combinational logic could be
transformed into some more states in a state machine. Let me explain:
If you have quite a buch of nested if-then and case statements, this
_could_ be a lot of combinational logic. If you use more states for your
state machines instead, the logic may be simpler.


Ralf

Hi Ralf and thanks for taking time to answer, but i didnt understud
what u mean by : This could be one possibility. -> Synthesize for area
only to test. ???explaine please.
And for the seconde posibility if i understud u well then you mean
that the pipelined version of the design "have been very lucky" so the
tool did infer a state machine for its combinational logic and that
did help a design to occpy less logic. nevertheless the tool did note
for the non piplined version of the design. If so then i have
unselected the option (in the Imp Option of synplify) that says : "FM
compiler" that tel the synthesis tool to detect and optimize FSM and i
have repeat the synthesis of pipeliened design. result : i still have
a paradoxal result.

 

[Ralf Hildebrandt]

Synthesize for area
only to test. ???explaine please.

Tell your synthesis tool, not to optimize for speed, but for area. Let
it freely optimize and don't care about a slow design.
Often in a synthesis tool area optimizing is performend, if you don't
specify a clock or speed constraints.

Optimizing for speed means trading area for speed. If you synthesis tool
had hard work while optimizing the non-pilelined version to fit your
speed constrains, this will result in a "explosion of area". So you
can't really compare the non-pipelined and the pipelined version. (O.k.,
you can compare them, if you are only interested in the final result,
but you can't find the reason, why the non-pipelind version is bigger.)

If the non-pipelined version is not bigger after area optimizing, you
found the reason. If it is even then bigger, think about "lucky" logic
reduction, discussed in this posting below:

And for the seconde posibility if i understud u well then you mean
that the pipelined version of the design "have been very lucky" so the
tool did infer a state machine for its combinational logic and that
did help a design to occpy less logic.

Well nearly ... let me describe it in a different way:
Assume, you have a state machine with n states. (n < 2^x, x is integer;
this means: you have free states)
Assume in one state of the state machine a huge buch of if-then and
case-statements have to be performed. This means: If the state machine
jumps to this state, a huge amount of combinational logic will be
triggered -> a lot of new values.

Then, in the pipelined design, this "big state" is split to several
smaller ones, but the number of states m does not exceed 2^x. (You use
free states.) Maybe because no state flipflop is added and the big
if-then and case statemens can be split from the "big state" to the
smaller states and become simpler, the amount of combinational logic
will be reduced.

....
case state is
when ...
when big_state => -- huge if-then / case statements
when ...
when others => ...
end case;
....

is transformed to

....
case state is
when ...
when big_state_part_1 => -- small if-then / case
when big_state_part_2 => -- small if-then / case
.....
when big_state_part_n => -- small if-then / case
when ...
when others => ...
end case;
....

=> The test, if some exceptions are taken (in the big if-then / case
statemens) is transformed into the state decoding.


Note: This is only an idea! This _may_ reduce area, if some functional
tests become simpler, when computing them step-by-step.


Ralf