FFT Implementation on Spartan 3E xc3s100e-5vq100

[Abhinav Mishra]

Hello Everyone,

I am trying to implement 64-point FFT on Spartan 3E xc3s100e-5vq100. But when I compile my code the overusage error appears. I have tried many ways to optimize the code but could not solve it.

Is it possible to implement it on this hardware ?

Can anyone tell what are the minimum hardware requirements?

 

[weetabixharry]

I can't give really specific help, as I am not familiar with the Spartan 3. However, if you look at Table 3.1 of this: [link], a 64-point FFT can be achieved with 264 multipliers and 1032 adders (or 196 multipliers and 1280 adders).

Those numbers seem a bit high to me, so there is possibly a way to do better than that. Perhaps this [link] is relevant (a 64-point FFT implemented on a Spartan 3E).

 

[allsey87]

Hi Abhinav,

There are no minimum hardware requirements generally, unless you specify a particular speed that this 64-point FFT must run at.

It is definitely possible to implement in hardware, but what you will need to do is serialize it. Otherwise you'll get resource usage like weetabixharry mentioned. Doing this by hand is awful and I highly wouldn't recommend it.

I would get started with this Versatile FFT, it claims to be synthesizable on the xc3s500e with reasonable resource usage using four of the 18x18 multipliers. You have four multipliers in your FPGA... it will be a tight fit, but it could work if the FPGA is to provide the FFT and little to no other functionality...

Good luck!

 

[Abhinav Mishra]

Hello Everyone,

Thank you for your suggestions. I tried the above mentioned links. Now, I have my code synthesized but there is still MAP errors. how can I fix it?

Do I really have to use FPGA Editor, never have used it and as the design is heavy I dont really want to pick n place. So, is there another way round?

 

[ads-ee]

use smartxporer it uses various seed and map/par settings to try and find a solution that routes.

 

[allsey87]

Hi Abhinav Mishra,

Can you be more specific about which approach you are taking?

If you are having mapping errors I would say you might want to look at rearranging stuff at the HDL level, as the autorouter for FPGAs is very good, and if it can't find a solution you may be out of luck for your current configuration.

Perhaps you can give more context about how you are using this FPGA? where does the input come from, and where does the output go to? what are the control signals (reset, enable, start, busy etc) connected to?

 

[ads-ee]

If you are having mapping errors I would say you might want to look at rearranging stuff at the HDL level, as the autorouter for FPGAs is very good, and if it can't find a solution you may be out of luck for your current configuration.

Not in my experience with dense designs. Which this one may be as the device the OP is using is rather small for the application. Also the indication from route implies the design is probably packing CLBs with unrelated logic, which map will do when the part is nearly full.

Abhinav Mishra, you should probably post the utilization reports for the design and the settings used for XST, map, and par. The command lines used should be in the respective report files.

 

[allsey87]

Not in my experience with dense designs. Which this one may be as the device the OP is using is rather small for the application. Also the indication from route implies the design is probably packing CLBs with unrelated logic, which map will do when the part is nearly full.

Quite possibly, I haven't gone down this path before. In any case, it is important that the inputs, outputs and control signals are routed out to the pads or connected to an internal controller. There is going to be very little room left for any logic inside this device and there is no point trying to squeeze in this FFT if you can't provide the IO and control lines to it...

 

[ads-ee]

I'm going by the OP's error, which was from route (par) so they have the I/O to fit the design, otherwise it wouldn't have made it to par (it would have failed map). So the problem appears to be bad placement, which I've also seen when a design starts reaches 80%+ utilization.

Once Abhinav Mishra post the reports a determination can be made of how to proceed. I still suggest they should try smartxplorer, if most of the strategies have 0 timing scores then the original map placement was probably non-optimal.

 

[Abhinav Mishra]

====================================================================
hello friends, |
|
This is what i got from xplorer. i m still working to use xplorer. So, what should I do next? |
=====================================================================
----------------------------------------------------------------------

FPGA SmartXplorer (tm) Version 13.2

