Timing issues in Xilinx and SmartXplorer

Hi,

My design has the following timing issues.

Period Required: Actual period:
4.096ns 6.058ns
8.138ns 10.442ns
2.035ns 1.429ns

In the design I have FFT processor somewhere in the middle, the processor works fine when I run it till 4096pts, but when I run it to higher pts sth like 16384 the time issues came. Now I was trying to use SmartXplorer, but in the first two strategies, it has 18000+ timing score, seems hopeless. That is quite a large one right, what else could be done to solve the timing?

SharpWeapon said:

Hi,

My design has the following timing issues.

Period Required: Actual period:
4.096ns 6.058ns
8.138ns 10.442ns
2.035ns 1.429ns

In the design I have FFT processor somewhere in the middle, the processor works fine when I run it till 4096pts, but when I run it to higher pts sth like 16384 the time issues came. Now I was trying to use SmartXplorer, but in the first two strategies, it has 18000+ timing score, seems hopeless. That is quite a large one right, what else could be done to solve the timing?

Click to expand...

You really should supply the following:
ISE version.
current utilization of the 16384 pt FFT design.

I would avoid using the two logic optimization runs in SmartXplorer. I've seen designs that stopped working randomly when using it.

18000 means there are 18 ns of negative slack across the entire design. The timing score represents the total negative slack in ps. A total negative slack of 18 ns is pretty large and SmartXporer is unlikely to converge.

I've found ISE seems to work best with utilization between 50%-75/80%. Outside that range I've noticed the placer seems to breakdown and often the placement results in very poor timing scores. I typically either heavily pipeline a design that I know will be outside the "sweet spot" range and/or partition the design. Partitioning the design is nice in that you can then place and route sections of the design that you know will always meet timing and never have to worry about them again. It will also speed up PAR due to less new stuff to place and route. The main issue with this flow is the extra effort of placing your design.

Regards

Hey, thanks for the reply. Full version 14.7. Find the attached text please.
And how can I partition my design btw, have never done that.

6% of LUTs and 3% of registers? Are you sure this is for the 16K FFT right? It's not a mistake and you posted a much smaller FFT design? If this is the correct report, you're running into the issue I see a lot when utilization is very very low, bad placement. I'm surprised you even meet timing for lower sizes with utilization that low.

To use partitions look at UG748 https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/Hierarchical_Design_Methodology_Guide.pdf

Regards

- - - Updated - - -

I just noticed you're using 72% of the RAMB36E1/FIFO36E1s in the design. That could be the source of your problem if that scales with the size of the FFT. The location of them are fixed and that will result in spreading the logic across the die.

Placing those would be a start, but I suspect once you do that you'll end up with timing violations to/from the RAMs.

Might need to know a lot more about the architecture of the design to make further suggestions.

Yes it is 16K FFT report. The thing is I had very large shift registers build from LUTs which made my synthesis very very slow, to be exact 8+ hours. Then I noticed that and changed it to RAM bases shift registers, that makes the RAM usage high but now I can generate my programming file in around 1 hour or so.