timing and timing reports (again)

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

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

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

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

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

Run the design through Timing Analizer to find out which path(s) are failing timing.

-P@

hi

thanks for the tip. well i did that but to be honest i couldn't quit figure out what to do with all the info. is there a manual or tutorial what all this means? if somebody wants to have a look at my design i would appreciate it! http://193.170.52.132/xilinx/system.ncd http://193.170.52.132/xilinx/system.pcf

are there perhaps some examples from xilinx that teach you how to use those tools and to debug?

thanks urban

i forgot mention that i did a static timing analysis with the timing analyzer. i also looked into the manual for trace but i would rather have some examples if there are some. thanks

Three tools can be very useful when chasing down timing issues:

1) trace (timing) report: generally, look to see the failing time specs; when you run it with useful options, you can get a feel for the critical path 2) delay report: sort of a netlist, marginally readable... but used in conjunction with the timing report, you can see variations on delays on any common net, which may give a clue to location issues causing the timing problems. You can also see how your clocks are routed; i.e, which BUFGs are used, etc. 3) the FPGA Editor: for small designs, you could go here quickly; however, for large designs, it takes a long time to load, so I avoid it as much as I can. But when you have to do it, do it with the report information handy. It can then be used as a reference for manual floorplanning (as in, seeing how the tool did a lousy job, and then picking [better] fixed locations for a few critical points (e.g., BUFGs, FFs.)

A fourth 'tool' is the data sheet for the part. All the timing definitions (tco, tpd, tsu, ...) are defined there; when you run across an unfamiliar one in the timing report, refer to the data sheet. Sometimes the problem is as simple as forcing a register to be in, or out of, an IOB.

The results of this analysis should guide you in further decision-making:

1) Floorplanning. 2) Re-coding portions of the design to make the critical path(s) non-critical. 3) Adding (or removing) timing constraints, such as multi-cycle constraints or Timing Ignore constraints. 4) Telling the tool to work harder, because the solution is there... 5) Recognizing that you just can't get there from here, and accepting lower peformance.

I try to avoid #5 by identifying critical paths early in the design process; I like to have some realistic expectation of success when I sign up to do something.

Nevertheless, there frequently arise cases where "sometimes it meets timing easily, sometimes it doesn't meet it at all." I.e., after minor design changes, timing closure may fail miserably. Usually, I end up asking myself, "How did the tool manage to do such a lousy job?" By inspecting the timing report, I can see whether the problem is likely too many levels of logic, or just plain lousy mapping and placement, where the routing process just can't make meet timing. (I have seen this happen many, many times over the last 10+ years.)

When I look at the [failing] timing report, I try to find answers to a few key questions (not necessarily in any order):

1) Do the failures have something in common? E.g, there might by 165,000 nets failing timing, but the worst 20 (or 7,000, or...) are all part of the same bus. The routing tool will often stop optimizing as it focuses all of its attention on the worst ones, making the problem seem worse than it really is. 2) Are there outlandishly long routing delays between logic elements? This is often indicative of poor placement, or not using preferred routing resources, such as between pins, BUFGs, and DCMs. 3) In conjuction with the delay report, are the delays on a net roughly matched for all nodes, or are some way off base? This kind of information gives a clue as to what you might see if you open the routed design with the FPGA Editor. 4) Are the failures real? I have often had control path failures because I had not initially used appropriate mutli-cycle constraints. (Of course, sometimes I had to change the design to force them to be multi-cycle. Give and take.)

As to examples, the ones that mean the most to you will be the ones for your design.... If you are overwhelmed with what you have at the moment, create a tiny design, over-constraint it (say, 2 GHz?), and try to make sense of the report. (Or, just have the timing tool report all paths in detail, not just the failing paths.)

JTW