----------------------------------------------------------------------
Strategy : MapTimingExtraEffort
----------------------------------------------------------------------
Run index : run1
Map options : -timing -ol high -xe n
Par options : -ol high
Total estimated power consumption : None (mW)
Status : Failed par
Current Best (Lowest) Timing Score : None
Current Best Strategy : None
----------------------------------------------------------------------
----------------------------------------------------------------------
Strategy : MapPhysSynthesis
----------------------------------------------------------------------
Run index : run2
Map options : -timing -ol high -xe n -register_duplication on -logic_opt on
Par options : -ol high
Total estimated power consumption : None (mW)
Status : Failed par
Current Best (Lowest) Timing Score : None
Current Best Strategy : None
----------------------------------------------------------------------
----------------------------------------------------------------------
Strategy : ParHighEffort2
----------------------------------------------------------------------
Run index : run4
Map options : -cm area -t 2
Par options : -ol high -t 2
Total estimated power consumption : None (mW)
Status : Failed par
Current Best (Lowest) Timing Score : None
Current Best Strategy : None
----------------------------------------------------------------------
----------------------------------------------------------------------
Strategy : ParHighEffort1
----------------------------------------------------------------------
Run index : run3
Map options : -cm area
Par options : -ol high
Total estimated power consumption : None (mW)
Status : Failed par
Current Best (Lowest) Timing Score : None
Current Best Strategy : None
----------------------------------------------------------------------
----------------------------------------------------------------------
Strategy : MapTiming1
----------------------------------------------------------------------
Run index : run5
Map options : -timing -ol high
Par options : -ol high
Total estimated power consumption : None (mW)
Status : Failed par
Current Best (Lowest) Timing Score : None
Current Best Strategy : None
----------------------------------------------------------------------
----------------------------------------------------------------------
Strategy : MapTiming2
----------------------------------------------------------------------
Run index : run6
Map options : -timing -ol high -t 9
Par options : -ol high -t 9
Total estimated power consumption : None (mW)
Status : Failed par
Current Best (Lowest) Timing Score : None
Current Best Strategy : None
----------------------------------------------------------------------
----------------------------------------------------------------------
Strategy : MapUseIOReg
----------------------------------------------------------------------
Run index : run7
Map options : -timing -ol high -pr b
Par options : -ol high
Total estimated power consumption : None (mW)
Status : Failed par
Current Best (Lowest) Timing Score : None
Current Best Strategy : None
----------------------------------------------------------------------

 

[ads-ee]

All of the runs failed par, not a good sign. All of them mapped, so there is enough "logic" in the device.

Are the I/O's you are using locked down? Where are the I/O's placed? Don't give just give us a list of the pin locations...I'd prefer to know what banks are used and the I/O that are assigned to them. You may have a really bad pin placement, which is aggravating the routing issue.

You still need to post the resource utilization reports from map and you need to include the par report. You're probably running into a problem with LUT packing that is killing the router. You should also tell us what XST options are set, you may want to force area to be the primary goal of the synthesis and use the highest effort level.

Regards

 

[mrflibble]

You still need to post the resource utilization reports from map and you need to include the par report. You're probably running into a problem with LUT packing that is killing the router. You should also tell us what XST options are set, you may want to force area to be the primary goal of the synthesis and use the highest effort level.

Mmmh, what do you mean with LUT packing killing the router? I can think of a few things, but those are not a 100% match for how you describe it...

 

[ads-ee]

When par starts packing LUTs when it's really full, unrelated logic gets stuffed into CLBs resulting in increased congestion, which is what the OP reported on their original run. That doesn't "kill the router" but causes the router to fail, which is what I was referring to.

 

[mrflibble]

Check. Which was one of out the set of things I was thinking you could mean. Hell, sometimes even packing it really full when the logic IS related is bad enough. At one time I thought I'd be real clever and pack things close and snug. You know, to keep routing delays to a minimum. Ooopsie, now I ran out of 1-step routes. As in you have 1,2,4 step routes, and you had better balance a bit between those. So it was actually more optimal to have slightly more relaxed constraints, so it would actually route. I forgot what the actual error message was, but it boiled down to "sorry, ran out of possible routes". And of course those *bleep* marketing people at Xilinx thought it's be cool to have routing congestion info available for Virtex family, but not for spartan. Because extracting & displaying the exact same info for spartan is soooo much harder. Yeah, that's it.

 

