Using the Timing Analyzer: Difference between revisions
No edit summary |
|||
Line 45: | Line 45: | ||
== 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? == | == 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 | 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 == | == Other Advice == |
Revision as of 20:03, 29 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.
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
A world about flip-flops... the distributed flip-flops contain their own Reset, Set, and Enable signals, but have that priority. 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