Using the Timing Analyzer

Xilinx's Timing Analyzer can be used to find fixed timing errors with your design. If you design "works perfectly in simulation, but not in hardware", and when you build a bitfile and the timing constraints are not met, you have a timing error that needs fixed.

Good designs won't have timing errors, and there are tricks to writing good HDL code that results in good timing.

Q. How do I know if my bitfile doesn't meet timing?

Check the Place and Route (phys/cae_fpga_routed.par) report in the phys folder or view the last few lines of the console output when building a bitfile. The timing results look something like this if you're failing to meet the timing constraints:

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   
----------------------------------------------------------------------------------------------------------
* TS_ae_top_io_pll_clkout1 = PERIOD TIMEGRP | SETUP       |    -2.893ns|     9.560ns|     743|      498468
   "ae_top_io_pll_clkout1" TS_CLK HIGH      | HOLD        |     0.000ns|            |       0|           0
      50%                                   |             |            |            |        |            
----------------------------------------------------------------------------------------------------------
  TS_ae_top_io_pll_clkout0 = PERIOD TIMEGRP | SETUP       |     0.023ns|     3.310ns|       0|           0
   "ae_top_io_pll_clkout0" TS_CLK / 2       | HOLD        |     0.000ns|            |       0|           0
     HIGH 50%                               |             |            |            |        |            
----------------------------------------------------------------------------------------------------------

...

1 constraint not met.
 

If you're failing one of the Convey timing constraints, you need to rework your design. Sometimes you need to run the timing analyzer to find timing issues.

Q. How do I know what's Causing the Timing Issue

If you're unsure of where the timing issue is, it makes sense to spend 10 minutes using the timing analyzer to find the longest critical paths in your design. Open the timing analyzer:

 $ timingan &

Open your project: File -> Open Design. Select the final routed design and constraint files from the phys directory (.ncd, .pcf, .ngd, .ucf) from the most recent bitfile you created (yes... you have to build the bitfile first).

Run the analysis. Timing -> Run Analysis, Timing -> Report -> Net Delays, or (my favorite) Timing -> Query.

The report should list the critical path and it's setup/routing time. If it's near 6.67 ns, you just barely missed timing; perhaps registering the output of one of your modules is all you need. Another way to meet timing is to break up the steps into pipeline stages (i.e. if some logic block takes 20 ns, breaking it up into a few pipeline stages should help). If a route has high fanout, you can register the signal to reduce the fanout into a tree.