[Abhinav Mishra]

Par report
=================================================

release 13.2 par o.61xd (nt)
copyright (c) 1995-2011 xilinx, inc. All rights reserved.

Abhi-pc:: Wed mar 12 19:48:18 2014

par -w -intstyle ise -ol std -t 1 ifft_map.ncd ifft.ncd ifft.pcf


constraints file: Ifft.pcf.
Loading device for application rf_device from file '3s500e.nph' in environment c:\xilinx\13.2\ise_ds\ise\.
"ifft" is an ncd, version 3.2, device xc3s500e, package fg320, speed -4
infoar:469 - although the overall effort level (-ol) for this implementation has been set to standard, placer will run
at effort level high. To override this, please set the placer effort level (-pl) to standard.
Vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
info:security:50 - the xilinxd_license_file environment variable is set to 'd:\new folder\xilinx ise design suite
13.2\spyral'.
Info:security:52 - the lm_license_file environment variable is set to 'd:\new folder\xilinx ise design suite
13.2\spyral'.
Info:security:54 - 'xc3s500e' is a webpack part.
Warning:security:43 - no license file was found in the standard xilinx license directory.
Warning:security:44 - no license file was found.
Please run the xilinx license configuration manager
(xlcm or "manage xilinx licenses")
to assist in obtaining a license.
Warning:security:42 - your software subscription period has lapsed. Your current version of xilinx tools will continue
to function, but you no longer qualify for xilinx software updates or new releases.

----------------------------------------------------------------------

initializing temperature to 85.000 celsius. (default - range: -40.000 to 100.000 celsius)
initializing voltage to 1.140 volts. (default - range: 1.140 to 1.320 volts)

