Using the Timing Analyzer - Revision history

Cnel711: /* 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? */

2012-12-05T14:58:25Z

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?

← Older revision		Revision as of 14:58, 5 December 2012
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; the console gives~~ a ~~rough idea about~~ the ~~module's timing and max frequency (should be~~ 150 MHz ~~or more)~~.		Start a new project in ISE with your module. The Timing Analyzer is available in the Tools file menu. You should add a .ucf file containing the period constraint of 150 MHz:

			NET "clk" TNM_NET = "TN_CLK";
			TIMESPEC "TS_CLK" = PERIOD "TN_CLK" 6.667 ns HIGH 50 %;

			In this example, clk is the name of the net used as your clock signal.

	== Other Advice ==		== Other Advice ==

Cnel711 at 19:11, 4 December 2012

2012-12-04T19:11:25Z

← Older revision		Revision as of 19:11, 4 December 2012
Line 48:		Line 48:

	== Other Advice ==		== 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.		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.

Line 60:		Line 61:
	end		end
	</nowiki>		</nowiki>

			=== 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.

Cnel711: /* Other Advice */

2012-11-29T20:04:26Z

Other Advice

← Older revision		Revision as of 20:04, 29 November 2012
Line 48:		Line 48:

	== Other Advice ==		== 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.		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.

	<nowiki>		<nowiki>

Cnel711: /* 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? */

2012-11-29T20:03:03Z

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?

← Older revision		Revision as of 20:03, 29 November 2012
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 ~~to get~~ a rough idea about it's timing.		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 ==

Cnel711 at 16:01, 6 November 2012

2012-11-06T16:01:20Z

← Older revision		Revision as of 16:01, 6 November 2012
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.		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 to get a rough idea about it's timing.

			== 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.

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

Cnel711 at 18:46, 2 November 2012

2012-11-02T18:46:07Z

← Older revision		Revision as of 18:46, 2 November 2012
Line 42:		Line 42:

	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.		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.

Cnel711: /* Q. How do I know what's Causing the Timing Issue */

2012-11-01T21:03:02Z

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

← Older revision		Revision as of 21:03, 1 November 2012
Line 41:		Line 41:
	Run the analysis. Timing -> Run Analysis, Timing -> Report -> Net Delays, or (my favorite) Timing -> Query.		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 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).		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.

Cnel711: /* Q. How do I know what's Causing the Timing Issue */

2012-11-01T05:25:19Z

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

← Older revision		Revision as of 05:25, 1 November 2012
Line 39:		Line 39:
	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).		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 or Timing -> Report -> Net Delays.		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 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).		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).

Cnel711 at 05:11, 1 November 2012

2012-11-01T05:11:59Z

← Older revision		Revision as of 05:11, 1 November 2012
Line 28:		Line 28:
	1 constraint not met.		1 constraint not met.
	</nowiki>		</nowiki>

			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 ==		== Q. How do I know what's Causing the Timing Issue ==
Line 37:		Line 39:
	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).		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~~.		Run the analysis. Timing -> Run Analysis or Timing -> Report -> Net Delays.

	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).		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).

Cnel711: /* How do I know what's Causing the Timing Issue */

2012-11-01T01:52:37Z

How do I know what's Causing the Timing Issue

← Older revision		Revision as of 01:52, 1 November 2012
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: