By: Richard Wilson

1st December 2014

     When your FPGA design fails to meet timing performance objectives, the cause may not be obvious. The solution lies not only in the FPGA implementation tools’ talent in optimizing the design to meet timing, but also in the designer’s ability to specify goals upfront and diagnose and isolate timing problems downstream. Designers now have access to certain tips and tricks that will help you set up clocks; correctly set timing constraints using tools like Synopsys Synplify Premier; and then tune parameters to meet the performance goals of your Xilinx FPGA design. There are multiple angles of attack, including:

• Better design setup, such as complete and accurate timing constraints and clock specifications.
• Time saving design techniques such as careful RTL coding for better performance results and grouping together the parts of the design that pose the greatest performance challenge, to reduce iteration run times when you later tune the design.
• Correlation of synthesis and place and route timing to deliver better timing quality of results (QoR) and timing closure.

Let’s take a closer look at some of these techniques in all three categories, and examine how to use them to achieve your timing goals.

Step 1: Better Design Setup

     The biggest bang for your buck will come from specifying correct and complete design constraints. The constraints communicate your design intent and the design’s performance goals to the synthesis tool. Once the design has been synthesised, these constraints and the critical path information will automatically be forward annotated to the Vivado Design Suite place and route (P&R) tools to further ensure that timing will be met. The synthesis tool can assist you with the challenging task of setting up pre-synthesis constraints. On your to-do list will be:

1. Identify clocks.
2. Identify and create clock groupings and clock relationships.
3. Constrain clocks.
4. Constrain design inputs and outputs.
5. Define multicycle paths and false paths.

     You will want to check that you have adequately and completely constrained your design without having overconstrained it. Overconstraining will result in longer run times and potentially, the reporting of false critical paths. Be sure to specify multicycle and false paths, and to set constraints on derived clocks (define_path_delay, define_false_path).



     Since constraints setup can be daunting, the synthesis software can help by providing an initial constraints template with basic constraints and syntax that can act as a starting point. For example, in the Synplify synthesis software, run the TCL utility to create an initial FDC file for a specific design: TCL: create_fdc_template Figure 1 shows an example of the constraints (.fdc) file that this process will generate. In this example, you can see that key items, such as declaring clocks, clock group (relationship between clocks) and input/output delays, have been taken care of.

Best practices for constraints setup in Vivado Design Suite flows When setting up constraints in Vivado Design Suite flows, be sure to do the following:

• Define all primary clocks on input ports or nets connected to input ports.
• Define clocks on the black box output pins.
• Define generated clocks on nets.
• Don’t define gated clocks.
• Provide correct clock constraints: Don’t overconstrain, and be sure to place unrelated (aka asynchronous) clocks in separate clock groups.
• Define timing exceptions such as false paths and multicycle paths.

Hint: In Vivado Design Suite, clock constraints should be applied as close to the source clock as possible, not on the BUFG, as was the case in Xilinx ISE Design Suite flows.

Ensuring that your constraints are correct We recommend four constraints verification techniques during the design setup phase. To give you an idea of the types of constraints checks that are worthwhile, let’s look at the checks that Synplify software performs. First run a “syntax check”—that is, a quick check of constraints, including their embedded “get_XX” and “all_XX” commands, to uncover and clean up any constraint syntax errors. The errors will appear in a log file that can be hyperlinked back to the error manual that explains the error and suggests a fix. Use the Tcl command check_fdc_query. Second, run a “synthesis check” to detect hardware related errors such as incorrectly coded flip flops. These errors are reported in a separate log file.

set_option –fast_synthesis 1

The synthesis compiler will create a synthesis report clock summary with information on inferred clocks that you can use for identifying, defining and constraining clocks. Fourth, run a full “constraints check.” This check looks for constraint setup issues with clock relationships, unconstrained start/end points, nonlocked I/Os and I/Os with no constraints.

A full constraints check will also look for the correct application of constraints and instance names. For example, it will flag timing constraints applied to non existent or invalid types of arguments and objects. The tool then generates a detailed explanatory report of inapplicable constraints and the instances not found so that the constraints file can be corrected. Synplify synthesis tools will run these kinds of checks automatically during the synthesis premap stage, or you can run the constraints check at the beginning of synthesis using the following TCL command: TCL: project -run constraint_check Running these basic types of checks identifies possible errors early in the synthesis cycle and improves the quality of results (Figure 2). Once synthesis has been run, be sure to analyze the post synthesis timing report, as it can provide important information. For example, when using Synplify software, a “System Clock” under the starting clock section of the timing report indicates that some of your I/Os may not be constrained. The interface information in this report will confirm whether or not this is the case.

Step 2: RTL coding styles and critical path tuning

To converge on better timing, we recommend that you use certain coding styles for finite state machines, RAMS, math/DSP functions, clock trees and shift registers. The result will be improved timing QoR, because the synthesis tool is better able to infer an implementation using FPGA primitive building blocks.

