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?
Thanks,
Best Answer
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.