infoar:282 - no user timing constraints were detected or you have set the option to ignore timing constraints ("par
-x"). Place and route will run in "performance evaluation mode" to automatically improve the performance of all
internal clocks in this design. Because there are not defined timing requirements, a timing score will not be
reported in the par report in this mode. The par timing summary will list the performance achieved for each clock.
Note: For the fastest runtime, set the effort level to "std". For best performance, set the effort level to "high".

Device speed data version: "production 1.27 2011-06-20".


Design summary report:

Number of external iobs 99 out of 232 42%

number of external input iobs 51

number of external input ibufs 51

number of external output iobs 48

number of external output iobs 48

number of external bidir iobs 0


number of bufgmuxs 1 out of 24 4%
number of mult18x18sios 16 out of 20 80%
number of ramb16s 2 out of 20 10%
number of slices 4386 out of 4656 94%
number of slicems 392 out of 2328 16%



overall effort level (-ol): Standard
placer effort level (-pl): High
placer cost table entry (-t): 1
router effort level (-rl): Standard

starting initial timing analysis. Real time: 6 secs
finished initial timing analysis. Real time: 6 secs


starting placer
total real time at the beginning of placer: 6 secs
total cpu time at the beginning of placer: 6 secs

phase 1.1 initial placement analysis
phase 1.1 initial placement analysis (checksum:9abc59) real time: 8 secs

phase 2.7 design feasibility check
phase 2.7 design feasibility check (checksum:9abc59) real time: 8 secs

phase 3.31 local placement optimization
phase 3.31 local placement optimization (checksum:9abc59) real time: 8 secs

phase 4.2 initial clock and io placement
....
Phase 4.2 initial clock and io placement (checksum:937c926f) real time: 9 secs

phase 5.30 global clock region assignment
phase 5.30 global clock region assignment (checksum:937c926f) real time: 9 secs

phase 6.36 local placement optimization
phase 6.36 local placement optimization (checksum:937c926f) real time: 9 secs

phase 7.3 local placement optimization
....
Phase 7.3 local placement optimization (checksum:5db1a340) real time: 9 secs

phase 8.5 local placement optimization
phase 8.5 local placement optimization (checksum:5db1a340) real time: 9 secs

phase 9.8 global placement
..........................
.......................................................................................................
.................................
.............................................................................................................
............................................................................................................
........................................................................................................................
Phase 9.8 global placement (checksum:6fc2b19) real time: 51 secs

phase 10.5 local placement optimization
phase 10.5 local placement optimization (checksum:6fc2b19) real time: 51 secs

phase 11.18 placement optimization
phase 11.18 placement optimization (checksum:509a4c66) real time: 59 secs

phase 12.5 local placement optimization
phase 12.5 local placement optimization (checksum:509a4c66) real time: 59 secs

total real time to placer completion: 1 mins
total cpu time to placer completion: 57 secs
writing design to file ifft.ncd



starting router


phase 1 : 24557 unrouted; real time: 1 mins 6 secs

phase 2 : 18210 unrouted; real time: 1 mins 7 secs

phase 3 : 4895 unrouted; real time: 1 mins 11 secs

phase 4 : 4906 unrouted; (par is working to improve performance) real time: 1 mins 12 secs
warning:route:438 - the router has detected an unroutable situation due to local congestion. The router will finish the
rest of the design and leave one or more connections as unrouted. The cause of this behavior might be putting too
much logic into a single clb. To allow you to use fpga editor to isolate the problems, the following is a list of (up
to 10) such congested connections:
Congestion on : Omux(49337,1840) signal : Fft/comp_mult1/mul2/mmult_mult_out_submult_01_p_to_adder_b_1
congestion on : Omux(49337,1840) signal : Fft/twdf1<15>
congestion on : Omux(-50096,-54291) signal : Fft/comp_mult2/mul2/mmult_mult_out_submult_01_p_to_adder_b_5
congestion on : Omux(-50096,-54291) signal : Fft/comp_mult2/mul2/mmult_mult_out_submult_01_p_to_adder_b_1
congestion on : Omux(-43275,-51520) signal : Fft/comp_mult2/mul2/mmult_mult_out_submult_01_p_to_adder_b_7
congestion on : Omux(-43275,-51520) signal : Fft/twdf2<39>
congestion on : Omux(40869,4496) signal : Fft/twdf1<37>
congestion on : Omux(40869,4496) signal : Fft/twdf1<36>


phase 5 : 2 unrouted; (par is working to improve performance) real time: 7 mins 1 secs

phase 6 : 2 unrouted; (par is working to improve performance) real time: 7 mins 4 secs

phase 7 : 2 unrouted; (par is working to improve performance) real time: 7 mins 7 secs

total real time to router completion: 7 mins 7 secs
total cpu time to router completion: 6 mins 28 secs

partition implementation status
-------------------------------

no partitions were found in this design.

-------------------------------

generating "par" statistics.

**************************
generating clock report
**************************

+---------------------+--------------+------+------+------------+-------------+
| clock net | resource |locked|fanout|net skew(ns)|max delay(ns)|
+---------------------+--------------+------+------+------------+-------------+
| clock_bufgp | bufgmux_x2y10| no | 2909 | 0.089 | 0.206 |
+---------------------+--------------+------+------+------------+-------------+

* net skew is the difference between the minimum and maximum routing
only delays for the net. Note this is different from clock skew which
is reported in trce timing report. Clock skew is the difference between
the minimum and maximum path delays which includes logic delays.

* the fanout is the number of component pins not the individual bel loads,
for example slice loads not ff loads.

Timing score: 0 (setup: 0, hold: 0)

asterisk (*) preceding a constraint indicates it was not met.
This may be due to a setup or hold violation.

----------------------------------------------------------------------------------------------------------
constraint | check | worst case | best case | timing | timing
| | slack | achievable | errors | score
----------------------------------------------------------------------------------------------------------
autotimespec constraint for clock net clo | setup | n/a| 17.458ns| n/a| 0
ck_bufgp | hold | 0.674ns| | 0| 0
----------------------------------------------------------------------------------------------------------


all constraints were met.
Info:timing:2761 - n/a entries in the constraints list may indicate that the
constraint is not analyzed due to the following: No paths covered by this
constraint; other constraints intersect with this constraint; or this
constraint was disabled by a path tracing control. Please run the timespec
interaction report (tsi) via command line (trce tsi) or timing analyzer gui.


Generating pad report.

2 signals are not completely routed. See the ifft.unroutes file for a list of all unrouted signals.

Warningar:100 - design is not completely routed. There are 2 signals that are not
completely routed in this design. See the "ifft.unroutes" file for a list of
all unrouted signals. Check for other warnings in your par report that might
indicate why these nets are unroutable. These nets can also be evaluated
in fpga editor by selecting "unrouted nets" in the list window.

Total real time to par completion: 7 mins 11 secs
total cpu time to par completion: 6 mins 31 secs

peak memory usage: 277 mb

placement: Completed - no errors found.
Routing: Completed - errors found.

Number of error messages: 0
number of warning messages: 3
number of info messages: 2

writing design to file ifft.ncd



par done!

- - - updated - - -

par report
=================================================
release 13.2 par o.61xd (nt)
copyright (c) 1995-2011 xilinx, inc. All rights reserved.

Abhi-pc:: Wed mar 12 19:48:18 2014

par -w -intstyle ise -ol std -t 1 ifft_map.ncd ifft.ncd ifft.pcf


constraints file: Ifft.pcf.
Loading device for application rf_device from file '3s500e.nph' in environment c:\xilinx\13.2\ise_ds\ise\.
"ifft" is an ncd, version 3.2, device xc3s500e, package fg320, speed -4
infoar:469 - although the overall effort level (-ol) for this implementation has been set to standard, placer will run
at effort level high. To override this, please set the placer effort level (-pl) to standard.
Vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
info:security:50 - the xilinxd_license_file environment variable is set to 'd:\new folder\xilinx ise design suite
13.2\spyral'.
Info:security:52 - the lm_license_file environment variable is set to 'd:\new folder\xilinx ise design suite
13.2\spyral'.
Info:security:54 - 'xc3s500e' is a webpack part.
Warning:security:43 - no license file was found in the standard xilinx license directory.
Warning:security:44 - no license file was found.
Please run the xilinx license configuration manager
(xlcm or "manage xilinx licenses")
to assist in obtaining a license.
Warning:security:42 - your software subscription period has lapsed. Your current version of xilinx tools will continue
to function, but you no longer qualify for xilinx software updates or new releases.

----------------------------------------------------------------------

initializing temperature to 85.000 celsius. (default - range: -40.000 to 100.000 celsius)
initializing voltage to 1.140 volts. (default - range: 1.140 to 1.320 volts)

infoar:282 - no user timing constraints were detected or you have set the option to ignore timing constraints ("par
-x"). Place and route will run in "performance evaluation mode" to automatically improve the performance of all
internal clocks in this design. Because there are not defined timing requirements, a timing score will not be
reported in the par report in this mode. The par timing summary will list the performance achieved for each clock.
Note: For the fastest runtime, set the effort level to "std". For best performance, set the effort level to "high".

Device speed data version: "production 1.27 2011-06-20".


Design summary report:

Number of external iobs 99 out of 232 42%

number of external input iobs 51

number of external input ibufs 51

number of external output iobs 48

number of external output iobs 48

number of external bidir iobs 0


number of bufgmuxs 1 out of 24 4%
number of mult18x18sios 16 out of 20 80%
number of ramb16s 2 out of 20 10%
number of slices 4386 out of 4656 94%
number of slicems 392 out of 2328 16%



overall effort level (-ol): Standard
placer effort level (-pl): High
placer cost table entry (-t): 1
router effort level (-rl): Standard

starting initial timing analysis. Real time: 6 secs
finished initial timing analysis. Real time: 6 secs


starting placer
total real time at the beginning of placer: 6 secs
total cpu time at the beginning of placer: 6 secs

phase 1.1 initial placement analysis
phase 1.1 initial placement analysis (checksum:9abc59) real time: 8 secs

phase 2.7 design feasibility check
phase 2.7 design feasibility check (checksum:9abc59) real time: 8 secs

phase 3.31 local placement optimization
phase 3.31 local placement optimization (checksum:9abc59) real time: 8 secs

phase 4.2 initial clock and io placement
....
Phase 4.2 initial clock and io placement (checksum:937c926f) real time: 9 secs

phase 5.30 global clock region assignment
phase 5.30 global clock region assignment (checksum:937c926f) real time: 9 secs

phase 6.36 local placement optimization
phase 6.36 local placement optimization (checksum:937c926f) real time: 9 secs

phase 7.3 local placement optimization
....
Phase 7.3 local placement optimization (checksum:5db1a340) real time: 9 secs

phase 8.5 local placement optimization
phase 8.5 local placement optimization (checksum:5db1a340) real time: 9 secs

phase 9.8 global placement
..........................
.......................................................................................................
.................................
.............................................................................................................
............................................................................................................
........................................................................................................................
Phase 9.8 global placement (checksum:6fc2b19) real time: 51 secs

phase 10.5 local placement optimization
phase 10.5 local placement optimization (checksum:6fc2b19) real time: 51 secs

phase 11.18 placement optimization
phase 11.18 placement optimization (checksum:509a4c66) real time: 59 secs

phase 12.5 local placement optimization
phase 12.5 local placement optimization (checksum:509a4c66) real time: 59 secs

total real time to placer completion: 1 mins
total cpu time to placer completion: 57 secs
writing design to file ifft.ncd



starting router


phase 1 : 24557 unrouted; real time: 1 mins 6 secs

phase 2 : 18210 unrouted; real time: 1 mins 7 secs

phase 3 : 4895 unrouted; real time: 1 mins 11 secs

phase 4 : 4906 unrouted; (par is working to improve performance) real time: 1 mins 12 secs
warning:route:438 - the router has detected an unroutable situation due to local congestion. The router will finish the
rest of the design and leave one or more connections as unrouted. The cause of this behavior might be putting too
much logic into a single clb. To allow you to use fpga editor to isolate the problems, the following is a list of (up
to 10) such congested connections:
Congestion on : Omux(49337,1840) signal : Fft/comp_mult1/mul2/mmult_mult_out_submult_01_p_to_adder_b_1
congestion on : Omux(49337,1840) signal : Fft/twdf1<15>
congestion on : Omux(-50096,-54291) signal : Fft/comp_mult2/mul2/mmult_mult_out_submult_01_p_to_adder_b_5
congestion on : Omux(-50096,-54291) signal : Fft/comp_mult2/mul2/mmult_mult_out_submult_01_p_to_adder_b_1
congestion on : Omux(-43275,-51520) signal : Fft/comp_mult2/mul2/mmult_mult_out_submult_01_p_to_adder_b_7
congestion on : Omux(-43275,-51520) signal : Fft/twdf2<39>
congestion on : Omux(40869,4496) signal : Fft/twdf1<37>
congestion on : Omux(40869,4496) signal : Fft/twdf1<36>


phase 5 : 2 unrouted; (par is working to improve performance) real time: 7 mins 1 secs

phase 6 : 2 unrouted; (par is working to improve performance) real time: 7 mins 4 secs

phase 7 : 2 unrouted; (par is working to improve performance) real time: 7 mins 7 secs

total real time to router completion: 7 mins 7 secs
total cpu time to router completion: 6 mins 28 secs

partition implementation status
-------------------------------

no partitions were found in this design.

-------------------------------

generating "par" statistics.

**************************
generating clock report
**************************

+---------------------+--------------+------+------+------------+-------------+
| clock net | resource |locked|fanout|net skew(ns)|max delay(ns)|
+---------------------+--------------+------+------+------------+-------------+
| clock_bufgp | bufgmux_x2y10| no | 2909 | 0.089 | 0.206 |
+---------------------+--------------+------+------+------------+-------------+

* net skew is the difference between the minimum and maximum routing
only delays for the net. Note this is different from clock skew which
is reported in trce timing report. Clock skew is the difference between
the minimum and maximum path delays which includes logic delays.

* the fanout is the number of component pins not the individual bel loads,
for example slice loads not ff loads.

Timing score: 0 (setup: 0, hold: 0)

asterisk (*) preceding a constraint indicates it was not met.
This may be due to a setup or hold violation.

----------------------------------------------------------------------------------------------------------
constraint | check | worst case | best case | timing | timing
| | slack | achievable | errors | score
----------------------------------------------------------------------------------------------------------
autotimespec constraint for clock net clo | setup | n/a| 17.458ns| n/a| 0
ck_bufgp | hold | 0.674ns| | 0| 0
----------------------------------------------------------------------------------------------------------


all constraints were met.
Info:timing:2761 - n/a entries in the constraints list may indicate that the
constraint is not analyzed due to the following: No paths covered by this
constraint; other constraints intersect with this constraint; or this
constraint was disabled by a path tracing control. Please run the timespec
interaction report (tsi) via command line (trce tsi) or timing analyzer gui.


Generating pad report.

2 signals are not completely routed. See the ifft.unroutes file for a list of all unrouted signals.

Warningar:100 - design is not completely routed. There are 2 signals that are not
completely routed in this design. See the "ifft.unroutes" file for a list of
all unrouted signals. Check for other warnings in your par report that might
indicate why these nets are unroutable. These nets can also be evaluated
in fpga editor by selecting "unrouted nets" in the list window.

Total real time to par completion: 7 mins 11 secs
total cpu time to par completion: 6 mins 31 secs

peak memory usage: 277 mb

placement: Completed - no errors found.
Routing: Completed - errors found.

Number of error messages: 0
number of warning messages: 3
number of info messages: 2

writing design to file ifft.ncd



par done!

 

[mrflibble]

Seems to be a fairly readable warning...

WARNING:Route:438 - The router has detected an unroutable situation due to local congestion. The router will finish the
rest of the design and leave one or more connections as unrouted. The cause of this behavior might be putting too
much logic into a single CLB. To allow you to use FPGA editor to isolate the problems, the following is a list of (up
to 10) such congested connections:

Congestion due to packing too much into CLB. Please do not pack so much and try again. Thank you for your cooperation citizen.

 

[Abhinav Mishra]

Hardware Utilization Report
=======================================

========================================

- - - Updated - - -

Can you plz elaborate how not to over-pack?

- - - Updated - - -

Can you plz elaborate how not to over-pack?

 

[ads-ee]

According to the utilization report the design isn't over packed, in fact the design isn't even packing unrelated logic together, and has enough resources (LUT, memory, mults) to fit. I'm somewhat surprised that smartxplorer didn't have at least 1 run that completed route.

Some questions you still haven't answered...

Q1) How did you select the I/O placement? (see post #11)

Q2) What settings are your using for XST?

Q3) What are the map settings?


I would also take a look at the design in planahead (if you have it) or in FPGA editor and take a look at where the congestion problem is located. I've played tricks like forcing regions of SLICES that aren't allowed so that it spreads out logic so it has more available routing resources.

regards.

 

[mrflibble]

You can get precisely this if you use RLOCs to stuff it too close together. That way it's starved for routing resources while the device is still far from full. Indeed, best check it in planahead. Although for the non-expensive devices I have not been able to find an actual useful metric to display to check routing congestion. Other than my usual "gee, that looks a bit crowded" eyeballing approach. Which usually works as well, but sometimes an overlay that just shows it would be nice. So if you know one that works for let say spartan-6 please tell me.

 

[pbernardi]

Your problem is here:

Number of Slices 4386 out of 4656 94%

You need additional slices for routing, and ISE cannot find a way to route your logic with only this 6% remaining slices. By the way, you are using a XC3S500E (which has 4656 Slices), not a 100E.

You need to use less slices. Better way to accomplish this is removing some register, using less pipelines, using less distributed memory (maybe using additional BRAM instead distributed RAM?), or having a better use of your flip-flops (using enable when possible, using flip-flop reset instead zero attribution).