Using the Timing Analyzer: Difference between revisions

From Cpre584
Jump to navigation Jump to search
New page: 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...
 
Line 29: Line 29:
  </nowiki>
  </nowiki>


== How do I know what's Causing the Timing Issue ==
== 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:
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:

Revision as of 01:52, 1 November 2012

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.
 

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. I usually just click Ok (Design timing constraints) and wait a few minutes for the report to appear, but there are more features you can explore.

The report should list the critical path and it's setup/routing time. If it's near 5 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).