Synplify Pro/ISE adder carry chain - interrupted

K

Ken

Guest
Hello folks,

I have quoted (at the end) an extract from the xilinx 5.2.03i trce command
which shows the worst path in my design.

The path is a carry chain within an adder but mid-way through the chain, it
jumps to another column (X45 to X39) leading to a big delay!

The VHDL was synthesised using Synplify Pro.

Sometimes, for other filters with the same style of VHDL, the tools don't do
this and maintain the carry chain in the same column which is clearly
faster.

Question is:

Is it Synplify optimisations that are causing this or perhaps the ISE
map/par stages and is there any way to avoid it?

Thanks in advance for your time,

Ken


Extract:



SLICE_X45Y5.CIN net (fanout=1) 0.000
AdderChain.tap27_sub_v648_1_cry_8/O
SLICE_X45Y5.COUT Tbyp 0.092 tap27_sub_v648_1_s_9_n

AdderChain.tap27_sub_v648_1_cry_9

AdderChain.tap27_sub_v648_1_cry_10

SLICE_X45Y6.CIN net (fanout=1) 0.000
AdderChain.tap27_sub_v648_1_cry_10/O
SLICE_X45Y6.X Tcinx 1.107
tap27_sub_v648_1_s_11_n

AdderChain.tap27_sub_v648_1_s_11

SLICE_X39Y18.F3 net (fanout=1) 0.910
tap27_sub_v648_1_s_11_n
SLICE_X39Y18.COUT Topcyf 0.668 tap27_sub_v648(11)

tap27_sub_v648_1_s_11_n_rt

AdderChain.tap27_sub_v648_1_cry_11_0

AdderChain.tap27_sub_v648_1_cry_12_0

SLICE_X39Y19.CIN net (fanout=1) 0.000
AdderChain.tap27_sub_v648_1_cry_12_0/O
SLICE_X39Y19.COUT Tbyp 0.092 tap27_sub_v648(13)

AdderChain.tap27_sub_v648_1_cry_13_0

AdderChain.tap27_sub_v648_1_cry_14_0







--
To reply by email, please remove the _MENOWANTSPAM from my email address.
 
Hi Ken,
One way to find out is to wade through the EDIF file and see what
Synplify has made. I suspect you'll find that the fault lies with the
map/par stages though. This happened to me when one of my designs started to
fill up the part, i.e. Slice % went to 100%, LUT % was maybe 70%. There were
a lot of long carry chains in it, and the Xilinx tools would break the
chains to make it fit. Floorplanning fixed the problem, I didn't try using
RLOC (see constraints guide) to fix the relative placement of the chain
elements, although this should work too.
Good luck mate, Syms.


"Ken" <aeu96186_MENOWANTSPAM@yahoo.co.uk> wrote in message
news:bpak1v$bcb$1@dennis.cc.strath.ac.uk...
Hello folks,

I have quoted (at the end) an extract from the xilinx 5.2.03i trce command
which shows the worst path in my design.

The path is a carry chain within an adder but mid-way through the chain,
it
jumps to another column (X45 to X39) leading to a big delay!

The VHDL was synthesised using Synplify Pro.

Sometimes, for other filters with the same style of VHDL, the tools don't
do
this and maintain the carry chain in the same column which is clearly
faster.

Question is:

Is it Synplify optimisations that are causing this or perhaps the ISE
map/par stages and is there any way to avoid it?

Thanks in advance for your time,

Ken


Extract:



SLICE_X45Y5.CIN net (fanout=1) 0.000
AdderChain.tap27_sub_v648_1_cry_8/O
SLICE_X45Y5.COUT Tbyp 0.092 tap27_sub_v648_1_s_9_n

AdderChain.tap27_sub_v648_1_cry_9

AdderChain.tap27_sub_v648_1_cry_10

SLICE_X45Y6.CIN net (fanout=1) 0.000
AdderChain.tap27_sub_v648_1_cry_10/O
SLICE_X45Y6.X Tcinx 1.107
tap27_sub_v648_1_s_11_n

AdderChain.tap27_sub_v648_1_s_11

SLICE_X39Y18.F3 net (fanout=1) 0.910
tap27_sub_v648_1_s_11_n
SLICE_X39Y18.COUT Topcyf 0.668 tap27_sub_v648(11)

tap27_sub_v648_1_s_11_n_rt

AdderChain.tap27_sub_v648_1_cry_11_0

AdderChain.tap27_sub_v648_1_cry_12_0

SLICE_X39Y19.CIN net (fanout=1) 0.000
AdderChain.tap27_sub_v648_1_cry_12_0/O
SLICE_X39Y19.COUT Tbyp 0.092 tap27_sub_v648(13)

AdderChain.tap27_sub_v648_1_cry_13_0

AdderChain.tap27_sub_v648_1_cry_14_0







--
To reply by email, please remove the _MENOWANTSPAM from my email address.
Click to expand...
 
"Symon" <symon_brewer@hotmail.com> wrote in message
news:bpauqv$1n8qij$1@ID-212844.news.uni-berlin.de...
Hi Ken,
One way to find out is to wade through the EDIF file and see what
Synplify has made. I suspect you'll find that the fault lies with the
map/par stages though. This happened to me when one of my designs started
to
fill up the part, i.e. Slice % went to 100%, LUT % was maybe 70%. There
were
a lot of long carry chains in it, and the Xilinx tools would break the
chains to make it fit. Floorplanning fixed the problem, I didn't try using
RLOC (see constraints guide) to fix the relative placement of the chain
elements, although this should work too.
Good luck mate, Syms.
Click to expand...
Symon,

Thanks for the reply.

I will take a look through the edif as you suggest.

However, the design is about 700 slices of a 14000 odd slice part so it is
not a utilisation issue....

Cheers,

Ken





---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.541 / Virus Database: 335 - Release Date: 14/11/2003
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top