I am running my design on spartan3a 3s700afg484 at 50 mhz.

There is no set up and hold time violations.

There is only one global clock net.

My clock report for two runs are

RUN 1:

Info: [707]: | Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)|

Info: [707]: | clk_int | BUFGMUX_X2Y11| No | 2056 | 0.236 | 1.213 |

Post pnr frequency is 140 mhz

I have compiled my design for some timing optimizations and I got below results.

RUN 2:

Info: [707]: | Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)|

Info: [707]: | clk_int | BUFGMUX_X2Y11| No | 2049 | 0.216 | 1.191 |

Post pnr freqency is 112 mhz

Note that clock net delay is lower in RUN 2 and it functions properly.

Post pnr frequency is higher in RUN 1 but designs doesnot function properly on fpga

Only difference between two runs is that RUN 2 is compiled with some timing options. I have simulated the post pnr netlist and it works fine.

What can be possible problem ? I want my design to function properly for RUN 1, since it has higher post pnr freqency. If clock net delay is the problem, then how to reduce it?


  • \$\begingroup\$ The 'fanout' number is different: why is that? \$\endgroup\$
    – pjc50
    Dec 13, 2012 at 13:29
  • \$\begingroup\$ Can you be a little more specific than "some timing options"? Are we supposed to guess what they were? \$\endgroup\$
    – Dave Tweed
    Dec 13, 2012 at 13:31
  • \$\begingroup\$ I have added -retime and -compile_for_timing options in second run. Hence fanout numbers are different \$\endgroup\$
    – quartz
    Dec 13, 2012 at 13:32
  • \$\begingroup\$ What have you re-run? Everything from synthesis onwards, or only the backend (Translate/Map/Par?) Have you tried taking the working synth run, and re-running Map/Par with different timing constraints) \$\endgroup\$
    – user16324
    Dec 13, 2012 at 13:46
  • \$\begingroup\$ What exactly is the "problem"? In the second run, you got smaller clock net delays, which means that in general, your design will have better clock-to-output times. Isn't that what you wanted? The maximum clock frequency isn't the only significant measure of performance, and often isn't the most important one. If the first run didn't work in the physical device, perhaps you need to specify tighter timing constraints on specific I/O signals. \$\endgroup\$
    – Dave Tweed
    Dec 13, 2012 at 13:57

1 Answer 1


I have been using Xilinx chips and tools for a very long time. The first version I used was Foundation 2.1, about 20 years ago. I do a LOT with FPGAs. So needless to say that I have learned a few things along the way.

One thing that I have learned is that if your timing constraints are set up correctly, and the timing analyzer says that you don't have a timing problem then you don't have a timing problem. Funny how that is-- a tool that actually works correctly!

This means that if you do have a timing problem then it is likely that either your constraints are not set up correctly, or you are doing something wrong with regard to signals that are asynchronous to your clock.

Doing a post PAR simulation (with timing data) does not guarantee proper operation. In fact, I would argue that for most designs with simple timing requirements that a post PAR timing simulation does nothing than what can be achieved with a behavioral simulation. These days I don't do timing simulations at all because of that, and I have never been burnt by that decision.

Anyway, the point is this: Odds are that either your timing constraints is wrong or you are doing something wrong with async signals.

Debugging this type of problem is difficult, but here's some tips on how to approach it:

Be meticulous and methodical in your debugging. Focus on what you know about the problem and follow it to the source. Don't take a shotgun approach and try lots of different things scattered around. Focus on the known problem (output signals are wrong) and follow that back to the bug. Don't just go hunting for anomalies in the many Xilinx report files-- since there are lots of things there to worry about and almost none of them are really problems. Anomaly hunting will just frustrate you.

  • \$\begingroup\$ Thank you David. Meticulous and methodical was the key!!! Apparently I haven't mentioned location of one input signal in .ucf file and this results in random placement of that signal by par on the board from one run to another. \$\endgroup\$
    – quartz
    Dec 14, 2012 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.