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.

Q. I know what module is causing timing issues... how can I just get timing data on 1 module instead of building the entire bitfile?

Start a new project in ISE with your module. The Timing Analyzer is available in the Tools file menu, or you can just synthesize your module; the console gives a rough idea about the module's timing and max frequency (should be 150 MHz or more).

Other Advice

Reset, Set, Enable for Flip Flops

A world about flip-flops... the distributed flip-flops contain their own Reset, Set, and Enable signals, but have priority in that order (Reset > Set > Enable). If assigning data to flip-flops, try using this priority in your statements in order to use less logic. If your logic is not in this order, you may end up using extra LUTs.

always @ (posedge clk) begin
if (reset)
  d <= 0;
else if (set)
  d <= 1;
else if (enable)
  d <= YOUR COMBO LOGIC;
end

Register Rebalancing

In synchronous designs, Xilinx XST can move logic forward or backward a register stage in order to balance the amount of work done in each register stage (thus improving timing). The side affects include radical changes to the structure of the design and an increase the synthesis run time. Modules with the Keep Heirarchy constraint will not rebalance registers.

To enable register rebalancing, you need to edit the template.xst file (/opt/convey/pdk/latest/phys/template.xst). If you don't have access, you can edit your project's copy of the template: phys/cae_fpga.xst by changing register_rebalancing to YES. Warning: After running make clean and make, the original template will replace any user edits to the cae_fpga.xst file.