For finite state machines

• For Xilinx flows, use a synchronous reset to set hardware to a valid state after power up, or reset hardware during operation.


• Separate the sequential blocks from combinational always blocks.


• Assign a next state variable for all possible (present) states.

---

For Block RAMs:

• Code synchronous RAMs wherever possible since these will generally run at higher clock frequencies.
• Place RAM code in a separate module for easier debug at the netlist level.
• Before deciding to use a RAM with a specific reset condition, dual port or byte enabled RAMs, or asymmetric RAMS, look at the recommended coding style and check whether inference is supported. If not, the netlist may end up creating more control logic.
• Don’t read from the same address that you write to in the same clock cycle.
• When all else fails, use an attribute (syn_ramstyle for Synplify software) to force implementation of small RAMs into registers, freeing up RAM resources for use in more timing critical or larger RAMs.

For DSP Blocks:
You can use these primitives to implement filters and mathematical functions such as counters, adders, multipliers, subtractors and the like.

• Place DSP code in a separate module for easier debug at the netlist level.
• When all else fails, use an attribute (syn_ dspstyle for Synplify in Vivado Design Suite flows) to force implementation.

For SRLs you can pack shift registers into a select_SRL Xilinx SRL primitive or implement them in registers.

• Packing occurs automatically. For shift register chains, Synplify software will always leave the last register in the chain out of the packed select_srl in order to optimise timing QoR.
• When all else fails, use the syn_srl- style attribute to control how your SRLs are implemented.

For Clock Trees:

• Since these will not automatically be inferred during synthesis, it is recommended that you instantiate phase locked loops (PLLs), clock generators or clock muxes in your RTL.
• The timing constraints on the input clock of the PLL will automatically generate derived clock constraints on the PLL output pins.

     To better review clock constraints, examine them in a schematic viewer. For example, Synplify’s HDL Analyst tool can run a filter on the clock tree that lets you observe and debug clock trees and clock constraints (Figure 3).

---

Using Modularity to Improve Critical Path Performance



     Certain parts of the design may be more timing critical than others, and you will need to tune and incrementally improve those that are not performing. One of the techniques that you can apply to allow quicker tuning at the RTL and netlist phases involves isolating critical paths inside a single block or subproject that you can then iterate on incrementally to improve it. In addition, you can force the Vivado place and route tools to place the elements in close proximity to further ensure timing QoR.

Capabilities at your disposal during synthesis that allow for this modularity include:

• Prior to synthesis, specify an RTL partition (in Synplify software, this would be called a “compile point”) or create a hierarchical subproject.
• Post synthesis, isolate (export) as a subproject just that portion of the design that is not performing using a hierarchical program management flow. Iterate, fix and merge back the results.
• Have the synthesis software communicate to the Vivado place and route tool that it is to place the critical path on the same die of a multi SLR device such as the Virtex-7 2000T FPGA to avoid cross SLR delays.

---

Step 3: Gaining final timing closure

     General timing can be reported post synthesis and after placement and routing (Figure 4). For example, Synplify software allows you to report upon specific parts of the design of interest using a TCL command (report_timing). To improve timing QoR further, we recommend that you correlate post synthesis and post P&R timing results, specifically the slack margins for given start points and endpoints on timing critical paths. In Synplify Premier synthesis software, for example, you can display the post synthesis and P&R timing reports side-by-side to read the timing results. The correlation tool does a side by side comparison of the status of end points, start points and required periods. Paths are reported against the end clock. Paths for which pre and post P&R timing do not correlate well to within your specified “slack margin” criteria will be flagged as “correlation mis-matches” so that you can take action on them. A typical action would be to specify so called “route” constraints to the synthesis tool that tighten timing path constraints only during the synthesis phase.

Here’s an example:
FDC Constraints input file to synthesis: set_clock_route_delay {c:clka} 1.4 These constraints make synthesis “work harder” to meet timing performance on those paths, resulting in better correlation and QoR.



     The nice thing about the timing correlation capability is that you can drill down to view the exact paths that are causing problems, for example, changing the number of paths that you want to be displayed per endpoint. You can search for specific clocks or instances of interest and have their timing paths displayed. Clocks are also compared and displayed to further assist in timing correlation (see Figure 5).

     As you can see, there are certain steps you need to take in order to achieve better timing performance in a reasonable amount of time in your Vivado Design Suite flow. The methodology we have outlined will intercept clock and constraints setup issues early, while also offering a variety of techniques to tune and correlate timing in your design and its RTL to get fast timing closure.Writers are Angela Sutton, staff product marketing manager and Paul Owens, corporate applications engineer at FPGA Synopsis

Original Source: https://www.electronicsweekly.com/news/design/eda-and-ip/fpga-design-timing-everything-says-synopsys-2014-12/#sthash.xmqDn6vD.dpuf