Creating Synthesis Constraints - 2023.2 English

UltraFast Design Methodology Guide for FPGAs and SoCs (UG949)

Document ID
Release Date
2023.2 English

Synthesis takes the RTL description of the design and transforms it into an optimized technology mapped netlist by using timing-driven algorithms. The quality of the results is affected by the quality of the RTL code and the constraints provided. At this point of the compilation flow, the net delay modeling is approximate and does not reflect placement constraints or complex effects such as congestion. The main objective is to obtain a netlist which meets timing, or fails by a small amount, with realistic and simple constraints.

The synthesis engine accepts all XDC commands, but only some have a real effect:

  • Timing constraints related to setup/recovery analysis influence the QoR:
    • create_clock / create_generated_clock
    • set_input_delay / set_output_delay
    • set_clock_groups / set_false_path / set_max_delay / set_multicycle_path
  • Timing constraints related to hold and removal analysis are ignored during synthesis:
    • set_min_delay / set_false_path -hold / set_multicycle_path -hold
  • RTL attributes forces decisions made by the mapping and optimization algorithms. Following are a few examples:
    • FULL_CASE / PARALLEL_CASE (Verilog RTL only)
    Note: The same attribute can also be set as a property from an XDC file. Using XDC-based constraints is convenient for influencing the synthesis results only in some cases without changing the RTL.
  • Physical constraints are ignored (LOC, BEL, Pblocks)

Synthesis constraints must use names from the elaborated netlist, preferably ports and sequential cells. During elaboration, some RTL signals can disappear and it is not possible to attach XDC constraints to them. In addition, due to the various optimizations after elaboration, nets or logical cells are merged into the various technology primitives such as LUTs or DSP blocks. To know the elaborated names of your design objects, click Open Elaborated Design in the Flow Navigator and browse to the hierarchy of interest.

Some registers are absorbed into RAM blocks and some levels of the hierarchy can disappear to allow cross-boundary optimizations.

Any elaborated netlist object or level of hierarchy can be preserved by using a DONT_TOUCH, KEEP, KEEP_HIERARCHY, or MARK_DEBUG constraint, at the risk of degrading timing or area QoR.

Finally, some constraints can conflict and cannot be respected by synthesis. For example, if a MAX_FANOUT attribute is set on a net that crosses multiple levels of hierarchy, and some hierarchies are preserved with DONT_TOUCH, the fanout optimization will be limited or fully prevented.

Important: Unlike during implementation, RTL netlist objects that are used for defining timing constraints can be optimized away by synthesis to allow better area QoR. This is usually not a problem as long as the constraints are updated and validated for implementation. But if needed, you can preserve any object by using the KEEP constraint so that the constraints will apply during both synthesis and implementation.

After synthesis is complete, AMD recommends that you review the timing and utilization reports to validate that the netlist quality meets the application requirements and can be used for implementation.