See all versions

of this document

UltraFast Design
Methodology Guide for
Xilinx FPGAs and SoCs

UG949 (v2022.1) June 8, 2022

Xilinx is creating an environment where employees, customers, and

partners feel welcome and included. To that end, we’re removing non-
inclusive language from our products and related collateral. We’ve
launched an internal initiative to remove language that could exclude
people or reinforce historical biases, including terms embedded in our
software and IPs. You may still find examples of non-inclusive
language in our older products as we work to make these changes and
align with evolving industry standards. Follow this link for more
information.
Table of Contents
Chapter 1: Introduction............................................................................................. 4
About the UltraFast Design Methodology................................................................................4
Understanding UltraFast Design Methodology Concepts..................................................... 7
Using the Vivado Design Suite.................................................................................................11
Accessing Additional Documentation and Training..............................................................12

Chapter 2: Board and Device Planning............................................................. 13

PCB Layout Recommendations............................................................................................... 13
Device Power Aspects and System Dependencies................................................................19
Clock Resource Planning and Assignment.............................................................................22
I/O Planning Design Flows.......................................................................................................22
Designing with SSI Devices...................................................................................................... 28
Designing with HBM Devices................................................................................................... 35
Configuration.............................................................................................................................39

Chapter 3: Design Creation with RTL.................................................................41

Defining a Good RTL Design Hierarchy.................................................................................. 41
Working with Intellectual Property (IP).................................................................................. 45
RTL Coding Guidelines..............................................................................................................48
Clocking Guidelines...................................................................................................................86
Clock Domain Crossing...........................................................................................................138

Chapter 4: Design Constraints.............................................................................143

Organizing the Design Constraints for Compilation.......................................................... 143
Defining Timing Constraints.................................................................................................. 149
Defining Power and Thermal Constraints............................................................................183
Defining Physical Constraints................................................................................................ 184

Chapter 5: Design Implementation.................................................................. 185

Running Synthesis...................................................................................................................185
Moving Past Synthesis............................................................................................................ 193
Implementing the Design...................................................................................................... 198

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 2
 Chapter 6: Design Closure......................................................................................206
Timing Closure.........................................................................................................................207
Power Closure..........................................................................................................................295
Configuration and Debug...................................................................................................... 301

Appendix A: Additional Resources and Legal Notices........................... 311

Xilinx Resources.......................................................................................................................311
Solution Centers...................................................................................................................... 311
Documentation Navigator and Design Hubs...................................................................... 311
References................................................................................................................................312
Training Resources..................................................................................................................314
Revision History....................................................................................................................... 315
Please Read: Important Legal Notices................................................................................. 315

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 3
 Chapter 1: Introduction

Chapter 1

Introduction

About the UltraFast Design Methodology

The Xilinx® UltraFast™ design methodology is a set of best practices intended to help streamline
the design process for today's devices. The size and complexity of these designs require specific
steps and design tasks to ensure success at each stage of the design. Following these steps and
adhering to the best practices will help you achieve your desired design goals as quickly and
efficiently as possible.

• This guide, which describes the various design tasks, analysis and reporting features, and best
practices for design creation and closure.
• UltraFast Design Methodology Quick Reference Guide (UG1231), which highlights key design
methodology steps in an easy-to-use, double-sided card format.
• UltraFast Design Methodology Timing Closure Quick Reference Guide (UG1292), which covers
recommendations for closing timing, including running initial design checks, baselining the
design, and resolving timing violations.
• UltraFast Design Methodology Checklist (XTP301), which is available in the Xilinx
Documentation Navigator and as a standalone spreadsheet. You can use this checklist to
identify common mistakes and decision points throughout the design process.
• UltraFast Design Methodology System-Level Design Flow diagram representing the entire
Vivado® Design Suite design flow, which is available in the Xilinx Documentation Navigator.
You can click a design step in the diagram to open related documentation, collateral, and FAQs
to help get you started.

RECOMMENDED: In addition to these resources, Xilinx recommends the UltraFast Embedded Design
Methodology Guide (UG1046) when working with embedded designs and the Vitis HLS Methodology in
the Vitis HLS User Guide (UG1399) when developing complex systems using Vivado IP integrator with
C-based IP.

Xilinx provides the following resources to help you take advantage of the UltraFast design
methodology:

TIP: Xilinx also provides methodology-related design rule checks (DRCs) for each design stage, which are
available using the report_methodology Tcl command in the Vivado Design Suite.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 4
 Chapter 1: Introduction

Using This Guide

This guide provides a set of best practices that maximize productivity for both system integration
and design implementation. It includes high-level information, design guidelines, and design
decision trade-offs for the following topics:

• Chapter 2: Board and Device Planning: Covers decisions and design tasks that Xilinx
recommends accomplishing prior to design creation. These include I/O and clock planning,
PCB layout considerations, device capacity and throughput assessment, alternate device
definition, power estimation, and debugging.

• Chapter 3: Design Creation with RTL: Covers the best practices for RTL definition and IP
configuration and management.

• Chapter 4: Design Constraints: Provides recommendations for creating proper timing, power,
and physical constraints as well as specifying additional constraints, attributes, and other
elements used during synthesis and implementation.

• Chapter 5: Design Implementation: Covers the options available and best practices for
synthesizing and implementing the design.

• Chapter 6: Design Closure: Covers the various design analysis and implementation techniques
used to close timing on the design or to reduce power consumption. It also includes
considerations for adding debug logic to the design for hardware verification purposes.

This guide includes references to other documents such as the Vivado Design Suite User Guides,
Vivado Design Suite Tutorials, and Quick-Take Video Tutorials. This guide is not a replacement for
those documents. Xilinx still recommends referring to those documents for detailed information,
including descriptions of tool use and design methodology.

This information is designed for use with the Vivado Design Suite, but you can use most of the
conceptual information with the ISE® Design Suite as well.

Related Information

Additional Resources and Legal Notices

Using the UltraFast Design Methodology Checklist

To take full advantage of the UltraFast design methodology, use this guide with the UltraFast
Design Methodology Checklist (XTP301). The checklist is available from the Xilinx Documentation
Navigator or as a standalone spreadsheet.

The questions in the UltraFast Design Methodology Checklist highlight typical areas in which
design decisions are likely to have downstream impact and draw attention to issues that are
often overlooked or ignored. Each tab in the checklist:

• Targets a specific role within a typical design team.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 5
 Chapter 1: Introduction

• Includes common questions and recommended actions to take during each design flow step,
including project planning, board and device planning, IP and submodule design, and top-level
design closure.
• Includes a Documentation and Training section that lists resources related to the design flow
step.
• Provides links to content in this guide or other Xilinx documentation, which offer guidance on
addressing the design concerns raised by the questions.

VIDEO: For a demonstration of the checklist, see the Vivado Design Suite QuickTake Video: Introducing
the UltraFast Design Methodology Checklist.

Using the UltraFast Design Methodology DRCs

The Vivado Design Suite contains a set of methodology-related DRCs you can run using the
report_methodology Tcl command. This command has rules for each of the following design
stages:

• Before synthesis in the elaborated RTL design to validate RTL constructs

• After synthesis to validate the netlist and constraints
• After implementation to validate constraints and timing related concerns.

RECOMMENDED: For maximum effect, run the methodology DRCs at each design stage and address
Critical Warnings and Warnings prior to moving to the next stage.

For more information on the design methodology DRCs, see the report_methodology Tcl
command in the Vivado Design Suite Tcl Command Reference Guide (UG835).

Related Information

Running Report Methodology

Using the UltraFast Design Methodology System-

Level Design Flow Diagram
The following figure shows the various design steps and features included in the Vivado Design
Suite. From the Xilinx Documentation Navigator Design Hub View, you can access an interactive
version of this graphic in which you can click each step for links to related resources.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 6
 Chapter 1: Introduction

Figure 1: System-Level Design Flow for FPGAs and SoCs

System Design Entry Model-Based Design with

Software Development
C-Based Design MATLAB® and Simulink® Software
with High-Level
Synthesis Vitis™ Model Composer

Configuring Xilinx® and IP Packager – IP Integrator Development Software

Third-Party IP and Processor OS
Configuring IP
Embedded Processor Design
Subsystems
RTL
Development

Implementation
Logic Simulation

Dynamic Function Assign Logical and Physical Constraints

eXchange

Logic Synthesis

Implementation

Timing Closure and Design Analysis

Generate Bitstream, Programming, and Debug

Export to Vitis Software

Processor Boot and Debug
Development Platform
Hardware Bring-Up and Validation
X15150-063021

Understanding UltraFast Design Methodology

Concepts
It is important to take the correct approach from the start of your design and to pay attention to
design goals from the early stages, including RTL, clock, pin, and PCB planning. Properly defining
and validating the design at each design stage helps alleviate timing closure, routing closure, and
power usage issues during subsequent stages of implementation.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 7
 Chapter 1: Introduction

Creating and Implementing a Hardware Design

After planning your device I/O, planning how to lay out your PCB, and deciding on your use
model, you can begin creating your design. Design creation includes:

• Planning the hierarchy of your design

• Identifying the IP cores to use and customize in your design
• Instantiating RTL modules that are needed for special interconnect or functionality that is not
available in the IP catalog
• Creating timing, power, and physical constraints
• Specifying additional constraints, attributes, and other elements used during synthesis and
implementation

When creating your design, the main points to consider include:

• Achieving the desired functionality

• Operating at the desired frequency
• Operating with the desired degree of reliability
• Fitting within the silicon resource and power budget

Decisions made at this stage affect the end product. A wrong decision at this point can result in
problems at a later stage, causing issues throughout the entire design cycle. Spending time early
in the process to carefully plan your design helps to ensure that you meet your design goals and
minimize debug time in the lab.

Maximizing Impact Early in the Development Cycle

As shown in the following figure, early stages in the design flow (C, C++, and RTL synthesis) have
a much higher impact on design performance, density, and power than the later implementation
stages. Therefore, if the design does not meet timing goals, Xilinx recommends that you revisit
the synthesis stage, including HDL and constraints, rather than iterating for a solution in the
implementation stages only.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 8
 Chapter 1: Introduction

Figure 2: Impact of Design Changes Throughout the Flow

Impact of change on
performance

HLS
(C, C++) 1000x

RTL 10x
Synthesis

Placement and 1.2x

Optimization

Routing 1.1x

X13423-081020

Validating at Each Design Stage

The UltraFast design methodology emphasizes the importance of monitoring design budgets,
such as area, power, latency, and timing, and correcting the design from early stages as follows:

• Create optimal RTL constructs with Xilinx templates, and validate your RTL with methodology
DRCs prior to synthesis, after elaboration.
Because the Vivado tools use timing-driven algorithms throughout, the design must be
properly constrained from the beginning of the design flow.
• Perform timing analysis after synthesis.
To specify correct timing, you must analyze the relationship between each master clock and
related generated clocks in the design. In the Vivado tools, each clock interaction is timed
unless explicitly declared as an asynchronous or false path.
• Meet timing using the right constraints before proceeding to the next design stage.
You can accelerate overall timing and implementation convergence by following this
recommendation and by using the interactive analysis environment of the Vivado Design
Suite.

TIP: You can achieve further acceleration by combining these recommendations with the HDL design
guidelines in this guide.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 9
 Chapter 1: Introduction

The following figure shows this recommended design methodology.

Figure 3: RTL Design Methodology for Rapid Convergence

Run Synthesis
Review options & HDL code

report_clock_networks
-> create_clock / create_generated_clock
report_clock_interaction
Cross-probe
-> set_clock_groups / set_false_path Define & Refine Instances in critical path
check_timing Constraints In Netlist view and
-> I/O delays
Elaborated view schematics
report_timing_summary
-> Timing exceptions

Timing Acceptable?
N

Place & Route

X13422

Synthesis is considered complete when the design goals are met with a positive margin or a
relatively small negative timing margin. For example, if post-synthesis timing is not met,
placement and routing results are not likely to meet timing. However, you can still go ahead with
the rest of the flow even if timing is not met. Implementation tools might be able to close timing
if they can allocate the best resources to the failing paths. In addition, proceeding with the flow
provides a more accurate understanding of the negative slack magnitude, which helps you
determine how much you need to improve the post-synthesis worst negative slack (WNS). You
can use this information when you return to the synthesis stage with improvements to HDL and
constraints.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 10
 Chapter 1: Introduction

Taking Advantage of Rapid Validation

This guide also introduces the concept of rapid validation of specific aspects of the system
architecture and micro-architecture as follows:

• In the context of system design, the I/O bandwidth is validated in-system, before
implementing the entire design. Validating I/O bandwidth can highlight the need to revise
system architecture and interface choices before finalizing on I/Os.
• As part of design implementation, baselining is used to write the simplest set of constraints,
which can identify internal device timing challenges. Baselining is a process used to identify
the need to revise RTL micro-architecture choices before moving to the implementation
phase.

Related Information

Interface Bandwidth Validation

Baselining the Design

Using the Vivado Design Suite

The Vivado Design Suite has a flexible use model to accommodate various development flows
and different types of designs. For detailed information on how to use the features within the
Vivado Design Suite, see the Vivado Design Suite User Guide: Design Flows Overview (UG892) and
other Vivado Design Suite documentation.

Managing Vivado Design Suite Sources with a

Revision Control System
Most design teams manage their design sources and results with a commercially available
revision control system. The Vivado Design Suite allows various use models for managing design
and IP data. For more information on using the Vivado tools with a revision control system, see
this link in the Vivado Design Suite User Guide: Design Flows Overview (UG892).

Upgrading to New Vivado Design Suite Releases

New releases of the Vivado Design Suite often contain updates to Xilinx IP. Carefully consider
whether you want to upgrade your IP, because upgrading can result in design changes. In
addition, you must follow specific rules when using IP configured with previous releases going
forward. For more information, see this link in the Vivado Design Suite User Guide: Designing with
IP (UG896).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 11
 Chapter 1: Introduction

Accessing Additional Documentation and

Training
This guide supplements the information in the Vivado Design Suite documentation, including
user guides, reference guides, tutorials, and QuickTake videos. The Xilinx Documentation
Navigator provides access to the Vivado Design Suite documentation and support resources,
which you can filter and search to find information. To open the Xilinx Documentation Navigator
(DocNav):

• From the Vivado IDE, select Help → Documentation and Tutorials.

• On Windows, select Start → All Programs → Xilinx Design Tools → DocNav.
• At the Linux command prompt, enter: docnav

Xilinx Design Hubs provide links to documentation organized by design tasks and other topics,
which you can use to learn key concepts and address frequently asked questions. To access the
Design Hubs:

• In the Xilinx Documentation Navigator, click the Design Hubs View tab.
• On the Xilinx website, see the Design Hubs page.

TIP: For quick access to information on different parts of the Vivado IDE, click the Quick Help button
in the window or dialog box. For detailed information on Tcl commands, enter the command
followed by -help in the Tcl Console.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 12
 Chapter 2: Board and Device Planning

Chapter 2

Board and Device Planning

Properly planning the device orientation on the board and assigning signals to specific pins can
lead to dramatic improvements in overall system performance, power consumption, thermal
performance, and design cycle times. Visualizing how the device interacts physically and logically
with the printed circuit board (PCB) enables you to streamline the data flow through the device.

Failing to properly plan the I/O configuration can lead to decreased system performance and
longer design closure times. Xilinx highly recommends that you consider I/O planning in
conjunction with board planning.

For more information, see the following resources:

• Vivado Design Suite User Guide: I/O and Clock Planning (UG899)
• Vivado Design Suite QuickTake Video: I/O Planning Overview

PCB Layout Recommendations

The layout of the device on the board relative to other components with which it interacts can
significantly impact the I/O planning.

Aligning with Physical Components on the PCB

The orientation of the device on the PCB should first be established. Consider the location of
fixed PCB components, as well as internal device resources. For example, aligning the GT
interfaces on the device package to be as close to the components with which they interface on
the PCB will lead to shorter PCB trace lengths and fewer PCB vias.

A sketch of the PCB including the critical interfaces can often help determine the best
orientation for the device on the PCB, as well as placement of the PCB components. After
completion, the rest of the device I/O interface can be planned.

High-speed interfaces such as memory can benefit from having very short and direct connections
with the PCB components with which they interface. These PCB traces often have to be
matched length and not use PCB vias, if possible. In these cases, the package pins closest to the
edge of the device are preferred in order to keep the connections short and to avoid routing out
of the large matrix of BGA pins.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 13
 Chapter 2: Board and Device Planning

The I/O Planning view layout in the Vivado® IDE is useful in this stage for visualizing I/O
connectivity relative to the physical device dimensions, showing both top-side and bottom-side
views.

THERMAL TIP: For thermally-challenged designs, be aware of device placement in relation to other high-
power components to minimize thermal coupling and maximize airflow. Avoid placement where the device
is positioned in the exhaust of another high-power component or where board heating might negatively
impact the operating temperature. Xilinx recommends thermal simulation to understand how the
placement and environmental conditions can affect the junction temperature of the device.

The following figure shows the I/O Planning view layout.

Figure 4: I/O Planning View Layout

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 14
 Chapter 2: Board and Device Planning

Power Distribution System

Board designers are faced with a unique task when designing a power distribution system (PDS)
for a Xilinx® device. Most other large, dense integrated circuits (such as large microprocessors)
come with very specific bypass capacitor requirements. Because these devices are designed only
to implement specific tasks in their hardened silicon architecture, their power supply demands
are fixed and fluctuate typically within a certain range.

Xilinx devices do not share this property. Devices can implement an almost infinite number of
applications at user-determined frequencies, and in multiple clock domains.

For this reason, it is critical that you understand the power requirements of the design, which you
can assess by completing a power estimation using the Xilinx Power Estimator (XPE). Also refer
to the PCB Design Guide for your device to fully understand the PDS placement and generic
decoupling requirements prior to a power estimation.

Key factors to consider during PDS design include:

• Selecting the right voltage regulators to meet the noise and current requirements based on
power estimation.
Note: To enable and simplify your power design, Xilinx partners with key power vendors to design,
build, document, and test reference designs that meet all power requirements. For more information,
see the Power Delivery Solutions tab on the Power page of the Xilinx website.

• Consolidating power. For supported consolidation options in UltraScale™ devices, see this link
in the UltraScale Architecture PCB Design User Guide (UG583).

POWER TIP: Xilinx recommends adding a shunt resistor to allow the power on each rail to be
monitored. Alternatively, you can use a PMBus-enabled regulator or current monitoring integrated
circuit (IC).

• Setting up the Sysmon power supply (VCCAUX_SMON).

• Running power distribution network (PDN) simulation. For UltraScale devices, use the
recommended number of decoupling capacitors listed in the UltraScale Architecture PCB Design
User Guide (UG583), which are based on the assumptions listed in the guide. If the
assumptions differ for your design, simulate your design to determine whether more or less
decoupling is required. Running PDN simulations can help to confirm the exact amount of
decoupling capacitors required to guarantee power supplies that are within the recommended
operating range.
Note: See the 7 Series FPGAs PCB Design Guide (UG483), UltraScale Architecture PCB Design User Guide
(UG583), or Zynq-7000 SoC PCB Design Guide (UG933) to find the details for your device.

For more information on PDN simulation, see Simulating FPGA Power Integrity Using S-Parameter
Models (WP411).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 15
 Chapter 2: Board and Device Planning

POWER TIP: Xilinx recommends simulating your power supply design using the SIMPLIS simulator in
SIMetrix/SIMPLIS to ensure your design is within the Xilinx recommended operating conditions. The
majority of power vendors provide a limited version of SIMPLIS and supply the models to allow you to run
this simulation. SIMPLIS is a third-party software used for transient and AC analysis of voltage regulators.
For more information about simulating your power delivery, contact SIMPLIS or your preferred power
delivery vendor.

POWER TIP: The Vivado tools report_power command can analyze power on a per regulator or
voltage regulator module (VRM) basis to ensure the required current on each rail does not exceed the
intended power delivery system.

Related Information

Power Closure

Thermal Solution Considerations

When considering the power estimation of a design, understanding the efficiency of the thermal
solution is crucial. The lower the junction temperature, the lower the static power of a design.

Xilinx recommends using lidless packaging if it is available for your device. Lidless packaging
offers a more efficient thermal solution and allows direct contact with the heat source, removing
a thermal interface material (TIM) layer. Xilinx lidded and lidless parts have the same handling and
manufacturing requirements. The following figure compares the heat sink application for a lidded
and lidless device.

THERMAL TIP: Xilinx recommends between 20 and 50 pound-force per square inch (PSI) for the heat
sink, which ensures the smallest bond line thickness (BLT), and recommends using 4-hole mounting to
ensure even pressure for both lidded and lidless devices. For more information on lidless techniques, see
Mechanical and Thermal Design Guidelines for Lidless Flip-Chip Packages (XAPP1301).

Figure 5: Heat Sink Example

Heat Sink

TIM2 TIM 1.5

LID Stiffener Ring

TIM 1
DIE

X23524-112719

Xilinx also recommends thermal simulation to ensure that there is adequate margin and accurate
power estimation. In the XPE, you have control over the following thermal settings:

• Junction Temperature Tj: You can override this setting to a desired junction temperature to
match your thermal simulation. If you are not running a thermal simulation, set the junction
temperature to the worst case.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 16
 Chapter 2: Board and Device Planning

• Effective ΘJA: Describes the thermal efficiency of a thermal solution, the units are measured
in degrees Celsius per watt (°C/W). For example, an ΘJA of 2.1°C/W means that for every
watt dissipated in the device, the junction temperature increases by 2.1°C. For a 10W design,
the increase is 21°C above the ambient temperature.

Note: You can obtain the ΘJA through thermal simulation using the following formula:

ΘJa = (Tj – Ta)/ PowerDissipated

The following figure shows the recommended flow for thermal validation.

Figure 6: Recommended Thermal Validation Flow

Power
Estimation

Re-Evaluate Design or
Thermal Solution

Thermal Simulation
Tj < Tj max
Y N
X23525-111319

After the junction temperature is within specification and sufficient margin is considered, the
thermal solution is considered effective.

THERMAL TIP: Add the results of the power estimation and thermal simulation to the Vivado design
constraints. You can use the following XDC constraints, which you can export from the XPE, as described
in the Xilinx Power Estimator User Guide (UG440):

# Standard Constraints:
set_operating_conditions -process Maximum
set_operating_conditions -design_power_budget <value>
#If thermal simulation completed
set_operating_conditions -ambient_temp <value>
set_operating_conditions -thetaja <value>
#Else if no thermal simulation completed
set_operating_conditions -junction_temp <value>

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 17
 Chapter 2: Board and Device Planning

PCB Design Considerations

The PCB should be designed considering the fastest signal interfacing with the device. These
high-speed signals are extremely sensitive to trace geometry, vias, loss, and crosstalk. These
aspects become even more prominent for multi-layer PCBs. For high-speed interfaces perform a
signal integrity simulation. A board redesign with improved PCB material or altered trace
geometries might be necessary to obtain the desired performance.

Xilinx recommends following these steps when designing your PCB:

1. Review the following device documentation:

• PCB Design Guide for your device.
• Board design guidelines in the transceiver user guide for your device.
2. Review memory IP and PCIe® design guidelines in the IP product guides.
3. Use the Vivado tools to validate your I/O planning:
• Run simultaneous switching noise (SSN) analysis.
• Run built-in DRCs.
• Export I/O buffer information specification (IBIS) models.
4. Run signal integrity analysis as follows:
• For gigabit transceivers (GTs), run Spice or IBIS-AMI simulations using channel parameters.
• For lower performance interfaces, run IBIS simulation to check for issues with overshoot
or undershoot.
5. Use the Xilinx Power Estimator (XPE) spreadsheet tool (download at www.xilinx.com/power)
with Process set to Maximum to generate an early estimate of the power consumption for
the design.
6. Complete and adhere to the schematic checklist for your device.
Note: See the 7 Series Schematic Review Recommendations (XMP277), Kintex UltraScale and Virtex
UltraScale FPGAs Schematic Review Checklist (XTP344), or UltraScale+ FPGAs and Zynq Ultrascale+
Devices Schematic Review Checklist (XTP427).

7. Manually add XDC operating condition constraints to your XDC file for the Vivado tools. Use
the XPE to generate a Xilinx design constraints (XDC) file, and import this file into the
corresponding Vivado project. The XPE environment settings are translated to XDC
constraints. The estimated total on-chip power becomes the design power budget for Vivado
power analysis. For more information, see the Vivado Design Suite User Guide: Power Analysis
and Optimization (UG907).

Related Information

Other Xilinx Documentation

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 18
 Chapter 2: Board and Device Planning

Device Power Aspects and System

Dependencies
When planning the PCB, you must take power into consideration:

• The device and the user design create system power supply and heat dissipation
requirements.
• Power supplies must be able to meet maximum power requirements and the device must
remain within the recommended voltage and temperature operating conditions during
operation. Power estimation and thermal modeling are required to ensure that the device
stays within these limits.
• Plan for the consolidation of power rails and their impact on power domain switching.
• Although consolidation is possible, Xilinx recommends using full power management to give
maximum flexibility where possible.

For these reasons, you must understand the power and cooling requirements of the device.
These must be designed on the board.

POWER TIP: For a list of Xilinx partners and Xilinx-approved power delivery reference designs, see the
Power page on the Xilinx website.

Power Supply Paths on Devices

Multiple power supplies are required to power a device and must be provided in a specific
sequence. Consider the use of power monitoring or sequencing circuitry to provide the correct
power-on sequence to the device as well as any additional active components on the board.
More complex environments might benefit from the use of a microcontroller or system and
power management bus such as SMBUS or PMBUS to control the power and reset process.
Specific details regarding on/off sequencing can be found in the device data sheet. For more
information on supply consolidation and topologies, see the 7 Series FPGAs PCB Design Guide
(UG483), UltraScale Architecture PCB Design User Guide (UG583), or Zynq-7000 SoC PCB Design
Guide (UG933) depending on your device.

The separate sources provide the required power for the different device resources. This allows
different resources to work at different voltage levels for increased performance or signal
strength, while preserving a high immunity to noise and parasitic effects.

Power Types
A device goes through several power phases from power up to power down with varying power
requirements.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 19
 Chapter 2: Board and Device Planning

Power-On
Power-on power is the transient spike current that occurs when power is first applied to the
device. This current varies for each voltage supply and depends on the device construction, the
ability of the power supply source to ramp up to the nominal voltage, and the device operating
conditions, such as temperature and sequencing between the different supplies.

Spike currents are not a concern in modern device architectures when the proper power-on
sequencing guidelines are followed.

Startup Power
Startup power is the power required during the initial bring-up and configuration of the device.
This power generally occurs over a very short period of time and thus is not a concern for
thermal dissipation. However, current requirements must still be met. In most cases, the active
current of an operating design will be higher and thus no changes are necessary. However, for
lower-power designs where active current can be low, a higher current requirement during this
time might be necessary. XPE can be used to understand this requirement. When Process is set
to Maximum, the current requirement for each voltage rail will be specified to either the
operating current or the startup current, whichever is higher. XPE will display the current value in
blue if the startup current is the higher value.

Static Power
Design static power (also called standby power) is the power supplied when the device is
configured with your design and no activity is applied externally or generated internally. Static
power represents the minimum continuous power that the supplies must provide while the
design operates.

Static power is a function of junction temperature. Therefore, ensuring the ambient and thermal
solution parameters are correctly modeled is critical to allow the power estimation tools accuracy
report the static power.

Related Information

Recommended Power Constraints

Dynamic Power
Dynamic power is the power required when the device is running your application and
undergoing switching activity as clocks and datapaths toggle between High and Low logic values.
Dynamic power is calculated based on the average switching activity of device circuits over a
period of time. Total power includes static power plus dynamic power.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 20
 Chapter 2: Board and Device Planning

Factors Impacting Power

Environmental Factors Impacting Power
In addition to the design itself, environmental factors affect power. These factors influence the
voltage and the junction temperature of the device, which impacts the power dissipation. For
more information, see this link in the Vivado Design Suite User Guide: Power Analysis and
Optimization (UG907).

THERMAL TIP: The -2LI and -2LE UltraScale+™ devices allow a temperature excursion of up to 110°C for
a defined period of time, which enables a reduction in the thermal solution cost. For more information, see
Extending the Thermal Solution by Utilizing Excursion Temperatures (WP517).

Power Rail Consolidation Impacting Power

To take advantage of the power management switching of power domains, your design must
keep some discrete power rails. This allows individual rails to be powered off with the power
domain switching logic at the cost of using additional voltage regulators or regulator outputs. For
more information, see this link in the UltraScale Architecture PCB Design User Guide (UG583).

TIP: The Vivado tools also support power rail constraints. For information, see this link in the Vivado
Design Suite User Guide: Power Analysis and Optimization (UG907).

Power Models Accuracy

The accuracy of the characterization data embedded in the tools evolves over time to reflect the
device availability or manufacturing process maturity. For details, see this link in the Vivado
Design Suite User Guide: Power Analysis and Optimization (UG907).

POWER TIP: Power estimation is only as accurate as the data entered. Xilinx recommends conducting a
thorough estimation and using the results of this estimation as well as the thermal evaluation as a design
constraint.

Device Power and the Overall System Design Process

From project conception to completion, various aspects of the design process affect power. For
details, see this link in the Vivado Design Suite User Guide: Power Analysis and Optimization
(UG907).

POWER TIP: During the design process, you can compare the total power of the design to the power
budget using the set_operating_conditions -design_power_budget <Power in
Watts> XDC constraint. If the power budget is exceeded, early intervention is the easiest way to correct
design power.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 21
 Chapter 2: Board and Device Planning

Worst Case Power Analysis

Xilinx recommends designing the board for worst-case power. For details, see this link in the
Vivado Design Suite User Guide: Power Analysis and Optimization (UG907).

Clock Resource Planning and Assignment

Xilinx recommends that you select clocking resources as one of the first steps of your design,
well before pinout selection. Your clocking selections can dictate a particular pinout and can also
direct logic placement for that logic, especially for stacked silicon interconnect (SSI) technology
devices. Proper clocking selections can yield superior results. Consider the following:

• Constraint creation, particularly in large devices with high utilization in conjunction with clock
planning.
• Manual placement of clocking resources if needed for design closure.
• Device-specific functionality that might require up-front planning to avoid issues and take
advantage of device features. For information on 7 series features, see this link and this link in
the 7 Series FPGAs Clocking Resources User Guide (UG472). For information on UltraScale
device features, see this link in the UltraScale Architecture Clocking Resources User Guide
(UG572).

Related Information

Clocking Guidelines
Auto-Pipelining Considerations
SLR Crossing for Wide Buses

I/O Planning Design Flows

The Vivado IDE allows you to interactively explore, visualize, assign, and validate the I/O ports
and clock logic in your design. The environment ensures correct-by-construction I/O assignment.
It also provides visualization of the external package pins in correlation with the internal die pads.

You can visualize the data flow through the device and properly plan I/Os from both an external
and internal perspective. After the I/Os are assigned and configured through the Vivado IDE,
constraints are then automatically created for the implementation tools.

For more information on Vivado Design Suite I/O and clock planning capabilities, see the
following resources:

• Vivado Design Suite User Guide: I/O and Clock Planning (UG899)

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 22
 Chapter 2: Board and Device Planning

• Vivado Design Suite QuickTake Video: I/O Planning Overview

Types of Vivado Design Suite Projects for I/O

Planning
You can perform I/O planning with either of the following types of projects:

• I/O planning project : An I/O planning project is an easy entry point that allows you to specify
select I/O constraints and generate a top-level RTL file from the defined pins.

• RTL project : An RTL project allows synthesis and implementation, which enables more
comprehensive design rule checks (DRCs). An RTL project also allows generation of IP cores,
which is important for memory interface pinout planning and any cores using GTs.

TIP: You can also start by using an I/O planning project and migrate to an RTL project later.

You can run more comprehensive DRCs on a post-synthesis netlist. The same is true after
implementation and bitstream generation. Therefore, Xilinx recommends using a skeleton design
that includes clocking components and some basic logic to exercise the DRCs. This builds
confidence that the pin definition for the board will not have issues later.

The recommended sign-off process is to run the RTL project through to bitstream generation to
exercise all the DRCs. However, not all design cycles allow enough time for this process. Often
the I/O configuration must be defined before you have synthesizable RTL. Although the Vivado
tools enable pre-RTL I/O planning, the level of DRCs performed are fairly basic. Alternatively,
you can use a dummy top-level design with I/O standards and pin assignments to help perform
DRCs related to banking rules.

Pre-RTL I/O Planning

If your design cycle forces you to define the I/O configuration before you have a synthesized
netlist, take great care to ensure adherence to all relevant rules. The Vivado tools include a Pin
Planning Project environment that allows you to import I/O definitions using a CSV or XDC
format file. You can also create a dummy RTL with just the port directions defined. Availability of
port direction makes SSN analysis more accurate as input and output signals have different
contributions to SSN.

I/O ports can also be created and configured interactively. Basic I/O bank DRC rules are
provided.

See the 7 Series FPGAs PCB Design Guide (UG483), UltraScale Architecture PCB Design User Guide
(UG583), or Zynq-7000 SoC PCB Design Guide (UG933) to ensure proper I/O configuration for
your device. For more information, see this link in the Vivado Design Suite User Guide: I/O and
Clock Planning (UG899).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 23
 Chapter 2: Board and Device Planning

Netlist-Based I/O Planning

The recommended time in the design cycle to assign I/Os and clock logic constraints is after the
design has been synthesized. The clock logic paths are established in the netlist for constraint
assignment purposes. The I/O and clock logic DRCs are also more comprehensive.

See the 7 Series FPGAs PCB Design Guide (UG483), UltraScale Architecture PCB Design User Guide
(UG583), or Zynq-7000 SoC PCB Design Guide (UG933) to ensure proper I/O configuration for
your device. For more information, see this link in the Vivado Design Suite User Guide: I/O and
Clock Planning (UG899).

Identifying Pin Compatible Devices

It is often difficult to predict the final device size for any given design during initial planning. Logic
can be added or removed during the course of the design cycle, which can result in the need to
change the device size. The Vivado tools enable you to identify alternate devices to ensure that
the I/O pin configuration defined is compatible across all selected devices, as long as the package
is the same. For information, see this link in the Vivado Design Suite User Guide: I/O and Clock
Planning (UG899).

IMPORTANT! The device must be in the same package.

TIP: To migrate your design with reduced risk, carefully plan the following at the beginning of the design
process: device selection, pinout selection, and design criteria. Take the following into account when
migrating to a larger or smaller device in the same package: pinout, clocking, and resource management.

Pin Assignment
Good pinout selection leads to good design logic placement, shorter routes, reduced power
consumption, and improved performance. Good pinout selection is especially important for large
devices, because a pinout that is spread out can cause related signals to span longer distances.
For more information, see this link in the Vivado Design Suite User Guide: I/O and Clock Planning
(UG899).

Using Xilinx Tools in Pinout Selection

Xilinx tools assist in interactive design planning and pin selection. These tools are only as
effective as the information you provide them. Tools such as the Vivado I/O Planner can assist
pinout efforts. These tools can graphically display the I/O placement, show relationships among
clocks and I/O components, and provide DRCs to analyze pin selection.

If a design version is available, a quick top-level floorplan can be created to analyze the data flow
through the device. For more information, see the Vivado Design Suite User Guide: Design Analysis
and Closure Techniques (UG906).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 24
 Chapter 2: Board and Device Planning

Required Information
For the tools to work effectively, you must provide as much information about the I/O
characteristics and topologies as possible. You must specify the electrical characteristics,
including the I/O standard, drive, slew, and direction of the I/O.

You must also take into account all other relevant information, including clock topology and
timing constraints. Clocking choices in particular can have a significant influence on pinout
selection, and vice versa.

For IP that have I/O requirements, such as transceivers, PCIe, and memory interfaces, you must
configure the IP prior to completing I/O pin assignment. For more information on specifying the
electrical characteristics for an I/O, see this link in the Vivado Design Suite User Guide: I/O and
Clock Planning (UG899).

Related Information

Clocking Guidelines

Pinout Selection
Xilinx recommends careful pinout selection for some specific signals as discussed below.

General Pinout Selection Guidelines

Following are general guidelines:

• Group the same interface data, address, and control pins into the same bank. If you cannot
group these components into the same bank, group them into adjacent banks.
Note: For SSI technology devices, adjacent banks must also be located within the same super logic
region (SLR).

• Place the following interface control signals in the middle of the data buses they control:
clocking, enables, resets, and strobes.
• Place very high fanout, design-wide control signals towards the center of the device.
Note: For SSI technology devices, place the signals in the SLR located in the middle of the SLR
components they drive.

Configuration Pins
To design an efficient system, you must choose the device configuration mode that best matches
the system requirements. Factors to consider include:

• Using dedicated vs. dual purpose configuration pins.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 25
 Chapter 2: Board and Device Planning

Each configuration mode dedicates certain device pins and can temporarily use other multi-
function pins during configuration only. These multi-function pins are then released for
general use when configuration is completed.
• Using configuration mode to place voltage restrictions on some device I/O banks.
• Choosing suitable terminations for different configuration pins.
• Using the recommended values of pull-up or pull-down resistors for configuration pins.

RECOMMENDED: Even though configuration clocks are slow speed, perform signal integrity analysis on
the board to ensure clean signals.

There are several configuration options. Although the options are flexible, there is often an
optimal solution for each system. Consider the following when choosing the best configuration
option:

• Setup
• Speed
• Cost
• Complexity

For more information on device configuration options, see Vivado Design Suite User Guide:
Programming and Debugging (UG908).

Related Information

Configuration

Memory Interfaces
Additional I/O pin planning steps are required when using Xilinx Memory IP. After the IP is
customized, assign the top-level IP ports to physical package pins in either the elaborated or
synthesized design in the Vivado IDE. All of the ports associated with each Memory IP are
grouped together into an I/O Port Interface for easier identification and assignment. A Memory
Bank/Byte Planner is provided to assist you with assigning Memory I/O pin groups to byte lanes
on the physical device pins. For more information, see this link in the Vivado Design Suite User
Guide: I/O and Clock Planning (UG899).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 26
 Chapter 2: Board and Device Planning

Take care when assigning memory interfaces and try to limit congestion as much as possible,
especially with devices that have a center I/O column. Bunching memory interfaces together can
create routing bottlenecks across the device. The Zynq-7000 SoC and 7 series Devices Memory
Interface Solutions (UG586) and the UltraScale Architecture-Based FPGAs Memory IP LogiCORE IP
Product Guide (PG150) contain design and pinout guidelines. Be sure that you follow the trace
length match recommendations in these guides, verify that the correct termination is used, and
validate the pinout in by running the DRCs after memory IP I/O assignment. For more
information on memory interface signal termination and routing guidelines, see the UltraScale
Architecture PCB Design User Guide (UG583).

Gigabit Transceivers (GTs)

Gigabit transceivers (GTs) have specific pinout requirements, and you must consider the
following:

• Sharing of reference clocks

• Sharing of PLLs within a quad
• Placement of hard blocks, such as PCIe, and their proximity to transceivers
• In SSI technology devices, crossing of SLR boundaries

Xilinx recommends that you use the GT wizard to generate the core. Alternatively, you can use
the Xilinx IP core for the protocol. For pinout recommendations, see the related product guide.

For clock resource balancing, the Vivado placer attempts to constrain loads clocked by GT output
clocks (TXOUTCLK or RXOUTCLK) next to the GTs sourcing the clocks. For SSI technology
devices, if the GTs are located in the clock regions adjacent to another SLR, the routing resources
required for signals entering or exiting SLLs have to compete with the routing resources required
by the GT output clock loads. Therefore, GTs located in clock regions next to SLR crossings might
reduce the available routing connections to and from the SLL crossings available in those clock
regions.

High Speed I/O

HP (high-performance) and HR (high-range) banks have difference in the speed with which they
can transmit and receive signals. Depending upon the I/O speed you need, choose between HP
or HR banks.

Internal VREF and DCI Cascade Constraints

Based on the settings for DCI Cascade and Internal VREF, you can free up pins to be used for
regular I/Os. These settings also ensure that related DRC checks are run to validate the legality
of the constraints. For more information, see either the 7 Series FPGAs SelectIO Resources User
Guide (UG471) or the UltraScale Architecture SelectIO Resources User Guide (UG571), depending on
your device.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 27
 Chapter 2: Board and Device Planning

Interface Bandwidth Validation

Create small connectivity designs to validate each interface on the device. These small designs
exercise only the specific hardware interface, which enables the following:

• Full DRC checks on pinout, clocking, and timing

• Hardware test design when the board is returned
• Rapid implementation through the Vivado tools, providing the fastest way to debug the
interface

There are multiple options to assist in generating test data for these interfaces. For some of the
interface IP cores, the Vivado tools can provide the test designs:

• IBERT for SerDes

• Example design within IP cores

TIP: If a test design does not exist, consider using AXI traffic generators.

You might need to create a separate design for a system-level test in a production environment.
Usually, this is a single design that includes tested interfaces and optionally includes processors.
You can construct this design using the small connectivity designs to take advantage of design
reuse. Although this design is not required early in the flow, it can enable better DRC checks and
early software development, and you can quickly create it using the Vivado IP integrator.

Designing with SSI Devices

SSI Pinout Considerations
When planning pinouts for components that are located in a particular SLR, place the pins into
the same SLR. For example, when using the device DNA information as a part of an external
interface, place the pins for that interface in the master SLR in which the DNA_PORT exists.
Additional considerations include the following:

• Group all pins of a particular interface into the same SLR.

• For signals driving components in multiple SLRs, place those signals in the middle SLR.
• Balance clock-capable I/O (CCIO) or clock management tile (CMT) components across SLRs.
• Reduce SLR crossings.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 28
 Chapter 2: Board and Device Planning

Super Logic Region (SLR)

A super logic region (SLR) is a single device die slice contained in an SSI technology device. Each
SLR contains a subset of device resources, such as CLBs, block RAMs, DSP tiles, and GTs, with a
similar structure to non-SSI devices.

Multiple SLR components are stacked vertically and connected through an interposer to create
an SSI technology device. The bottom SLR is SLR0, and subsequent SLR components are named
incrementally as they ascend vertically.

For example, the XC7V2000T device includes four SLR components. The bottom SLR is SLR0,
the SLR directly above SLR0 is SLR1, the SLR directly above SLR1 is SLR2, and the top SLR is
SLR3.

Note: The Xilinx tools clearly identify SLR components in the graphical user interface (GUI) and in reports.

SLR Nomenclature
Understanding SLR nomenclature for your target device is important in:

• Pin selection
• Floorplanning
• Analyzing timing and other reports
• Identifying where logic exists and where that logic is sourced or destined

You can use the Vivado Tcl command get_slrs to get specific information about SLRs for a
particular device. For example, use the following commands:

• llength [get_slrs] to obtain the number of SLRs in the device

• get_slrs -of_objects [get_cells my_cell] to get the SLR in which my_cell is
placed

Master Super Logic Region

Every SSI technology device has a single master SLR. The master SLR contains the primary
configuration logic that initiates configuration of the device and all other SLR components. The
master SLR contains the circuitry that is used for configuration, DNA_PORT, and EFUSE_USER.
When using these components, the place and route tools can assign associated pins and logic to
the appropriate SLR. In general, no additional intervention is required.

TIP: To query which SLR is the master SLR in the Vivado Design Suite, you can enter the get_slrs -
filter IS_MASTER Tcl command.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 29
 Chapter 2: Board and Device Planning

Silicon Interposer
The silicon interposer is a passive layer in the SSI technology device, which routes the following
between SLR components:

• Configuration
• Global clocking
• General interconnect

Super Long Line (SLL) Routes

Super Long Line (SLL) routes connect signals from one SLR to another inside the device.

TIP: To determine the number of available SLLs between SLRs, use SLR properties. For example:

get_property NUM_TOP_SLLS [get_slrs SLR0]

get_property NUM_BOT_SLLS [get_slrs SLR1]

Propagation Limitations
TIP: For high-speed propagation across SLRs, be sure to register signals that cross SLR boundaries.

SLL signals are the only data connections between SLR components.

The following do not propagate across SLR components:

• Carry chains
• DSP cascades
• Block RAM and UltraRAM cascades
• Other dedicated connections, such as DCI cascades

The tools normally take this limit on propagation into account. To ensure that designs route
properly and meet your design goals, you must also take this limit into account when you:

• Build a very long DSP, Block RAM, or UltraRAM cascade and manually place such logic near
SLR boundaries
• Specify a pinout for the design

SLR Utilization Considerations

The Vivado implementation tools use a special algorithm to partition logic into multiple SLRs. For
challenging designs, you can improve timing closure for designs that target SSI technology
devices using the following guidelines.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 30
 Chapter 2: Board and Device Planning

To improve timing closure and compile times, you can use Pblocks to assign logic to each SLR and
validate that individual SLRs do not have excessive utilization across all fabric resource types. For
example, a design with block RAM utilization of 70% might cause issues with timing closure if the
block RAM resources are not balanced across SLRs and one SLR is using over 85% block RAM.

TIP: You can define SLR Pblocks by specifying a complete SLR (e.g., resize_pblock pblock_SLR0
-add SLR0).

SLR Utilization Example

The following example utilization report for a vu160 shows that the overall block RAM utilization
is 56% with 59% in SLR0, 40% in SLR1, and 58% in SLR2. The block RAM utilization is evenly
distributed across SLRs with reasonable utilization in each SLR, which allows the Vivado
implementation commands more flexibility to meet timing.

Figure 7: Block RAM Section in Utilization Report

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 31
 Chapter 2: Board and Device Planning

Figure 8: SLR Section in Utilization Report

Xilinx recommends assigning block RAM and DSP groups to SLR Pblocks to minimize SLR
crossings of shared signals. For example, an address bus that fans out to a group of block RAMs
that are spread out over multiple SLRs can make timing closure more difficult to achieve, because
the SLR crossing incurs additional delay for the timing critical signals.

Device resource location or user I/O selection anchors IP to SLRs, for example, GT, ILKN, PCIe,
and CMAC dedicated block or memory interface controllers. Xilinx recommends the following:

• Pay special attention to dedicated block location and pinout selection to avoid data flow
crossing SLR boundaries multiple times.
• Keep tightly interconnected modules and IP within the same SLR. If that is not possible, you
can add pipeline registers to allow the placer more flexibility to find a good solution despite
the SLR crossing between logic groups.
• Keep critical logic within the same SLR. By ensuring that main modules are properly pipelined
at their interfaces, the placer is more likely to find SLR partitions with flip-flop to flip-flop SLR
crossings.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 32
 Chapter 2: Board and Device Planning

In the following figure, a memory interface that is constrained to SLR0 needs to drive user logic
in SLR1. An AXI4-Lite slave interface connects to the memory IP backend, and the well-defined
boundary between the memory IP and the AXI4-Lite slave interface provides a good transition
from SLR0 to SLR1.

Figure 9: Memory Interface in SLR0 Driving User Logic in SLR1

User_logic

AXI4_slave
SLR1

SLR0
MIG_DDR3
X15238-121919

SLR Crossing for Wide Buses

When data flow requirements require that wide buses cross SLRs, use pipelining strategies to
improve timing closure and alleviate routing congestion of long resources. For wide buses
operating above 250 MHz, Xilinx recommends using at least three pipeline stages to cross an
SLR: one at the top, one at the bottom, and one in the middle of the SLR. Additional pipeline
stages might be required for very high performance buses or when traversing horizontal as well
as vertical distances.

The following figure illustrates a worst case crossing for a vu190-2 device. This example starts at
an Interlaken dedicated block in the bottom left of SLR0 to a packet monitor block assigned to
the top right of SLR2. Without pipeline registers for the data bus to and from the packet monitor,
the design misses the 300 MHz timing requirement by a wide margin.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 33
 Chapter 2: Board and Device Planning

Figure 10: Data Path Crossing SLR without Pipeline Flip-Flop

X15240-121919

However, adding seven pipeline stages to aid in the traversal from SLR0 to SLR2 allows the
design to meet timing. It also reduces the use of vertical and horizontal long routing resources, as
shown in the following figure.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 34
 Chapter 2: Board and Device Planning

Figure 11: Data Path Crossing SLR with Pipeline Flip-Flop Added

X15239-110415

TIP: Use the AXI Register Slice IP or your custom auto-pipelining IP to close timing on wide buses across
SLRs.

Related Information

Auto-Pipelining Considerations

Designing with HBM Devices

Virtex® UltraScale+™ HBM devices incorporate 4 GB high-bandwidth memory (HBM) stacks
adjacent to the device die. Using SSI technology, the device communicates to the HBM stacks
through memory controllers that connect through the silicon interposer at the bottom of the
device. Each Virtex UltraScale+ HBM device contains one or two 4 GB HBM stacks, resulting in
up to 8 GB of HBM per device. The device includes 32 HBM AXI interfaces used to communicate
with the HBM. The flexible addressing feature that is provided by a built-in switch allows for any
of the 32 HBM AXI interface to access any memory address on either one or both of the HBM
stacks. This flexible connection between the device and the HBM stacks is helpful for
floorplanning and timing closure.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 35
 Chapter 2: Board and Device Planning

The following figure shows the Virtex UltraScale+ HBM vu37p device adjacent to a Virtex
UltraScale+ vu13p device. In the VU37P device, the bottom two SLRs of the VU13P device are
replaced by the HBM stacks (SLR0 in the vu13p device) and an SLR that contains the 32 HBM
AXI interfaces (SLR1 in the vu13p device). The top two SLRs of the vu13p and vu37p device are
identical.

Figure 12: Device View of the vu13p and vu37p

CMAC
ILKN
PCIE
PCIEC

HBM AXI
vu13p vu37p
X21195-121919

In the vu37p device, the SLR0 contains 4 PCIE4C sites, 2 ILKNE4 sites, and the 32 HBM AXI
interfaces. The 4 PCIE4C sites in the Virtex UltraScale+ HBM SLR0 are unique because they
allow for the Cache Coherent Interconnect for Accelerators (CCIX) protocol using PCIe Gen3 x
16 when VCCINT is at 0.72V.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 36
 Chapter 2: Board and Device Planning

Figure 13: SLR0 of a Virtex UltraScale+ HBM vu37p Device

ILKNE4
CMACE4
PCIE4
PCIE4C

HBM AXI
X21207-121919

Placement Considerations When Using HBM Devices

Pipelining Considerations for Crossing SLRs
The pipeline considerations for crossing SLRs in Virtex UltraScale+ HBM devices are the same as
for other UltraScale and Virtex UltraScale+ SSI technology devices.

Paths from fabric logic in SLR2 to the HBM AXI Interfaces in SLR0 often require five or more
pipeline stages to meet timing. Thoughtful design planning of Virtex UltraScale+ HBM devices
can reduce the need for additional pipeline stages and reduce routing congestion. The following
figure shows an example of SLR crossings to the HBM AXI Interfaces from SLR2.

RECOMMENDED: Xilinx recommends keeping the paths from SLR2 and SLR1 vertically aligned to their
respective HBM AXI interfaces to avoid crossing the device diagonally.

TIP: Use auto-pipelining (e.g., AXI Register Slice IP) to ensure timing closure between the HBM interfaces
and any SLR at 450 MHz.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 37
 Chapter 2: Board and Device Planning

Figure 14: HBM Sub-Optimal Design Planning (left) versus Optimal Design Planning
(right)

X21196-121919

Related Information

Auto-Pipelining Considerations
SLR Crossing for Wide Buses

Resource Planning within SLR0

Proper management of the HBM AXI Interfaces and other logic within the SLR0 can provide
optimal quality of results (QoR) and minimize routing congestion. Following are some common
design planning considerations for the SLR0 in HBM devices:

• For designs that heavily utilize the HBM AXI interfaces, budget for lower overall fabric
utilization of non-HBM logic in SLR0 to better accommodate the resources required for the
HBM AXI interfaces.
• Using MIG IP in the SLR0 might result in timing closure challenges for HBM AXI interfaces
located near the I/O columns of the device. When using MIG IP, consider using the I/O
columns located in SLR2 or SLR1.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 38
 Chapter 2: Board and Device Planning

• Be aware of address ranges and the physical location of the HBM AXI interfaces that can
impact the latency and bandwidth of the design. To optimize the performance of the HBM,
utilize the physical HBM AXI interfaces on the same device side as the addressed HBM stack.

PCIE4C to HBM AXI Paths within SLR0

To achieve optimal timing QoR and minimize routing congestion when designing with HBM and
PCIE4C, Xilinx recommends using the PCIE4C sites that are farthest away from the 32 HBM AXI
interface in SLR0. In the following figure, these sites are PCIE4CE4_X0Y1 and PCIE4CE4_X1Y1
indicated by the green arrows.

Figure 15: Recommended PCIE4C Sites in SLR0 of a Virtex UltraScale+ HBM vu37p
Device

Configuration
Configuration is the process of loading application-specific data into the internal memory of the
device. Because Xilinx device configuration data is stored in CMOS configuration latches (CCLs),
the configuration data is volatile and must be reloaded each time the device is powered up.

Xilinx devices can load themselves through configuration pins from an external, non-volatile
memory device. Devices can also be configured by an external smart source, such as the
following:

• Microprocessor

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 39
 Chapter 2: Board and Device Planning

• Microcontroller
• DSP processor
• Personal computer (PC)
• Board tester

When board planning, consider configuration aspects up front, which makes it easier to configure
as well as debug. Each device family has a Configuration User Guide that is the primary resource
for detailed information about each of the supported configuration modes and their trade-offs on
pin count, performance, and cost.

Related Information

Other Xilinx Documentation

Board Design Tips

When designing a board, it is important to consider which interfaces and pins will assist with
debug capability beyond configuration. For example, Xilinx recommends that you ensure the
JTAG interface is accessible even when the interface is not the primary configuration mode. The
JTAG interface allows you to check the device ID and device DNA information, and you can use
the interface to enable indirect flash programming solutions during prototyping.

In addition, signals such as the INIT_B and DONE are critical for device configuration debug. The
INIT_B signal has multiple functions. It indicates completion of initialization at power-up and can
indicate when a CRC error is encountered. Xilinx recommends that you connect the INIT_B and
DONE signals to light-emitting diodes (LEDs) using LED drivers and pull-ups.

For recommended pull-up values, see the configuration user guide for your device:

• 7 Series FPGAs Configuration User Guide (UG470)

• UltraScale Architecture Configuration User Guide (UG570)

To identify and check recommended board-level pin connections, see the schematic checklists:

• 7 Series Schematic Review Recommendations (XMP277)

• Kintex UltraScale and Virtex UltraScale FPGAs Schematic Review Checklist (XTP344)
• UltraScale+ FPGAs and Zynq Ultrascale+ Devices Schematic Review Checklist (XTP427)

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 40
 Chapter 3: Design Creation with RTL

Chapter 3

Design Creation with RTL

After planning your device I/O, planning how to lay out your PCB, and deciding on your use
model for the Vivado® Design Suite, you can begin creating your design. Design creation
includes:

• Planning the hierarchy of your design

• Identifying the IP cores to use and customize in your design
• Creating the custom RTL for interconnect logic and functionality for which a suitable IP is not
available
• Creating timing, power, and physical constraints
• Specifying additional constraints, attributes, and other elements used during synthesis and
implementation

When creating your design, the main points to consider include:

• Achieving the desired functionality

• Operating at the desired frequency
• Operating with the desired degree of reliability
• Fitting within the silicon resource and power budget

Decisions made at this stage affect the end product. A wrong decision at this point can result in
problems at a later stage, causing issues throughout the entire design cycle. Spending time early
in the process to carefully plan your design helps to ensure that you meet your design goals and
minimize debug time in lab.

Defining a Good RTL Design Hierarchy

The first step in design creation is to decide how to partition the design logically. The main factor
when considering hierarchy is to partition a part of the design that contains a specific function.
This allows a specific designer to design a piece of IP in isolation as well as isolating a piece of
code for reuse.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 41
 Chapter 3: Design Creation with RTL

However, defining a hierarchy based on functionality only does not take into account how to
optimize for timing closure, runtime, and debugging. The following additional considerations
made during hierarchy planning also help in timing closure.

Add I/O Components Near the Top Level

Where possible, add I/O components near the top level for design readability. When you infer a
component, you provide a description of the function you want to accomplish. The synthesis tool
then interprets the HDL code to determine which hardware components to use to perform the
function. Components that can be inferred are simple single-ended I/O (IBUF, OBUF, OBUFT and
IOBUF) and single data rate registers in the I/O.

When using the tool to infer IOBUF or OBUFT components, make sure that the enable logic and
the input/output logic are all in the same hierarchy. If the logic is in different hierarchies and
there are KEEP_HIERARCHY or DONT_TOUCH attributes between the hierarchies, the tool will
not be able to infer these buffers.

I/O components that need to be instantiated, such as differential I/O (IBUFDS, OBUFDS) and
double data-rate registers (IDDR, ODDR, ISERDES, OSERDES), should also be instantiated near
the top level. When you instantiate a component, you add an instance of that component to your
HDL file. Instantiation gives you full control over how the component is used. Therefore, you
know exactly how the logic will be used.

Insert Clocking Elements Near the Top Level

Inserting the clocking elements towards the top level allows for easier clock sharing between
modules. This sharing may result in fewer clocking resources needed, which helps in resource
utilization, improved performance, and power.

Aside from the module the clocks are created in, clock paths should only drive down into
modules. Any paths that go through (down from top and then back to top) can create a delta
cycle problem in VHDL simulation that is difficult and time consuming to debug.

Register Data Paths at Logical Boundaries

Register the outputs of hierarchical boundaries to contain critical paths within a single module or
boundary. Consider registering the inputs also at the hierarchical boundaries. It is always easier
to analyze and repair timing paths which lie within a module, rather than a path spanning
multiple modules. Any paths that are not registered at hierarchy boundaries should be
synthesized with hierarchy rebuilt or flat to allow cross hierarchy optimization. Registering the
datapaths at logical boundaries helps to retain traceability (for debug) through the design process
because cross hierarchical optimizations are kept to a minimum and logic does not move across
modules.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 42
 Chapter 3: Design Creation with RTL

Address Floorplanning Considerations

A floorplan ensures that cells belonging to a specific portion in the design netlist are placed at
particular locations on the device. You can use manual floorplanning to accomplish the following:

• Partition logic to a particular SLR when using SSI technology devices.

• Close timing on a design when timing is not met using standard flows.

If the cells are not contained within a level of hierarchy, all objects must be included individually
in the floorplan constraint. If synthesis changes the names of these objects, you must update the
constraints. A good floorplan is contained at the hierarchy level, because this requires only a one
line constraint.

Floorplanning is not always required. Floorplan only when necessary.

For more information on floorplanning, see this link in the Vivado Design Suite User Guide: Design
Analysis and Closure Techniques (UG906).

RECOMMENDED: Although the Vivado tools allow cross hierarchy floorplans, these require more
maintenance. Avoid cross hierarchy floorplans where possible.

Optimize Hierarchy for Functional and Timing Debug

As discussed earlier in this section, keeping the critical path within the same hierarchical
boundary is helpful in debugging and meeting timing requirements. Similarly, for functional
debug (and modification) purposes, signals that are related should be kept in the same hierarchy.
This allows the related signals to be probed and modified with relative ease, as signal names
optimized by synthesis are easier to trace when contained in a single level of hierarchy.

Apply Attributes at the Module Level

Applying attributes at the module level can keep code tidier and more scalable. Instead of having
to apply an attribute at the signal level, you can apply the attribute at the module level and have
the attribute propagated to all signals declared in the current hierarchy. Applying attributes at the
module level also allows you to override global synthesis options.

CAUTION! Unlike other attributes, the DONT_TOUCH attribute does not propagate from a module to all
the signals inside the module. For more information, see this link in the Vivado Design Suite User Guide:
Synthesis (UG901).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 43
 Chapter 3: Design Creation with RTL

Optimize Hierarchy for Advanced Design Techniques

Advanced design techniques such as bottom-up synthesis, Dynamic Function eXchange (DFX),
and out-of-context design require planning at the hierarchical level. The designer must choose
the appropriate level of hierarchy for the technique being used. These techniques are not
covered in this document. For more information, see this link in the Vivado Design Suite User
Guide: Hierarchical Design (UG905).

Example of Upfront Hierarchical Planning for High

Speed DSP Designs
The following example is not applicable to all designs, but demonstrates what can be done with
hierarchy. DSP designs generally allow latency to be added to the design. This allows registers to
be added to them to be optimized for performance. In addition, registers can be used to increase
placement flexibility. This is important because at high clock frequency, signals cannot traverse
the die in one clock cycle. Adding registers can allow hard-to-reach areas to be used. The
following figure shows how effective hierarchy planning results in faster timing closure.

Figure 16: Effective Hierarchy Planning Example

placement_flexibility_wrapper_i

floorplanning_wrapper_i

DSP_i
DATA_IN DATA_OUT

DSP
VALID_IN Algorithm VALID_OUT
CE

attribute KEEP_HIERARCHY = “yes”

attribute SHREG_EXRACT = “no”

X13500-122019

There are three levels of hierarchy in this part of the design:

• DSP_i
In the DSP_i algorithm block, both the inputs and outputs are registered. Because registers are
plentiful in a device, it is preferable to use this method to improve the timing budget.
• floorplanning_wrapper_i

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 44
 Chapter 3: Design Creation with RTL

In floorplanning_wrapper_i, there is a CE signal. CE signals are typically heavily-loaded

and can present a timing challenge. They should be included in a floorplan. By creating a
floorplanning wrapper, this module can be manually floorplanned later if needed.
In addition, KEEP_HIERARCHY has been added at the module level to ensure that hierarchy is
preserved for floorplanning regardless of any other global synthesis options.
• placement_flexibility_wrapper_i
In placement_flexibility_wrapper_i, the DATA_IN, VALID_IN, DATA_OUT and
VALID_OUT signals are registered. Because these signals are not intended to be part of the
floorplan, they are outside floorplanning_wrapper_i. If they were in the floorplan, they
would not be able to fulfill the requirement for placement flexibility.
In addition, more registers can be added later as long as both DATA_IN + VALID_IN or
DATA_OUT and VALID_OUT are treated as pairs. If more registers are added, the synthesis
tool might infer shift register LUTs (SRLs), which will force all registers into one component
and not help placement flexibility. To prevent this, SHREG_EXTRACT has been added at the
module level and set to NO.

Working with Intellectual Property (IP)

Pre-validated Intellectual Property (IP) cores significantly reduce design and validation efforts,
and ensure a large advantage in time-to-market. See the following resources for more
information on working with IP:

• Vivado Design Suite User Guide: Designing with IP (UG896)

• Vivado Design Suite User Guide: Designing IP Subsystems Using IP Integrator (UG994)
• Vivado Design Suite QuickTake Video: Configuring and Managing Reusable IP in Vivado

Planning IP Requirements
Planning IP requirements is one of the most important stages of any new project:

• Evaluate the IP options available from Xilinx or third-party partners against required
functionality and other design goals. For example:
○ Is custom logic more desirable compared to an available IP core?

○ Does it make sense to package a custom design for reuse in multiple projects in an industry
standard format?
• Consider the interfaces that are required such as, memory, network, and peripherals.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 45
 Chapter 3: Design Creation with RTL

IMPORTANT! To ensure that the tools process the IP-specific constraints properly, add the .xci or .xcix IP
source files to the project. Do not use the IP-generated output DCP files as project sources when working
with IP.

AMBA AXI
Xilinx has standardized IP interfaces on the open AMBA® 4 AXI4 interconnect protocol. This
standardization eases integration of IP from Xilinx and third-party providers, and maximizes
system performance. Xilinx has worked with Arm® to define the AXI4, AXI4-Lite, and AXI4-
Stream specifications for efficient mapping into its device architectures.

AXI4 is targeted at high performance, high clock frequency system designs, and is suitable for
high-speed interconnects. AXI4-Lite is a light-weight version of AXI4, and is used mostly for
accessing control and status registers.

AXI4-Stream is used for unidirectional streaming of data from Master to Slave. This is typically
used for DSP, Video and Communications applications.

Vivado Design Suite IP Catalog

The IP catalog is a single location for Xilinx-supplied IP. In the IP catalog, you can find IP cores for
embedded systems, DSP, communication, interfaces, and more.

From the IP catalog, you can explore the available IP cores, and view the Product Guide, Change
Log, Product Web page, and Answer Records for any IP.

You can access and customize the cores in the IP catalog through the GUI or Tcl shell. You can
also use Tcl scripts to automate the customization of IP cores.

Custom IP
Xilinx uses the industry standard IP-XACT format for delivery of IP, and provides tools (IP
packager) to package custom IP. Accordingly, you can also add your own customized IP to the
catalog and create IP repositories that can be shared in a team or across a company. IP from
third-party providers can also be added to this catalog, provided it is packaged in IP packager,
even if it is already in the IP-XACT format.

Selecting IP from the IP Catalog

All Xilinx and third-party vendor IP is categorized based on applications such as communications
and networking; video and image processing; and automotive and industrial. Use this
categorization to browse the catalog to see which IP is available for your area of interest.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 46
 Chapter 3: Design Creation with RTL

A majority of the IP in the IP catalog is free. However, some high value IP has an associated cost
and requires a license. The IP catalog informs you about whether or not the IP requires purchase,
as well as the status of the license. To select an IP from the catalog, consider the following key
features, based on your design requirements, and what the specific IP offers:

• Silicon Resources required by this IP (found in the respective IP Product Guide)

• Is this IP supported in the device and speed grade being considered (the selection of the IP
often drives the speed grade decision)? If supported, what is the max achievable throughput
and Fmax?
• External interface standards, needed for your design to talk to its companion chip on board:
○ Industry-standard interfaces such as Ethernet, PCIe® interfaces, etc.

○ Memory interfaces - number of memory interfaces, including their size and performance.

○ Xilinx proprietary interfaces such as Aurora.

Note: You can also choose to design your own custom interface.

• On-chip bus protocol supported by the IP (Application interface)

• On-chip bus protocol, needed for interaction with the rest of your design. Examples:
○ AXI4

○ AXI4-Lite

○ AXI4-Stream

• If multiple protocols are involved, bridging IP cores might have to be chosen using
infrastructure IP from the IP catalog. For example:
○ AXI-AHB bridge

○ AXI-AXI Interconnect

○ AXI-PCIe bridge

○ AXI-PLB bridge

Customizing IP
IP can be customized through the GUI or through Tcl scripts.

Related Information

Using the Customization GUI

Using a Tcl Script

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 47
 Chapter 3: Design Creation with RTL

Using the Customization GUI

Using the graphical interface is the easiest way to find, research, and customize IP. Each IP is
customized with its own set of tabs or pages. Related configuration options are grouped
together. An example of a customization window is shown in the following figure. A unique
customization of an IP can be created, which is represented in an XCI file. From this, the various
output products of an IP can be created.

Using a Tcl Script

Almost every GUI action results in the issuance of a Tcl command. The creation of an IP including
the setting of all the customization options can be performed in a Tcl script without user
interaction.

You would need to know the names of the configuration options, and the values to which they
can be set. Typically, you first perform the customization through the GUI, and then create the
script from that. Once you see the resulting Tcl script, you can easily modify the script for your
needs, such as changing data sizes.

Tcl script based IP creation is useful for automation, for example working with version control
system. For information about source management and revision control, see this link in the
Vivado Design Suite User Guide: Design Flows Overview (UG892).

IP Versions and Revision Control

When IP is customized, the tool creates an XCI file containing all the selected parameterization
values. Each Vivado IDE version supports only one version of an IP. Xilinx recommends that you
use this latest IP version. If you use an older IP version, you must save all the output products for
the older version. For information about source management and revision control, see this link in
the Vivado Design Suite User Guide: Design Flows Overview (UG892).

IMPORTANT! For memory IP in 7 series devices, a PRJ file is created in addition to the XCI file. When
using revision control with 7 series memory IP, keep the PRJ file in the same directory as the XCI file.

RTL Coding Guidelines

You can create custom RTL to implement glue logic functions as well as functions without
suitable IP. For optimal results, follow the coding guidelines in this section. For additional
guidelines, see this link in the Vivado Design Suite User Guide: Synthesis (UG901).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 48
 Chapter 3: Design Creation with RTL

Using Vivado Design Suite HDL Templates

Use the Vivado Design Suite Language Templates when creating RTL or instantiating Xilinx®
primitives. The Language Templates include recommended coding constructs for proper
inference to the Xilinx device architecture. Using the Language Templates can ease the design
process and lead to improved results. To open the Language Templates from the Vivado IDE,
select the Language Templates option in the Flow Navigator, and select the desired template.

Control Signals and Control Sets

A control set is the grouping of control signals (set/reset, clock enable and clock) that drives any
given SRL, LUTRAM, or register. For any unique combination of control signals, a unique control
set is formed. This is important, because registers within a 7 series slice all share common control
signals, and thus, only registers with a common control set can be packed into the same slice. For
example, if a register with a given control set has just one register as a load, the other seven
registers in the slice it occupies will be unusable.

Designs with too many unique control sets might have many wasted resources as well as fewer
options for placement, resulting in higher power and lower performance. Designs with fewer
control sets have more options and flexibility in terms of placement, generally resulting in
improved results.

In UltraScale™ devices, there is more flexibility in control set mapping within a CLB. Resets that
are undriven do not form part of the control set, because the tie off is generated locally within
the slice. However, it is good practice to limit unique control sets to give maximum flexibility in
placement of a group of logic.

Resets
Resets are one of the more common and important control signals to take into account and limit
in your design. Resets can significantly impact your design's performance, area, and power.

Inferred synchronous code might result in resources such as:

• LUTs
• Registers
• SRLs
• Block or LUT memory
• DSP48 registers

The choice and use of resets can affect the selection of these components, resulting in less
optimal resources for a given design. A misplaced reset on an array can mean the difference
between inferring one block RAM, or inferring several thousand registers.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 49
 Chapter 3: Design Creation with RTL

Asynchronous resets described at the input or output of a multiplier might result in registers
placed in the slices rather than the DSP block. In such situations, additional logic resources are
used, which negatively impacts the power consumption and design performance.

When and Where to Use a Reset

Xilinx devices have a dedicated global set/reset signal (GSR). This signal sets the initial value of all
sequential cells in hardware at the end of device configuration.

If an initial state is not specified, sequential primitives are assigned a default value. In most cases,
the default value is zero. Exceptions are the FDSE and FDPE primitives that default to a logic
one. Every register will be at a known state at the end of configuration. Therefore, it is not
necessary to code a global reset for the sole purpose of initializing a device on power up.

Xilinx highly recommends that you take special care in deciding when the design requires a reset,
and when it does not. In many situations, resets might be required on the control path logic for
proper operation. However, resets are generally less necessary on the data path logic. Limiting
the use of resets:

• Limits the overall fanout of the reset net.

• Reduces the amount of interconnect necessary to route the reset.
• Simplifies the timing of the reset paths.
• Results in many cases in overall improvement in performance, area, and power.

RECOMMENDED: Evaluate each synchronous block, and attempt to determine whether a reset is
required for proper operation. Do not code the reset by default without ascertaining its real need.

Functional simulation should easily identify whether a reset is needed or not.

For logic in which no reset is coded, there is much greater flexibility in selecting the device
resources to map the logic.

The synthesis tool can then pick the best resource for that code in order to arrive at a potentially
superior result by considering, for example:

• Requested functionality
• Performance requirements
• Available device resources
• Power

Synchronous Reset vs. Asynchronous Reset

If a reset is needed, Xilinx recommends using synchronous resets. Synchronous resets have the
following advantages over asynchronous resets:

• Synchronous resets can directly map to more resource elements in the device architecture.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 50
 Chapter 3: Design Creation with RTL

• Asynchronous resets impact the performance of the general logic structures. Because all Xilinx
device general-purpose registers can program the set/reset as either asynchronous or
synchronous, it might seem like there is no penalty in using asynchronous resets. If a global
asynchronous reset is used, it does not increase the control sets. However, the need to route
this reset signal to all register elements increases routing complexity.
• Asynchronous resets have a greater probability of corrupting memory contents of block
RAMs, LUTRAMs, and SRLs during reset assertion. This is especially true for registers with
asynchronous resets that drive the input pins of block RAMs, LUTRAMs, and SRLs.
• Synchronous resets offer more flexibility for control set remapping when higher density or fine
tuned placement is needed. A synchronous reset can be remapped to the data path of the
register if an incompatible reset is found in the more optimally placed slice. This can reduce
routing resource utilization and increase placement density where needed to allow proper
fitting and improved performance.
• Some resources such as the DSP48 and block RAM have only synchronous resets for the
register elements within the block. When asynchronous resets are used on register elements
associated with these elements, those registers may not be inferred directly into those blocks
without impacting functionality.

Following are additional considerations:

• The clock works as a filter for small reset glitches for synchronous resets. However, if these
glitches occur near the active clock edge, the flip-flop might become metastable.
• Synchronous resets might need to stretch the pulse width to ensure that the reset signal pulse
is wide enough for the reset to be present during an active edge of the clock.
• When using asynchronous resets, remember to synchronize the deassertion of the
asynchronous reset. Although the relative timing between clock and reset can be ignored
during reset assertion, the reset release must be synchronized to the clock. Avoiding the reset
release edge synchronization can lead to metastability. During reset release, setup and hold
timing conditions must be satisfied for the reset pin relative to the clock pin of a register. A
violation of the setup and hold conditions for asynchronous reset (e.g., reset recovery and
removal timing) might cause the flip-flop to become metastable, causing design failure due to
switching to an unknown state. Note that this situation is similar to the violation of setup and
hold conditions for the flip-flop data pin.

Reset Coding Example: Multiplier with Synchronous Reset

To take advantage of the existing DSP primitive features, the following example shows a
multiplier with synchronous reset.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 51
 Chapter 3: Design Creation with RTL

Figure 17: Multiplier with Pipeline Registers (Synchronous Reset)

In this circuit, the DSP48 primitive is inferred with all pipeline registers packed within the DSP
primitive (AREG/BREG=1, MREG=1, PREG=1).

This coding example has the following advantages:

• Optimal resource usage

• Better performance and lower power
• Lower number of endpoints

Reset Coding Example: Multiplier with Asynchronous Reset

The following example illustrates the importance of using registers with synchronous resets for
the logic targeting the dedicated DSP resources. The following figure shows a 16x16 bits DSP48-
based multiplier using pipeline registers with asynchronous reset. Synthesis must use regular
fabric registers for the input stages, as well as an external register and 32 LUT2s (red markers) to
emulate the asynchronous reset on the DSP output (DSP48 P registers are enabled but not
connected to reset). This costs an extra 65 registers and 32 LUTs, and the DSP48 results in the
configuration: AREG/BREG=0, MREG=0, PREG=1.

Figure 18: Multiplier with Pipeline Registers Using Asynchronous Resets

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 52
 Chapter 3: Design Creation with RTL

By simply changing the reset definition as shown in the following figure, such that the multiplier
pipeline registers use a synchronous reset, synthesis can take advantage of the DSP48 internal
registers: AREG/BREG=1, MREG=1, PREG=1.

Figure 19: Changing Asynchronous Reset into Synchronous Reset on Multiplier

Due to saving fabric resources and taking advantage of all DSP48 internal registers, the design
performance and power efficiency are optimal.

Issues When Trying to Eliminate Reset in HDL Code

When optimizing the code to eliminate reset, commenting out the conditions within the reset
declaration does not create the desired structures and instead creates issues. For example, the
following figure shows three pipeline stages with asynchronous reset used for each. If you
attempt to eliminate the reset condition for two of the pipeline stages by commenting out the
code with the reset condition, the asynchronous reset becomes enabled (inverted logic of rst).

Figure 20: Commenting Out Code with Reset Conditions

D Q D Q D Q
CE CE CLR
clk clk clk

rst

X17086-052016

The optimal way to remove the resets is to create separate sequential logic procedures with one
for reset conditions and the other for non-reset conditions, as shown in the following figure.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 53
 Chapter 3: Design Creation with RTL

Figure 21: Separate Procedural Statements for Registers With and Without Reset

TIP: When using a reset, make sure that all registers in the procedural statement are reset.

Clock Enables
When used properly, clock enables can significantly reduce design power with little impact on
area or performance. However, when clock enables are used improperly, they can lead to:

• Increased resource utilization

• Decreased placement density
• Increased power
• Reduced performance

In most cases, low fanout clock enables are the main contributor to the high number of control
sets.

Creating Clock Enables

Clock enables are created when an incomplete conditional statement is coded into a
synchronous block. A clock enable is inferred to retain the last value when the prior conditions
are not met. When this is the desired functionality, it is valid to code in this manner. However, in
some cases when the prior conditional values are not met, the output is a don't care. In that case,
Xilinx recommends closing off the conditional (that is, use an else clause), with a defined
constant (that is, assign the signal to a one or a zero).

In most implementations, this does not result in added logic, and avoids the need for a clock
enable. The exception to this rule is in the case of a large bus when inferring a clock enable in
which the value is held can help in power reduction. The basic premise is that when small
numbers of registers are inferred, a clock enable can be detrimental because it increases control
set count. However, in larger groups, it can become more beneficial and is recommended.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 54
 Chapter 3: Design Creation with RTL

Reset and Clock Enable Precedence

In Xilinx devices, all registers are built to have set/reset take precedence over clock enable,
whether an asynchronous or synchronous set/reset is described. In order to obtain the most
optimal result, Xilinx recommends that you always code the set/reset before the enable (if
deemed necessary) in the if/else constructs within a synchronous block. Coding a clock
enable first forces the reset into the data path and creates additional logic.

Related Information

Clocking Guidelines

Controlling Enable/Reset Extraction with Synthesis Attributes

You can force control set mapping by applying the DIRECT_RESET / DIRECT_ENABLE /
EXTRACT_RESET / EXTRACT_ENABLE attributes as needed to handle the mapping of control
sets for a given structure.

When the design includes a synchronous reset/enable, synthesis creates a logic cone mapped
through the CE/R/S pins when the load is equal to or above the threshold set by the -
control_set_opt_threshold synthesis switch, or creates a logic cone that maps through
the D pin if below the threshold. The default thresholds are:

• 7 series devices: 4
• UltraScale devices: 2

Using DIRECT_ENABLE and DIRECT_RESET

To use control set mapping you can apply attributes to the nets connected to enable/reset
signals, which will force synthesis to use the CE/R pin.

In the following figure, the enable signal (en) is only connected to one flip-flop. Therefore, the
synthesis engine connected the en signal to the FDRE/D pin cone of logic. Note that the CE pin
is tied to logic 1.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 55
 Chapter 3: Design Creation with RTL

Figure 22: Clock Enable Implementation Using Datapath Logic

To override this default behavior, you can use the DIRECT_ENABLE attribute. For example, the
following figure shows how to connect the enable signal (en) to the CE pin of the register by
adding the DIRECT_ENABLE attribute to the port/signal.

Figure 23: Dedicated Clock Enable Implementation Using direct_enable

The following figure shows RTL code in which either global_rst or int_rst can reset the
register. By default, both are mapped to the reset pin cone of logic.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 56
 Chapter 3: Design Creation with RTL

Figure 24: Multiple Reset Conditions Mapped Through Datapath Logic

You can use the DIRECT_RESET attribute to specify which reset signal to connect to the register
reset pin. For example, the following figure shows how to use the DIRECT_RESET attribute to
connect only the global_rst signal to the register FDRE/R pin and connect the int_rst
signal to the FDRE/D cone of logic.

Figure 25: Dedicated Reset Pin Usage Using DIRECT_RESET Attribute

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 57
 Chapter 3: Design Creation with RTL

Pushing the Logic from the Control Pin to the Data Pin
During analysis of critical paths, you might find multiple paths ending at control pins. You must
analyze these paths to determine if there is a way to push the logic into the datapath without
incurring penalties, such as extra logic levels. There is less delay in a path to the D pin than
CE/R/S pins given the same levels of logic because there is a direct connection from the output
of the last LUT to the D input of the FF. The following coding examples show how to push the
logic from the control pin to the data pin of a register.

In the following example, the enable pin of dout_reg[0] has 2 logic levels, and the data pin has 0
logic levels. In this situation, you can improve timing by moving the enable logic to the D pin by
setting the EXTRACT_ENABLE attribute to "no" on the dout register definition in the RTL file.

Figure 26: Critical Path Ending at Control Pin (Enable) of a Register

The following example shows how to separate the combinational and sequential logic and map
the complete logic in to the datapath. This pushes the logic into the D pin, which still has 2 logic
levels.

You can achieve the same structure by setting the EXTRACT_ENABLE attribute to “no.” For more
information on the EXTRACT_ENABLE attribute, see the Vivado Design Suite User Guide: Synthesis
(UG901).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 58
 Chapter 3: Design Creation with RTL

Figure 27: Critical Path Ending at Data Pin of a Register (Disabling Enable Extraction)

Tips for Control Signals

• Check whether a global reset is really needed.
• Avoid asynchronous control signals.
• Keep clock, enable, and reset polarities consistent.
• Do not code a set and reset into the same register element.
• If an asynchronous reset is absolutely needed, remember to synchronize its deassertion.

Know What You Infer

Your code finally has to map onto the resources present on the device. Make an effort to
understand the key arithmetic, storage, and logic elements in the architecture you are targeting.
Then, as you code the functionality of the design, anticipate the hardware resources to which the
code will map. Understanding this mapping gives you an early insight into any potential problem.

The following examples demonstrate how understanding the hardware resources and mapping
can help make certain design decisions:

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 59
 Chapter 3: Design Creation with RTL

• For larger than 4-bit addition, subtraction, and add-sub, a carry chain is generally used and
one LUT per 2-bit addition is used (that is, an 8-bit by 8-bit adder uses 8 LUTs and the
associated carry chain). For ternary addition or in the case where the result of an adder is
added to another value without the use of a register in between, one LUT per 3-bit addition is
used (that is, an 8-bit by 8-bit by 8-bit addition also uses 8 LUTs and the associated carry
chain).
If more than one addition is needed, it may be advantageous to specify registers after every
two levels of addition to cut device utilization in half by allowing a ternary implementation to
be generated.
• In general, multiplication is targeted to DSP blocks. Signed bit widths less than 18x25 (18x27
in UltraScale devices) map into a single DSP Block. Multiplication requiring larger products
might map into more than one DSP block. DSP blocks have pipelining resources inside them.
Pipelining properly for logic inferred into the DSP block can greatly improve performance and
power. When a multiplication is described, three levels of pipelining around it generates best
setup, clock-to-out, and power characteristics. Extremely light pipelining (one-level or none)
might lead to timing issues and increased power for those blocks, while the pipelining
registers within the DSP lie unused.
• Two SRLs with depths of 16 bits or less can be mapped into a single LUT, and single SRLs up
to 32 bits can also be mapped into a single LUT.
• For conditional code resulting in standard MUX components:
○ A 4-to-1 MUX can be implemented into a single LUT, resulting in one logic level.

○ An 8-to-1 MUX can be implemented into two LUTs and a MUXF7 component, still resulting
in effectively one logic (LUT) level.
○ A 16-to-1 MUX can be implemented into four LUTs and a combination of MUXF7 and
MUXF8 resources, still resulting in effectively one logic (LUT) level.
A combination of LUTs, MUXF7, and MUXF8 within the same CLB/slice structure results in a
very small combinational delay. Hence, these combinations are considered as equivalent to
only one logic level. Understanding this code can lead to better resource management, and
can help in better appreciating and controlling logic levels for the data paths.

For general logic, take into account the number of unique inputs for a given register. From that
number, an estimation of LUTs and logic levels can be achieved. In general, 6 inputs or fewer
always results in a single logic level. Theoretically, two levels of logic can manage up to 36 inputs.
However, for all practical purposes, you should assume that approximately 20 inputs is the
maximum that can be managed with two levels of logic. In general, the larger the number of
inputs and the more complex the logic equation, the more LUTs and logic levels are required.

IMPORTANT! Check the availability of hardware resources and how efficiently they are being utilized
early in the design cycle to enable easier modifications. This approach yields better results than waiting
until late in the design cycle during timing closure.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 60
 Chapter 3: Design Creation with RTL

Inferring RAM and ROM

RAM and ROM may be specified in multiple ways. Each has advantages and disadvantages.

• Inference
Advantages:
○ Highly portable

○ Easy to read and understand

○ Self-documenting

○ Fast simulation

Disadvantages:
○ Might not have access to all RAM configurations available

○ Might produce less optimal results

Because inference usually gives good results, it is the recommended method, unless a given
use is not supported, or it is not producing adequate results in performance, area, or power. In
that case, explore other methods.
When inferring RAM, Xilinx recommends that you use the HDL Templates provided in the
Vivado tools. As mentioned earlier, using asynchronous reset impacts RAM inference, and
should be avoided.
• Xilinx Parameterizable Macros (XPMs)
Advantages:
○ Portable between Xilinx device families

○ Fast simulation

○ Support for asymmetric width

○ Predictable quality of results (QoR)

Disadvantages:
○ Limited to supported XPM options

XPMs are built on inference using fixed templates that you cannot modify. Therefore, they can
guarantee QoR and can support features that standard inference does not. When standard
inference does not support the features required, Xilinx recommends you use XPMs instead.
Note: When you compile simulation libraries using compile_simlib, XPMs are automatically
compiled. For more information, see the Vivado Design Suite User Guide: Logic Simulation (UG900).

• Direct Instantiation of RAM Primitives

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 61
 Chapter 3: Design Creation with RTL

Advantages:
○ Highest level control over implementation

○ Access to all capabilities of the block

Disadvantages:
○ Less portable code

○ Wordier and more difficult to understand functionality and intent

• Core from IP catalog

Advantages:
○ Generally more optimized result when using multiple components

○ Simple to specify and configure

Disadvantages:
○ Less portable code

○ Core management

Related Information

Using Vivado Design Suite HDL Templates

Performance Considerations When Implementing RAM

To efficiently infer memory elements, consider these factors affecting performance:

• Using Dedicated Blocks or Distributed RAMs

RAMs can be implemented in either the dedicated block RAM or within LUTs using distributed
RAM. The choice not only impacts resource selection, but can also significantly impact
performance and power.
In general, the required depth of the RAM is the first criterion. Memory arrays described up to
64 bits deep are generally implemented in LUTRAMs, where depths of 32 bits and less are
mapped 2 bits per LUT and depths up to 64-bits can be mapped one bit per LUT. Deeper
RAMs can also be implemented in LUTRAM depending on available resources and synthesis
tool assignment.
Memory arrays deeper than 256 bits are generally implemented in block memory. Xilinx
devices have the flexibility to map such structures in different width and depth combinations.
Familiarize yourself with these configurations to understand the number and structure of
block RAMs used for larger memory array declarations in the code.
• Using the Output Pipeline Register

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 62
 Chapter 3: Design Creation with RTL

Using an output register is required for high performance designs, and is recommended for all
designs. This improves the clock to output timing of the block RAM. Additionally, a second
output register is beneficial, as slice output registers have faster clock to out timing than a
block RAM register. Having both registers has a total read latency of 3. When inferring these
registers, they should be in the same level of hierarchy as the RAM array. This allows the tools
to merge the block RAM output register into the primitive.
• Using the Input Pipeline Register
When RAM arrays are large and mapped across many primitives, they can span a considerable
area of the die. This can lead to performance issues on address and control lines. Consider
adding an extra register after the generation of these signals and before the RAMs. To further
improve timing, use phys_opt_design later in the flow to replicate this register. Registers
without logic on the input will replicate more easily.

Scenarios Preventing Block RAM Output Register Inference

Xilinx recommends that the memory and the output registers are all inferred in a single level of
hierarchy, because this is the easiest method to ensure inference is as intended. There are two
scenarios that will infer a block RAM output register. The first one is when an extra register exists
on the output, and the second is when the read address register is retimed across the memory
array. This can only happen using single port RAM. This is illustrated below:

Figure 28: RAM with Extra Read Register for Block RAM Output Register Inference

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 63
 Chapter 3: Design Creation with RTL

Figure 29: View of RAM Before Address Register Retiming

Certain deviations from these examples can prevent the inference of the output register.

Checking for Multi-Fanout on the Output of Read Data Registers

The fanout of the data output bits from the memory array must be 1 for the second register to
be absorbed by the RAM primitive. This is illustrated in the following figure.

Figure 30: Multiple Fanout Preventing Block RAM Output Register Inference

Checking for Reset Signals on the Address/Read Data Registers

Memory arrays should not be reset. Only the output of the RAM can tolerate a reset. The reset
must be synchronous in order for inference of the output register into the RAM primitive. An
asynchronous reset will cause the register to not be inferred into the RAM primitive. Additionally,
the output signal can only be reset to 0.

The following figure highlights an example of what to avoid to ensure correct inference of RAMs
and output registers.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 64
 Chapter 3: Design Creation with RTL

Figure 31: Checking for Reset On Address/Read Data Registers

Checking for Feedback Structures in Registers

Make sure that registers do not have feedback logic, because this prevents register optimizations.
In the following example, the address register drives both the RAM and the adder, which means
that the register cannot be packed into a block RAM. The resulting circuit is a block RAM in
which the dout register is packed into the RAM to make the RAM fully synchronous. However,
the RAM does not use the output registers (DOA_REG and DOB_REG will be set to '0'), which is
inefficient.

Figure 32: Check for the Presence of Feedback on Registers Around the RAM Block

Mapping Memories to UltraRAM Blocks

UltraRAM is a 4Kx72 memory block with two ports using a single clock. This primitive is only
available in certain UltraScale+™ devices. In these devices, UltraRAM is included in addition to
block RAM resources.

UltraRAM can be used in your design using one of the following methods:

• Rely on synthesis to infer UltraRAMs by setting the ram_style = "ultra" attribute on a

memory declaration in HDL.
• Instantiate Xilinx XPM_MEMORY primitives.
• Instantiate UltraRAM UNISIM primitives.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 65
 Chapter 3: Design Creation with RTL

The following code example shows the instantiation of XPM memory and is available in the HDL
Language templates. Highlighted parameters MEMORY_PRIMITIVE and READ_LATENCY are the
key parameters to infer memory as UltraRAM for high performance.

• MEMORY_PRIMITIVE = "ultra" specifies the memory is to be inferred as UltraRAM.

• READ_LATENCY defines the number of pipeline registers present on the output of the
memory.

Larger memories are mapped to an UltraRAM matrix consisting of multiple UltraRAM cells
configured as row x column structures.

A matrix can be created with single or multiple columns based on the depth. The current default
threshold for UltraRAM column height is 8 and it can be controlled with the attribute
CASCADE_HEIGHT.

The difference between single column and multiple column UltraRAM matrix is as follows:

• Single column UltraRAM matrix uses the built-in hardware cascade without fabric logic.
• Multiple column UltraRAM matrix uses built-in hardware cascade within each column, plus
some fabric logic for connecting the columns. Extra pipelining may be required to maintain
performance. This is inferred by increasing the read latency. The Vivado tools automatically
pack these registers into UltraRAM as required.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 66
 Chapter 3: Design Creation with RTL

Figure 33: Specifying UltraRAM in RTL Code (via XPM)

The preceding example uses a 32 K x 72 memory configuration, which uses eight UltraRAMs. To
increase performance of the UltraRAM, more pipelining registers should be added to the cascade
chain. This is achieved by increasing the read latency integer.

For more information on inferring UltraRAM in Vivado synthesis, see this link in the Vivado
Design Suite User Guide: Synthesis (UG901).

Coding for Optimal DSP and Arithmetic Inference

The DSP blocks within the Xilinx devices can perform many different functions, including:

• Multiplication
• Addition and subtraction
• Comparators
• Counters

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 67
 Chapter 3: Design Creation with RTL

• General logic

The DSP blocks are highly pipelined blocks with multiple register stages allowing for high-speed
operation while reducing the overall power footprint of the resource. Xilinx recommends that
you fully pipeline the code intended to map into the DSP48, so that all pipeline stages are
utilized. To allow the flexibility of use of this additional resource, a set condition cannot exist in
the function for it to properly map to this resource.

DSP48 slice registers within Xilinx devices contain only resets, and not sets. Accordingly, unless
necessary, do not code a set (value equals logic 1 upon an applied signal) around multipliers,
adders, counters, or other logic that can be implemented within a DSP48 slice. Additionally, avoid
asynchronous resets, since the DSP slice only supports synchronous reset operations. Code
resulting in sets or asynchronous resets may produce suboptimal results in terms of area,
performance, or power.

Many DSP designs are well-suited for the Xilinx architecture. To obtain best use of the
architecture, you must be familiar with the underlying features and capabilities so that design
entry code can take advantage of these resources.

The DSP48 blocks use a signed arithmetic implementation. Xilinx recommends code using signed
values in the HDL source to best match the resource capabilities and, in general, obtain the most
efficient mapping. If unsigned bus values are used in the code, the synthesis tools may still be
able to use this resource, but might not obtain the full bit precision of the component due to the
unsigned-to-signed conversion.

If the target design is expected to contain a large number of adders, Xilinx recommends that you
evaluate the design to make greater use of the DSP48 slice pre-adders and post-adders. For
example, with FIR filters, the adder cascade can be used to build a systolic filter rather than using
multiple successive add functions (adder trees). If the filter is symmetric, you can evaluate using
the dedicated pre-adder to further consolidate the function into both fewer LUTs and flip-flops
and also fewer DSP slices as well (in most cases, half the resources).

If adder trees are necessary, the 6-input LUT architecture can efficiently create ternary addition
(A + B + C = D) using the same amount of resources as a simple 2-input addition. This can help
save and conserve carry logic resources. In many cases, there is no need to use these techniques.

By knowing these capabilities, the proper trade-offs can be acknowledged up front and
accounted for in the RTL code to allow for a smoother and more efficient implementation from
the start. In most cases, Xilinx recommends inferring DSP resources.

For more information about the features and capabilities of the DSP48 slice, and how to best
leverage this resource for your design needs, see the 7 Series DSP48E1 Slice User Guide (UG479)
and UltraScale Architecture DSP Slice User Guide (UG579).

Coding Shift Registers and Delay Lines

In general, a shift register is characterized by some or all of the following control and data signals:

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 68
 Chapter 3: Design Creation with RTL

• Clock
• Serial input
• Asynchronous set/reset
• Synchronous set/reset
• Synchronous/asynchronous parallel load
• Clock enable
• Serial or parallel output

Xilinx devices contain dedicated SRL16 and SRL32 resources (integrated in LUTs). These allow
efficiently implemented shift registers without using flip-flop resources. However, these elements
support only LEFT shift operations, and have a limited number of I/O signals:

• Clock
• Clock Enable
• Serial Data In
• Serial Data Out

In addition, SRLs have address inputs (A3, A2, A1, A0 inputs for SRL16) determining the length of
the shift register. The shift register can be a fixed static length or can be dynamically adjusted. In
dynamic mode, each time a new address is applied to the address pins, the new bit position value
is available on the Q output after the time delay to access the LUT.

Synchronous and asynchronous set/reset control signals are not available in the SRL primitives.
However, if your RTL code includes a reset, the Xilinx synthesis tool infers additional logic around
the SRL to provide the reset functionality.

To obtain the best performance when using SRLs, Xilinx recommends that you implement the last
stage of the shift register in the dedicated slice register. Slice registers have a better clock-to-out
time than SRLs. This allows additional slack for the paths sourced by the shift register logic.
Synthesis tools automatically infer this register unless this resource is instantiated or the
synthesis tool is prevented from inferring this type of register because of attributes or cross-
hierarchy boundary optimization restrictions. To infer the extra register, register the dynamically
delayed signal separately in the RTL.

Xilinx recommends that you use the HDL coding styles represented in the Vivado Design Suite
HDL Templates.

When using registers to obtain placement flexibility in the chip, turn off SRL inference using the
following attribute:

SHREG_EXTRACT = "no"

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 69
 Chapter 3: Design Creation with RTL

For more information about synthesis attributes and how to specify the attributes in the HDL
code, see the Vivado Design Suite User Guide: Synthesis (UG901).

Initialization of All Inferred Registers, SRLs, and Memories

The GSR net initializes all registers to the specified initial value in the HDL code. If no initial value
is supplied, the synthesis tool is at liberty to assign the initial state to either zero or one. Vivado
synthesis generally defaults to zero with a few exceptions such as one-hot state machine
encodings.

Any inferred SRL, memory, or other synchronous element may also have an initial state defined
that will be programmed into the associated element upon configuration.

Xilinx highly recommends that you initialize all synchronous elements accordingly. Initialization of
registers is completely inferable by all major device synthesis tools. This lessens the need to add
a reset for the sole purpose of initialization, and makes the RTL code more closely match the
implemented design in functional simulation, as all synchronous element start with a known
value in the device after configuration.

Initial state of the registers and latches VHDL coding example one:

signal reg1 : std_logic := '0'; -- specifying register1 to start as a zero

signal reg2 : std_logic := ‘1’; -- specifying register2 to start as a one
signal reg3 : std_logic_vector(3 downto 0):="1011"; -- specifying INIT
value for
4-bit register

Initial state of the registers and latches Verilog coding example two:

reg register1 = 1’b0; // specifying regsiter1 to start as a zero

reg register2 = 1’b1; // specifying register2 to start as a one
reg [3:0] register3 = 4’b1011; //specifying INIT value for 4-bit register

Another possibility in Verilog is to use an initial statement:

reg [3:0] register3;

initial begin
register3= 4’b1011;
end

Deciding When to Instantiate or Infer

Xilinx recommends that you have an RTL description of your design; and that you let the
synthesis tool do the mapping of the code into the resources available in the device. In addition
to making the code more portable, all inferred logic is visible to the synthesis tool, allowing the
tool to perform optimizations between functions. These optimizations include logic replications;
restructuring and merging; and retiming to balance logic delay between registers.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 70
 Chapter 3: Design Creation with RTL

Synthesis Tool Optimization

When device library cells are instantiated, synthesis tools do not optimize them by default. Even
when instructed to optimize the device library cells, synthesis tools generally cannot perform the
same level of optimization as with the RTL. Therefore, synthesis tools typically only perform
optimizations on the paths to and from these cells but not through the cells.

For example, if an SRL is instantiated and is part of a long path, this path might become a
bottleneck. The SRL has a longer clock-to-out delay than a regular register. To preserve the area
reduction provided by the SRL while improving its clock-to-out performance, an SRL of one delay
less than the actual desired delay is created, with the last stage implemented in a regular flip-flop.

When Instantiation Is Desirable

Instantiation might be desirable when the synthesis tool mapping does not meet the timing,
power, or area constraints; or when a particular feature within a device cannot be inferred.

With instantiation, you have total control over the synthesis tool. For example, to achieve better
performance, you can implement a comparator using only LUTs, instead of the combination of
LUT and carry chain elements usually chosen by the synthesis tool.

Sometimes instantiation may be the only way to make use of the complex resources available in
the device. This can be due to:

• HDL Language Restrictions

For example, it is not possible to describe double data rate (DDR) outputs in VHDL because it
requires two separate processes to drive the same signal.
• Hardware Complexity
It is easier to instantiate the I/O SerDes elements than to create synthesizable description.
• Synthesis Tools Inference Limitations
For example, synthesis tools currently do not have the capability to infer the hard FIFOs from
RTL descriptions. Therefore, you must instantiate them.
If you decide to instantiate a Xilinx primitive, see the appropriate User Guide and Libraries
Guide for the target architecture to fully understand the component functionality,
configuration, and connectivity.
In case of both inference as well as instantiation, Xilinx recommends that you use the
instantiation and language templates from the Vivado Design Suite language templates.

Following are tips:

• Infer functionality whenever possible.

• When synthesized RTL code does not meet requirements, review the requirements before
replacing the code with device library component instantiations.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 71
 Chapter 3: Design Creation with RTL

• Consider the Vivado Design Suite language templates when writing common Verilog and
VHDL behavioral constructs or if necessary instantiating the desired primitives.

Coding Styles to Improve Maximum Frequency

For high performance designs, the coding techniques discussed in this section can mitigate
possible timing hazards.

High Fanouts in Critical Paths

High fanout nets are much easier to deal with early in the design process. What constitutes too
high of a fanout is often dictated by performance requirements and the construction of the
paths. You can use the following techniques to address issues with high fanout nets.

RECOMMENDED: Identify high fanout nets using the report_high_fanout_nets Tcl command
after synthesis. Monitor the impact of these nets on design performance as you progress through the
implementation process.

Reduce Loads in Portions of the Design That Do Not Require It

For high fanout control signals, evaluate whether all coded portions of the design require that
net. Reducing the number of loads can greatly reduce timing problems.

Replicate High Fanout Net Drivers

Register replication can increase the speed of critical paths by making copies of registers to
reduce the fanout of a given signal. This gives the implementation tools more flexibility in placing
and routing the different loads and associated logic. Synthesis tools use this technique
extensively.

Most synthesis tools use a fanout threshold limit to automatically determine whether to
duplicate a register. Lowering this global threshold allows automatic duplication of high fanout
nets. However, it does not allow control over which registers are duplicated or how their loads
are grouped. In addition, the global replication mechanism does not assess timing slack
accurately, which can lead to unnecessary replicated cells, logic utilization increase, and
potentially higher power consumption.

For high frequency designs, a better approach to reducing fanout is to use a balanced tree for the
high fanout signals. Consider manually replicating registers based on the design hierarchy,
because the cells included in a hierarchy are often placed together. For example, in the balanced
reset tree shown in the following figure, the high fanout reset FF RST2 is replicated in RTL to
balance the fanout across the different modules. If required, physical synthesis can perform
further replication to improve WNS based on placement information.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 72
 Chapter 3: Design Creation with RTL

TIP: To preserve the duplicate registers in synthesis, use a KEEP attribute instead of DONT_TOUCH. A
DONT_TOUCH attribute prevents further optimization during physical optimization later in the
implementation flow.

Note: If a LUT1 rather than a register is replicated, it indicates that an attribute or constraint is applied
incorrectly.

Figure 34: High Fanout Reset Transformed to Balanced Reset Tree

block_A block_A

RST2
RST2
rst_gen_inst rst_gen_inst
11
10000 10000

RST1 RST2 RST1

1 1 20000 1
block_B block_B

RST2
2
3000 3000

block_C block_C

block_D block_D

RST2
3
7000 6000 6000

block_E block_E

RST2
4
1000 1000

X20034-110617

RECOMMENDED: Using MAX_FANOUT attributes on global high fanout signals leads to suboptimal
replication similar to when the global fanout limit is lowered in synthesis. For this reason, Xilinx
recommends only using MAX_FANOUT inside the hierarchies on local signals with medium to low fanout.

Do not replicate registers used for synchronizing signals that cross clock domains. The presence
of the ASYNC_REG attribute on these registers prevents the tool from replicating these registers.
If the synchronizing chain has a very high fanout and replication must meet timing, add an extra
register after the synchronization chain that does not have the ASYNC_REG constraint.

The following table provides guidelines on the number of fanouts that might be acceptable for
your design.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 73
 Chapter 3: Design Creation with RTL

Table 1: Fanout Guidelines for Medium Performance 7 Series Devices

Condition Fanout > 5000 Fanout > 200 Fanout > 100
Low Frequency 1 to 125 Few logic levels between N/A N/A
MHZ synchronous logic <13 levels
of logic at maximum
frequency
Medium Frequency 125 If the design does not meet <6 levels of logic at maximum N/A
to 250 MHz timing, you might need to frequency. (Driver and load
reduce fanout and/or logic types impact performance.)
levels.
High Frequency > 250 Not recommended for most Small number of logic levels is Advance pipelining methods
MHz designs. typically necessary for higher required. Careful logic
speeds. replication. Compact
functions. Low logic levels
required. (Driver and load
types impact performance.)

TIP: If the timing reports indicate that high-fanout signals are limiting the design performance, consider
replicating the signals using the implementation tool options, such as opt_design -
hier_fanout_limit, place_design, and phys_opt_design.

TIP: When replicating registers, consider using a naming convention for the registers, such as
<original_name>_a, <original_name>_b, etc., to make it easier to understand intent of the
replication and easier to maintain the RTL code.

Pipelining Considerations
Another way to increase performance is to restructure long datapaths with several levels of logic
and distribute them over multiple clock cycles. This method allows for a faster clock cycle and
increased data throughput at the expense of latency and pipeline overhead logic management.

Because devices contain many registers, the additional registers and overhead logic are usually
not an issue. However, the datapath spans multiple cycles, and you must make special
considerations for the rest of the design to account for the added path latency.

Consider Pipelining for SSI Devices

When designing high performance register-to-register connections for SLR boundary crossings,
the appropriate pipelining must be described in the HDL code and controlled at synthesis. This
ensures that the shift register LUT (SRL) inference and other optimizations do not occur in the
logic path that must cross an SLR boundary. Modifying the code in this manner along with
appropriate use of Pblocks defines where the SLR boundary crossing occurs.

Consider Pipelining Up Front

Considering pipelining up front rather than later on can improve timing closure. Adding pipelining
at a later stage to certain paths often propagates latency differences across the circuit. This can
make one seemingly small change require a major redesign of portions of the code.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 74
 Chapter 3: Design Creation with RTL

Identifying pipelining opportunities early in the design can often significantly improve timing
closure, implementation runtime (due to easier-to-solve timing problems), and device power (due
to reduced switching of logic).

Check Inferred Logic

As you code your design, be aware of the logic being inferred. Monitor the following conditions
for additional pipelining considerations:

• Cones of logic with large fanin

For example, code that requires large buses or several combinational signals to compute an
output.
• Blocks with restricted placement or slow clock-to-out or large setup requirements
For example, block RAMs without output registers or arithmetic code that is not appropriately
pipelined.
• Forced placement that causes long routes
For example, a pinout that forces a route across the chip might require pipelining to allow for
high-speed operation.
• Logic comprised of large XOR functions
Large XOR functions often have high switch rates that can generate large dynamic power
dissipation. Pipelining these functions can reduce switching, which positively impacts power
consumption of the described circuit.

In the following figure the clock speed is limited by the following:

• Clock-to out-time of the source flip-flop

• Logic delay through four levels of logic
• Routing associated with the four function generators
• Setup time of the destination register

Figure 35: Before Pipelining

reg0 reg1

D Q D Q
LUT LUT LUT LUT

Slow_Clock
X13429-042122

Use one of the following methods to ensure that your design uses pipeline registers correctly:

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 75
 Chapter 3: Design Creation with RTL

• In your RTL code, add the registers before or after the logic to be retimed, preferably within
the hierarchy.
• Use the Vivado synthesis global retiming or BLOCK_SYNTH.RETIMING option, which
analyzes the timing of a path and moves the registers to improve timing, if possible.
• Alternatively, for more control, use the retiming_forward and retiming_backward
synthesis attributes. You can add these attributes on specific registers to force the tool to
retime through combinational logic regardless of the timing score of the logic. For more
information on these attributes, see the Vivado Design Suite User Guide: Synthesis (UG901).

The following figure shows the pipelining after adding extra registers.

Figure 36: Pipelining After Adding Extra Registers

reg0 reg1 reg2 reg3 reg4

D Q D Q D Q D Q D Q
LUT LUT LUT LUT

Slow_Clock
X26546-042122

The following figure is an example of the same data path shown in the Before Pipelining diagram.
Because the flip-flop is contained in the same slice as the function generator, the clock speed is
limited by the clock-to-out time of the source flip-flop, the logic delay through one level of logic,
one routing delay, and the setup time of the destination register. In this example, the system
clock runs faster after pipelining and retiming than in the original design.

Figure 37: Pipelining After Retiming

reg0 reg1_bret reg2_bret reg3_bret reg4

D Q D Q D Q D Q D Q
LUT LUT LUT LUT

Fast_Clock
X13430-041422

Following is a code example that shows how to use the retiming attributes to force the specific
retiming shown in the Pipelining After Retiming figure.

(* retiming_backward = 3 *) reg reg1;

(* retiming_backward = 2 *) reg reg2;
(* retiming_backward = 1 *) reg reg3;

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 76
 Chapter 3: Design Creation with RTL

Determine Whether Pipelining is Needed

A commonly used pipelining technique is to identify a large combinatorial logic path, break it into
smaller paths, and introduce a register stage between these paths, ideally balancing each pipeline
stage.

To determine whether a design requires pipelining, identify the frequency of the clocks and the
amount of logic distributed across each of the clock groups. You can use the
report_design_analysis Tcl command with the -logic_level_distribution option
to determine the logic-level distribution for each of the clock groups.

TIP: The design analysis report also highlights the number of paths with zero logic levels, which you can
use to determine where to make modifications in your code.

Balance Latency
To balance the latency by adding pipeline stages, add the stage to the control path and not the
data path. The data path includes wider buses, which increases the number of flip-flop and
register resources used.

For example, if you have a 128-bit data path, 2 stages of registers, and a requirement of 5 cycles
of latency, inserting 3 register stages results in an extra 3 x 128 = 384 flip-flops. Alternatively,
you can use registers to control logic to enable the data path. Use 5 stages of single-bit registers
to control the enable signal of datapath flip-flops and multicycle path timing exceptions
accordingly.

Note: This example is only possible for certain designs. For example, in cases where there is a fanout from
the intermediate data path flip-flops, having only 2 stages does not work.

RECOMMENDED: The optimal LUT:FF ratio in a device is 1:1. Designs with significantly more FFs will
increase unrelated logic packing into slices, which will increase routing complexity and can degrade QoR.

Balance Pipeline Depth and SRL Usage

When there are deep register pipelines, map as many registers as possible into the SRLs to avoid
significant increases in register utilization. For example, a 9-deep pipeline for a data width of 32
results in 9 registers for each bit, which uses 32 x 9 = 288 registers. Mapping the same structure
to SRLs uses 32 SRLs. Each SRL has address pins A4 through A0 connected to 5'b01000 to
implement a depth of 9 stages.

There are multiple ways to infer SRLs during synthesis, including the following:

• SRL
• REG -> SRL
• SRL -> REG
• REG -> SRL -> REG

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 77
 Chapter 3: Design Creation with RTL

You can create these structures using the srl_style attribute in the RTL code as follows:

• (* srl_style = "srl" *)
• (* srl_style = "reg_srl" *)
• (* srl_style = "srl_reg" *)
• (* srl_style = "reg_srl_reg" *)

A common mistake is to use different enable/reset control signals in deeper pipeline stages.
Following is an example of a reset used in a 9-deep pipeline stage with the reset connected to
the third, fifth, and eighth pipeline stages. With this structure, the tools map the pipeline stages
to registers only, because there is a reset pin on the SRL primitive.

FF->FF->FF(reset) -> FF->FF(reset)->FF->FF->FF(reset)->FF

To take advantage of SRL inference:

• Ensure there are no resets for the pipeline stages.

• Analyze whether the reset is really required.
• Use the reset on one flip-flop (for example, on the first or last stage of the pipeline).

Avoid Unnecessary Pipelining

For highly utilized designs, too much pipelining can lead to suboptimal results. For example,
unnecessary pipeline stages increase the number of flip-flops and routing resources, which might
limit the place and route algorithms if the utilization is high.

Note: If there are many paths with 0/1 levels of logic, check to make sure this is intentional.

Consider Pipelining Macro Primitives

Based on the target architecture, dedicated primitives such as block RAMs and DSPs can work at
over 500 MHz if enough pipelining is used. For high frequency designs, Xilinx recommends using
all of the pipelines within these blocks.

Auto-Pipelining Considerations
The auto-pipelining feature allows the placer to determine the number of required pipeline
stages and their optimal location, which helps timing closure across interface boundaries. You can
enable this feature by setting up the auto-pipelining mode of the AXI Register Slice core or by
applying the auto-pipelining HDL attribute or XDC constraints for data buses. Because the
insertion is timing-driven, always be sure to apply proper timing constraints on the targeted
paths. For more information, see this link in the Vivado Design Suite User Guide: Implementation
(UG904).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 78
 Chapter 3: Design Creation with RTL

The following example shows auto-pipelining applied on the interface between the module
data01 and data12. The output from data01 consists of registers with no control sets.

Figure 38: Simple Data Flow Connections Between Modules

Following is the RTL code for this example. The autopipeline_module attribute is applied on the
hierarchical module data01, and the autopipeline_group/autopipeline_limit/autopipeline_include
attributes are applied on the nets directly driven by the Q pins of the registers.

data_reg_ap #( .C_DATA_WIDTH(C_DATA_WIDTH)) data01 (

.clk (clk),
.datain (shinreg),
.datareg (d1)
);

data_reg #( .C_DATA_WIDTH(C_DATA_WIDTH)) data12 (

.clk (clk),
.datain (d1),
.datareg (d2)
);

(* autopipeline_module="yes" *)
module data_reg_ap # (
parameter integer C_DATA_WIDTH = 32
)
( input wire clk,
input wire [C_DATA_WIDTH-1:0] datain,
(* autopipeline_group="fwd",autopipeline_limit=24 *)
output reg [C_DATA_WIDTH-1:0] datareg
);

always @(posedge clk) begin

datareg <= datain;
end
endmodule

Following are the XDC constraints for this example, which is an alternative approach to using
attributes in the RTL code.

# It's suggested to add the USER_SLR_ASSIGNMENT property at the module

level to ensure better logic clustering with its driver and load, see UG912
for more details on this property
set_property USER_SLR_ASSIGNMENT APSRC [get_cells data01]
set_property USER_SLR_ASSIGNMENT APDST [get_cells data12]

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 79
 Chapter 3: Design Creation with RTL

set_property AUTOPIPELINE_MODULE TRUE [get_cells data01]

set_property AUTOPIPELINE_GROUP WBUS [get_nets -of [get_pins -filter
REF_PIN_NAME==Q -of [get_cells data01/*]]]
set_property AUTOPIPELINE_LIMIT 10 [get_nets -of [get_pins -filter
REF_PIN_NAME==Q -of [get_cells data01/*]]]

Coding Styles to Improve Power

Gate Clock or Data Paths
Gating the clock or data paths is a common technique to stop transition when the results of
these paths are not used. Gating a clock stops all driven synchronous loads and prevents data
path signal switching and glitches from continuing to propagate.

Power optimization (power_opt_design) can automatically generate signal gating logic to

reduce switching activity. However, you have information about the application, data flow, and
dependencies that is not available to the tool, which only you can specify.

Maximize Gating Elements

Maximize the number of elements affected by the gating signal. For example, it is more power
efficient to gate a clock domain at its driving source than to gate each load with a clock enable
signal.

Use Clock Enable Pins of Dedicated Clock Buffers

When gating or multiplexing clocks to minimize activity or clock tree usage, use the clock enable
ports of dedicated clock buffers. Inserting LUTs or using other methods to gate-off clock signals
is not efficient for power and timing.

Use Case Block When Priority Encoder Not Needed

When a priority encoding is not needed, use a case block instead of an if-then-else block or
ternary operator.

Inefficient coding example:

if (reg1)
val = reg_in1;
else if (reg2)
val = reg_in2;
else if (reg3)
val = reg_in3;
else val = reg_in4;

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 80
 Chapter 3: Design Creation with RTL

Correct coding example:

(* parallel_case *) casex ({reg1, reg2, reg3})

1xx: val = reg_in1 ;
01x: val = reg_in2 ;
001: val = reg_in3 ;
default: val = reg_in4 ;
endcase

Performance/Power Trade-Off for Block RAMs

There are multiple ways of breaking a memory configuration to serve a particular requirement.
The requirement for a particular design can be performance, power, or a mixture of both.

The following example highlights the different structures that can be generated to achieve your
requirements. Synthesis can limit the cascading of the block RAM for the performance/power
trade-off using the CASCADE_HEIGHT attribute. The usage and arguments for the attribute are
described in the Vivado Design Suite User Guide: Synthesis (UG901).

The following figure shows an example of 8Kx32 memory configuration for higher performance
(timing).

Note: This example applies to UltraScale and UltraScale+ devices only.

Figure 39: RTL Representation of 4Kx32 Using 4Kx8 and CASCADE_HEIGHT=1

In this implementation, all block RAMs are always enabled (for each read or write) and consume
more power.

The following figure shows an example of cascading all the block RAMs for low power.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 81
 Chapter 3: Design Creation with RTL

Figure 40: RTL Representation of 4Kx32 Using 1Kx32 and CASCADE_HEIGHT=4

In this implementation, because one block RAM at a time is selected (from each unit), the
dynamic power contribution is almost half. Block RAMs have a dedicated cascade MUX and
routing structure that allows the construction of wide, deep memories requiring more than one
block RAM primitive to be built in a very power efficient configuration.

The following figure shows an example of how to limit the cascading and gain both power and
performance at the same time, often with no trade-off in performance.

Note: This example applies to UltraScale and UltraScale+ devices only.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 82
 Chapter 3: Design Creation with RTL

Figure 41: RTL Representation of 4Kx32 Using 2Kx16 and CASCADE_HEIGHT=2

Because two block RAMs are selected at a time in this implementation, the dynamic power
contribution is better than for the high performance structure, but not as good as for the low
power structure. The advantage with this structure compared to a low power structure is that it
uses only two block RAMs in the cascaded path, which has impact on the target frequency when
compared to four block RAMs in the critical path for the low power structure.

Decomposing Deeper Memory Configurations for

Balanced Power and Performance
When working with deeper memory configurations, you can use the RAM_DECOMP synthesis
attribute in the RTL to reduce power by improving memory composition. When the
RAM_DECOMP attribute is applied to a memory array, the memory logic is mapped to a wider
array of block RAM primitives. To balance power and performance, you can control cascading
using the CASCADE_HEIGHT attribute along with the RAM_DECOMP attribute. This approach
requires more address decoding logic but helps to reduce the number of block RAMs that are
enabled for each read operation, which helps to reduce power.

For example, the following figure shows a 32x16K memory configuration.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 83
 Chapter 3: Design Creation with RTL

Figure 42: 32x16K Memory Configuration

If you apply the following attributes:

ram_decomp = "power"
cascade_height = 4

16 RAMB36E2 is inferred and the memory is decomposed as follows:

• The base primitive is 32x1K.

• 4 block RAMs are cascaded to create a 32x4K configuration.
• 4 parallel structures create a 16K deep memory.
• The outputs are multiplexed to generate the output data.

Figure 43: Generated Structure for 32x16K Memory Configuration Example Using
CASCADE_HEIGHT and RAM_DECOMP Attributes

32
32x1K 32x1K 32x1K 32x1K

32
32x1K 32x1K 32x1K 32x1K
32

32
32x1K 32x1K 32x1K 32x1K

32
32x1K 32x1K 32x1K 32x1K

4:1 MUX
X19283-121919

The following RTL code example shows the use of the CASCADE_HEIGHT and RAM_DECOMP
attributes.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 84
 Chapter 3: Design Creation with RTL

Figure 44: RTL Code for 32x16K Memory Configuration Using the CASCADE_HEIGHT and
RAM_DECOMP Attributes

If you apply only the ram_decomp = "power" attribute, 16 RAMB36E2 are inferred and the
memory is decomposed as follows:

• The base primitive is 32x1K.

• 8 block RAMs are cascaded to create a 32x8K configuration.
• 2 parallel structures create a 16K deep memory.
• The outputs are multiplexed into a 2:1 MUX to generate the output data.

Figure 45: Generated Structure for 32x16K Memory Configuration Using the
RAM_DECOMP Attribute

0 1 6 7
32
32x1K 32x1K 32x1K 32x1K
32

32
32x1K 32x1K 32x1K 32x1K

2:1 MUX
X19284-050517

The following RTL code example shows the use of the RAM_DECOMP attribute.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 85
 Chapter 3: Design Creation with RTL

Figure 46: RTL Code for 32x16K Memory Configuration Using the RAM_DECOMP
Attribute

If you use only the RAM_DECOMP attribute, the overall power savings is similar to using both
the RAM_DECOMP and CASCADE_HEIGHT attributes together, because only one block RAM is
active at a time. Creating a 4-deep cascaded block RAM chain is better for performance when
compared to an 8-deep cascaded block RAM chain.

For more information, see this link in the Vivado Design Suite User Guide: Synthesis (UG901).

Running RTL DRCs

A set of RTL DRC rules identify potential coding issues with your HDL. You can perform these
checks on the elaborated views, which you can open by clicking Open Elaborated Design in the
Flow Navigator. You can run these DRC checks by selecting RTL Analysis → Report Methodology
in the Flow Navigator or by executing report_methodology at the Tcl command prompt.

Clocking Guidelines
Each device architecture has some dedicated resources for clocking. Understanding the clocking
resources for your device architecture can allow you to plan your clocking to best utilize those
resources. Most designs might not need you to be aware of these details. However, if you can
control the placement and have a good idea of the fanout on each of the clocking domains, you
can explore alternatives based on the following clocking details. If you decide to exploit any of
these clocking resources, you need to explicitly instantiate the corresponding clocking element.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 86
 Chapter 3: Design Creation with RTL

UltraScale Device Clocking

UltraScale devices have a different clocking structure from previous device architectures, which
blurs the line between global versus regional clocking. UltraScale devices do not have regional
clock buffers like 7 series devices and instead use a common buffer and clock routing structure
whether the loads are local/regional or global.

UltraScale devices feature smaller clock regions of a fixed size across devices, and the clock
regions no longer span half of the device width in the horizontal direction. The number of clock
regions per row varies per UltraScale device. Each clock region contains a clock network routing
that is divided into 24 vertical and horizontal routing tracks and 24 vertical and horizontal
distribution tracks. The following figure shows a device with 36 clock regions (6 columns x 6
rows). The equivalent 7 series device has 12 clock regions (2 columns x 6 rows).

Figure 47: UltraScale Device Clock Region Tiles

Clock Routing and Distribution Tracks

Clock Region Boundary

CLB, DSP,
Clocking I/O GTH/Y
BRAM
X15241-122019

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 87
 Chapter 3: Design Creation with RTL

The clocking architecture is designed so that only the clock resources necessary to connect clock
buffers and loads for a given placement are used, and no resource is wasted in clock regions with
no loads. The efficient clock resource utilization enables support for more design clocks in the
architecture while improving clock characteristics for performance and power. Following are the
main categories of clock types and associated clock structures grouped by their driver and use:

• High-Speed I/O Clocks

These clocks are associated with the high-speed SelectIO™ interface bit slice logic, generated
by the PLL, and routed via dedicated, low-jitter resources to the bit slice logic for high-speed
I/O interfaces. In general, this clocking structure is created and controlled by Xilinx IP, such as
memory IP or the High Speed SelectIO Wizard, and is not user specified.
• General Clocks
These clocks are used in most clock tree structures and can be sourced by a GCIO package
pin, an MMCM/PLL, or fabric logic cells (not generally suggested). The general clocking
network must be driven by BUFGCE/BUFGCE_DIV/BUFGCTRL buffers, which are available in
any clock region that contains an I/O column. Any given clock region can support up to 24
unique clocks, and most UltraScale devices can support over 100 clock trees depending on
their topology, fanout, and load placement.
• Gigabit Transceiver (GT) Clocks
Transmit, receive, and reference clocks of gigabit transceivers (GTH or GTY) use dedicated
clocking in the clock regions that include the GTs. You can use GT clocks to achieve the
following:
○ Drive the general clocking network using the BUFG_GT buffers to connect any loads in the
fabric
○ Share clocks across several transceivers in the same or different Quad

Clock Primitives
Most clocks enter the device through a global clock-capable I/O (GCIO) pin. These clocks directly
drive the clock network via a clock buffer or are transformed by a PLL or MMCM located in the
clock management tile (CMT) adjacent to the I/O column.

The CMT contains the following clocking resources:

• Clock generation blocks

○ 2 PLLs

○ 1 MMCM

• Global clock buffers

○ 24 BUFGCEs

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 88
 Chapter 3: Design Creation with RTL

○ 8 BUFGCTRLs

○ 4 BUFGCE_DIVs

Note: Clocking resources in CMTs that are adjacent to I/O columns with unbonded I/Os are available for
use.

The GT user clocks drive the global clock network via BUFG_GT buffers. There are 24 BUFG_GT
buffers per clock region adjacent to the GTH/GTY columns.

Following is summary information for each of the UltraScale device clock buffers:

• BUFGCE
The most commonly used buffer is the BUFGCE. This is a general clock buffer with a clock
enable/disable feature equivalent to the 7 series BUFHCE.
• BUFGCE_DIV
The BUFGCE_DIV is useful when a simple division of the clock is required. It is considered
easier to use and more power efficient than using an MMCM or PLL for simple clock division.
When used properly, it can also show less skew between clock domains as compared to an
MMCM or PLL when crossing clock domains. The BUFGCE_DIV is often used as replacement
for the BUFR function in 7 series devices. However, because the BUFGCE_DIV can drive the
global clock network, it is considered more capable than the BUFR component.
• BUFGCTRL (also BUFGMUX)
The BUFGCTRL can be instantiated as a BUFGMUX and is generally used when multiplexing
two or more clock sources to a single clock network. As with the BUFGCE and BUFGCE_DIV,
it can drive the clock network for either regional or global clocking.
• BUFG_GT
When using clocks generated by GTs, the BUFG_GT clock buffer allows connectivity to the
global clock network. In most cases, the BUFG_GT is used as a regional buffer with its loads
placed in one or two adjacent clock regions. The BUFG_GT has built-in dynamic clock division
capability that you can use in place of an MMCM for clock rate changes.

You can use the Clock Utilization Report in the Vivado IDE to visually analyze clocking resource
utilization and clock routing. The following figure shows the clock resource utilization per clock
region overlaid in the Device window. For more information on this report, see the Vivado Design
Suite User Guide: Design Analysis and Closure Techniques (UG906).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 89
 Chapter 3: Design Creation with RTL

Figure 48: Clock Utilization Report

For more information on the BUFGCE, BUFGCE_DIV, and BUFGCTRL buffers, see the UltraScale
Architecture Clocking Resources User Guide (UG572). For details on connectivity and use of the
BUFG_GT buffer, see the appropriate UltraScale Architecture Transceiver User Guide:

• UltraScale Architecture GTH Transceivers User Guide (UG576)

• UltraScale Architecture GTY Transceivers User Guide (UG578)

Global Clock Buffer Connectivity and Routing Tracks

Each of the 24 BUFGCE buffers in a clock region can only drive a specific clock routing track.
However, the BUFGCTRL and BUFGCE_DIV outputs can use any of the 24 tracks by going
through a MUX structure. Each BUFGCE_DIV shares the input connectivity with a specific
BUFGCE site, and each BUFGCTRL shares input connectivity with two specific BUFGCE sites.
Consequently, when BUFGCE_DIV or BUFGCTRL buffers are used in the clock region, use of the
BUFGCE buffers is limited. The following figure shows the bottom 6 BUFGCE in a clock region,
which are replicated 4 times within a clock region.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 90
 Chapter 3: Design Creation with RTL

Note: A global clock net is assigned to a specific track ID in the device for all the vertical, horizontal routing,
and distribution resources the clock uses. A clock cannot change track IDs unless the clock goes through
another clock buffer.

Figure 49: BUFGCE, BUFGCE_DIV, and BUFGCTRL Shared Inputs and Output
Multiplexing

Track 23
To Track 5

BUFGCE_X0Y5

BUFGCE_DIV_X0Y0
To Track 4

BUFGCE_X0Y4

BUFGCTRL_X0Y1
To Track 3
BUFGCE_X0Y3

Track 7
MUX
Track 6
To Track 2
BUFGCE_X0Y2 Track 5

Track 4

To Track 1 Track 3

BUFGCE_X0Y1
Track 2

Track 1
BUFGCTRL_X0Y0
To Track 0 Track 0
BUFGCE_X0Y0

X15231-080420

Clock Routing, Root, and Distribution

To properly understand the clocking capacity of an UltraScale device and the clocking utilization
of a design, it is important to know how the clock routes use the dedicated routing resources:

• From the clock buffer to the clock root, the clock signal goes through one or several segments
of vertical and horizontal routing. Each segment must use the same track ID (between 0 and
23).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 91
 Chapter 3: Design Creation with RTL

• At the clock root, the clock signal transitions from the routing track to the distribution track
with the same track ID. To reduce skew, the clock root is usually in the clock region located in
the center of the clock window. The clock window is the rectangular area that includes all the
clock regions where the clock net loads are placed. For skew optimization reasons, the Vivado
IDE might move the clock root to off center.
• From the clock root to the CLB columns where the loads are located, the clock signal travels
on the vertical distribution (both up and down the device as needed) and then onto the
horizontal distribution (both to the left and right as needed).
• The CLB columns are split into two halves, which are located above and below the horizontal
distribution resources. Each half of the CLB column contains several leaf clock routing
resources that can be reached by any of the horizontal distribution tracks.

In some cases, a clock buffer can directly drive onto the clock distribution track. This usually
happens when the clock root is located in the same clock region as the clock buffer or when the
clock buffer only drives non-clock pins (for example, high fanout nets).

Because clock routing resources are segmented, only the routing and distribution segments used
to traverse a clock region or to reach a load in a clock region are consumed.

The following figure shows how a clock buffer located in clock region X2Y1 reaches its loads
placed inside the clock window, which is formed by a rectangle of clock regions from X1Y3 to
X5Y5.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 92
 Chapter 3: Design Creation with RTL

Figure 50: UltraScale Device Clock Routing from Driver to Loads

X1Y5 X5Y5

X3Y4

X1Y3 X5Y3

X2Y1

Design Implementation: UltraScale Architecture:

Clock Buffer (X2Y1) Clock Routing and Distribution Tracks
Clock Root (X3Y4) Clock Region Boundary
Clock Window (X1Y3->X5Y5)
Clock Regions with Loads

X15389-120619

In the following figure, a routed device view shows an example of a global clock that spans most
of the device. The clock buffer driving the network is marked in blue in clock region X2Y0 and
drives onto the horizontal routing in that clock region. The net then transitions from the
horizontal routing onto the vertical routing in clock region X2Y0 reaching the clock root in clock
region X2Y5. All clock routing is marked in blue. The clock root is marked in red in the clock
region X2Y5. From the clock root in X2Y5, the net transitions onto the vertical distribution and
then the horizontal distribution to the clock leaf pins. The distribution layer and the leaf clock
routing resources in the CLB columns are marked in red.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 93
 Chapter 3: Design Creation with RTL

Figure 51: Routed Device View of a Routed Clock Network

Clock Tree Placement and Routing

During the following phases, the Vivado placer determines the placement of MMCM/PLLs, global
clock buffers, and the clock root while honoring the physical XDC constraints:

1. I/O and clock placement

The placer places I/O buffers and MMCM/PLLs based on connectivity rules and user
constraints. The placer assigns clock buffers to clock regions but not to individual sites unless
constrained using the LOC property. Only the clock buffers that only drive non-clock loads
can move to a different clock region later in the flow based on the placement of their driver
and loads.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 94
 Chapter 3: Design Creation with RTL

Any placer error at this phase is due to conflicting connectivity rules, user constraints, or
both. The log file shows extensive information about the possible root cause of the error,
which you must review in detail to make the appropriate design or constraint change.
2. SLR partitioning (SSI technology devices only) and global placement
The placer performs the initial clock tree implementation based on early driver and load
placements. Each clock net is associated with a clock window. The excessive overlap of clock
windows can lead to placer errors due to anticipated clock routing contention.
When a clock partitioning error occurs, the log file shows the last clock budgeting solution
for each clock net as well as the number of unique clock nets present in each clock region.
Review the log file in detail to determine which clocks to remove from the overutilized clock
regions. You can remove clocks using the following methods:
• Reduce the number of clocks in the design by combining identical synchronous clocks,
removing unnecessary MMCM feedback clocks, or consolidating lower fanout clocks with
high fanout clocks.
• Move clock primitives to different clock regions, especially those without connectivity-
based placement rules.
• Add floorplanning constraints on clock loads to keep clocks with smaller fanout closer to
their driver or away from the highly utilized clock regions.
The placer refines the clock tree implementation several times to help improve timing QoR.
For example, during the later placement optimization phases, the placer analyzes each
challenging clock to determine a better clock root location.
3. Clock tree pre-routing
The placer guides the subsequent implementation steps and provides accurate delay
estimates for post-place timing analysis.

After placement, the Vivado tools can modify the clock tree implementation as follows:

• The Vivado physical optimizer can replicate and move cells to clock regions without
associated clocks.
• The Vivado router can make adjustments to improve timing QoR and legalize the clock
routing.

The following table summarizes the placement rules for the main clock topologies and how
constraints affect these rules.

Table 2: Topologies with and without Placement Rules

Constrained Source Unconstrained Destination Behavior

GCIO BUFGCE, BUFGCTRL, BUFGCE_DIV, PLL/ Automatically placed in same clock region.
MMCM
PLL/MMCM BUFGCE, BUFGCTRL, BUFGCE_DIV Automatically placed in same clock region.
GT*_CHANNEL BUFG_GT Automatically placed in same clock region.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 95
 Chapter 3: Design Creation with RTL

Table 2: Topologies with and without Placement Rules (cont'd)

Constrained Source Unconstrained Destination Behavior

BUFGCTRL BUFGCTRL Automatically placed in same clock region.

Note: You can override placement within

same clock region using the
CLOCK_REGION constraint.

BUFG* BUFG* Unpredictable placement of unconstrained

destination BUFG.
Recommend constraining destination
BUFG* using the CLOCK_REGION
constraint.

Note: This excludes BUFGCTRL >

BUFGCTRL.

BUFG* MMCM/PLL Unpredictable placement of unconstrained

destination MMCM/PLL.
Recommend constraining MMCM/PLL
using a LOC constraint.
Recommend CLOCK_DEDICATED_ROUTE
constraint when the route spans adjacent
or multiple clock regions.

Clocking Capability
Clock planning must be based on the total number of high fanout clocks and low fanout clocks in
the target device.

High Fanout Clocks

A high fanout clock spans almost an entire SLR of an SSI technology device or almost all clock
regions of a monolithic device. The following figure shows a high fanout clock that spans almost
an entire SLR with the BUFGCE driver shown in red.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 96
 Chapter 3: Design Creation with RTL

Figure 52: High Fanout Clock Spanning an SLR

Note: Using more than 24 clocks in a design might cause issues that require special design considerations
or other up-front planning.

IMPORTANT! In ZHOLD and BUF_IN compensation modes, the MMCM feedback clock path matches the
CLKOUT0 clock path in terms of routing track, clock root location, and distribution tracks. Therefore, the
feedback clock can be considered a high fanout clock when the clock buffer and clock root are far apart.

Related Information

I/O Timing with MMCM ZHOLD/BUF_IN Compensation

Low Fanout Clocks

In most cases, a low fanout clock is a clock net that is connected to less than 5,000 clock pins,
which are placed in 3 or fewer horizontally adjacent clock regions. The clock routing, clock root,
and clock distribution are all contained within the localized area.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 97
 Chapter 3: Design Creation with RTL

In some cases, the placer is expected to identify a low fanout clock but fails. This can be caused
by design size, device size, or physical XDC constraints, such as a LOC constraint or Pblock,
which prevent the placer from placing the loads in a local area. To address this issue, you might
need to guide the tool by manually creating a Pblock or modifying the existing physical
constraints.

Clocks driven by BUFG_GTs are an example of a low fanout clock. The Vivado placer
automatically identifies these clock nets and contains the loads to the clock regions adjacent to
the GT interface. The following figure shows a low fanout clock contained in two clock regions
with the BUFG_GT driver shown in red.

TIP: To contain a low fanout clock to a single clock region, you can use the CLOCK_LOW_FANOUT XDC
constraint.

Figure 53: Low Fanout Clock Contained in Two Clock Regions

Related Information

Using the CLOCK_LOW_FANOUT Constraint

Balanced Utilization of High and Low Fanout Clocks

UltraScale devices support more clocks than previous Xilinx device families. This enables a wide
range of clocking utilization scenarios, such as the following:

• 24 clocks or less

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 98
 Chapter 3: Design Creation with RTL

Unless conflicting user constraints exist, all clocks can be treated as high fanout clocks
without risking placement or routing contention.
• Almost 300 clocks
For a design that targets a device with 6 clock region rows and includes only low fanout clocks
with each clock included in 3 clock regions at most, the following clocks are required: 6 rows x
2 clock windows per row x 24 clocks per region = 288 clocks.

Low fanout clock windows do not have a fixed size but are usually between 1 and 3 clock
regions. High fanout clocks rarely span the entire device or an entire SLR.

The following method shows how to balance high fanout clocks and low fanout clocks, assuming
that a few low fanout clocks come from I/O interfaces and most from GT interfaces. You can
apply the same method for each SSI technology device SLR.

• High fanout clocks

○ Up to 12 for monolithic devices

○ Up to 24 for SSI technology devices (assuming some high fanout clocks are only present in
1 SLR)
• Low fanout clocks
○ Up to 12 plus 8 per GT utilized Quad

○ Alternatively, up to 12 plus 6 per GT interface (group of GT channels that share the

RXUSRCLK and TXUSRCLK)

Clock Constraints
Physical XDC constraints drive the implementation of clock trees and control the use of high
fanout clocking resources. Because UltraScale device clocking is more flexible than clocking with
previous architectures and includes additional architectural constraints, it is important to
understand how to properly constrain your clocks for implementation.

Using LOC Constraints for IO/MMCM/PLL/GT

To constrain clocks, you can assign placement constraints as follows:

• On a clock input at the I/O port

Assigning a PACKAGE_PIN constraint for a clock on a GCIO or assigning a LOC to an IOB
affects the clock network. The MMCM/PLL and clock buffers directly connected to the input
port must be placed in the same clock region.
• On an MMCM or PLL

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 99
 Chapter 3: Design Creation with RTL

The clock buffers directly connected to the MMCM or PLL outputs and the input clock ports
connected to the MMCM or PLL inputs are automatically placed in the same clock region. If
an input clock port and an MMCM or PLL are directly connected and constrained to different
clock regions, you must manually insert a clock buffer and set a CLOCK_DEDICATED_ROUTE
constraint on the net connected to the MMCM or PLL.
• On a GT*_CHANNEL or IBUFDS_GT* cell
The BUFG_GTs driven by the cell are placed in the same clock region.

CAUTION! Xilinx does not recommended using LOC constraints on the clock buffer cells. This method
forces the clock onto a specific track ID, which can result in placement that cannot be legally routed.
Only use LOC constraints to place high fanout clock buffers in UltraScale devices when you understand
the entire clock tree of the design and when placement is consistent in the design. Even after taking
these precautions, collisions might occur during implementation due to design or constraint changes.

Using the CLOCK_REGION Property on Clock Buffers

You can use the CLOCK_REGION constraint to assign a clock buffer to a clock region without
specifying a site. This gives the placer more flexibility when optimizing all the clock trees and
when determining the appropriate buffer sites to successfully route all clocks.

You can also use a CLOCK_REGION constraint to provide guidance on the placement of
cascaded clock buffers or clock buffers driven by non-clocking primitives, such as fabric logic.

In the following example, the XDC constraint assigns the clkgen/clkout2_buf clock buffer to
the CLOCK_REGION X2Y2.

set_property CLOCK_REGION X2Y2 [get_cells clkgen/clkout2_buf]

Note: In most cases, the clock buffers are directly driven by input clock ports, MMCMs, PLLs, or
GT*_CHANNELs that are already constrained to a clock region. If this is the case, the clock buffers are
automatically placed in the same clock region, and you do not need to use the CLOCK_REGION constraint.

Using a Pblock to Restrict Clock Buffer Placement

When a clock buffer does not need to be placed in a specific clock region, you can use a Pblock
to specify a range of clock regions. For example, use a Pblock when a BUFGCTRL is needed to
multiplex two clocks that are located in different areas. You can assign the BUFGTRL to a Pblock
that includes the clock regions between the two clock drivers and let the placer identify a valid
placement.

Note: Xilinx does not recommend using a Pblock for a single clock region.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 100
 Chapter 3: Design Creation with RTL

Using the USER_CLOCK_ROOT Property on a Clock Net

You can use the USER_CLOCK_ROOT property to force the clock root location of a clock driven
by a clock buffer. Specifying the USER_CLOCK_ROOT property influences the design placement,
because it impacts both insertion delay and skew by modifying the clock routing. The
USER_CLOCK_ROOT value corresponds to a clock region, and you must set the property on the
net segment directly driven by the high fanout clock buffer. Following is an example:

set_property USER_CLOCK_ROOT X2Y3 [get_nets clkgen/wbClk_o]

Figure 54: USER_CLOCK_ROOT Applied on the Net Segment Driven by the Clock Buffer

After placement, you can use the CLOCK_ROOT property to query the actual clock root as
shown in the following example. The CLOCK_ROOT reports the assigned root whether it was
user assigned or automatically assigned by the Vivado tools.

get_property CLOCK_ROOT [get_nets clkgen/wbClk_o]

=> X2Y3

Another way to review the clock root assignments of your implemented design is to use the
report_clock_utilization Tcl command. For example:

report_clock_utilization -clock_roots_only

The following figure shows this report.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 101
 Chapter 3: Design Creation with RTL

Figure 55: report_clock_utilization Clock Root Assignments

Using the CLOCK_DELAY_GROUP Constraint on Several Clock Nets

You can use the CLOCK_DELAY_GROUP constraint to match the insertion delay of multiple,
related clock networks driven by different clock buffers. This constraint is commonly used to
minimize skew on synchronous CDC timing paths between clocks originating from the same
MMCM, PLL, or GT source. You must set the CLOCK_DELAY_GROUP constraint on the net
segment directly connected to the clock buffer. The following example shows the clk1_net and
clk2_net clock nets, which are directly driven by the clock buffers:

set_property CLOCK_DELAY_GROUP grp12 [get_nets {clk1_net clk2_net}]

Related Information

Synchronous CDC

Using the CLOCK_DEDICATED_ROUTE Constraint

The CLOCK_DEDICATED_ROUTE constraint is typically used when driving from a clock buffer in
one clock region to an MMCM or PLL in another clock region. By default, the
CLOCK_DEDICATED_ROUTE constraint is set to TRUE, and the buffer/MMCM or PLL pair must
be placed in the same clock region.

Note: Using the 7 series CLOCK_DEDICATED_ROUTE value of BACKBONE on an UltraScale device

results in the same behavior as SAME_CMT_COLUMN.

The following table summarizes the different CLOCK_DEDICATED_ROUTE constraint values,

use, and behavior.

Table 3: UltraScale Device CLOCK_DEDICATED_ROUTE Constraint Summary

Value Use Behavior

TRUE Default value on clock nets Global clock buffer and
MMCM/PLLs must be
placed in the same clock
region.
This value ensures the net
is routed using only global
clock resources.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 102
 Chapter 3: Design Creation with RTL

Table 3: UltraScale Device CLOCK_DEDICATED_ROUTE Constraint Summary (cont'd)

Value Use Behavior

SAME_CMT_COLUMN Net driven by a global clock buffer MMCM/PLLs must be
(BACKBONE) Example: placed in a clock region in
the same vertical column.
set_property CLOCK_DEDICATED_ROUTE SAME_CMT_COLUMN \ This value ensures the net
[get_nets -of [get_pins BUFGCE_inst/O]] is routed using only global
clock resources.
For optimal results, Xilinx
recommends using a LOC
constraint on the
MMCM/PLL to control
placement of the
MMCM/PLL within in the
same vertical column.
ANY_CMT_COLUMN Net driven by a global clock buffer MMCM/PLLs can be placed
Examples: in any clock region with
available resources.
set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN \ This value ensures the net
[get_nets -of [get_pins BUFGCE_inst/O]] is routed using only global
set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN \ clock resources.
[get_nets -of [get_pins BUFGCE_DIV_inst/O]]
set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN \ For optimal results, Xilinx
[get_nets -of [get_pins BUFGCTRL_inst/O]] recommends using a LOC
constraint on the
MMCM/PLL to control
placement of the
MMCM/PLL within the
device.
FALSE Clock net not driven by a global clock buffer but part of the clock Net is routed using fabric
network (for example, nets driven by the output of an IBUF or nets and global clock resources.
directly connected to output clock pins of an MMCM) This can adversely affect
Examples: the timing and
performance of the clock
set_property CLOCK_DEDICATED_ROUTE FALSE \ network.
[get_nets -of [get_pins MMCME4_ADV_inst/CLKOUT0]]
set_property CLOCK_DEDICATED_ROUTE FALSE \ IMPORTANT! For
[get_nets -of [get_pins IBUF_inst/O]]
UltraScale devices, the
FALSE value must only be
used when a clock
normally routed with
global clock resources
needs to be routed with
fabric resources for
special design reasons.

Note: When working with UltraScale devices, do not apply the CLOCK_DEDICATED_ROUTE property to
the net driven directly by a port. Instead, apply the CLOCK_DEDICATED_ROUTE property to the output
of the IBUF.

Constraint Example for Vertically Adjacent Clock Regions

When driving from a clock buffer in one clock region to a MMCM or PLL in a vertically adjacent
clock region, set the CLOCK_DEDICATED_ROUTE to BACKBONE for 7 series devices or to
SAME_CMT_COLUMN for UltraScale devices for optimal results. This can prevent
implementation errors and ensures that the clock is routed with global clock resources only. In
some cases, the placer can legally place two or fewer MMCMs or PLLs in vertically adjacent clock

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 103
 Chapter 3: Design Creation with RTL

regions without setting the CLOCK_DEDICATED_ROUTE constraint. In cases where the placer
can find a legal solution for MMCMs or PLLs in vertically adjacent clock regions without the
CLOCK_DEDICATED_ROUTE constraint, it is possible that the resulting solution is sub-optimal
for your design. The following example and figure show a central clock buffer driving two PLLs in
vertically adjacent clock regions above and below.
set_property CLOCK_DEDICATED_ROUTE SAME_CMT_COLUMN [get_nets -of [get_pins BUFG_inst_0/O]]
set_property LOC PLLE3_ADV_X0Y0 [get_cells PLLE3_ADV_inst_0]
set_property LOC PLLE3_ADV_X0Y4 [get_cells PLLE3_ADV_inst_1]

Figure 56: CLOCK_DEDICATED_ROUTE Constraint Set to SAME_CMT_COLUMN

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 104
 Chapter 3: Design Creation with RTL

Constraint Example for Non-Vertically Adjacent Clock Regions

When driving from a clock buffer to other clock regions that are not vertically adjacent, you must
set the CLOCK_DEDICATED_ROUTE to FALSE for 7 series devices or to ANY_CMT_COLUMN
for UltraScale devices. This prevents implementation errors and ensures that the clock is routed
with global clock resources only. The following example and figure show a BUFGCE driving two
PLLs that are not located on the same clock region column as the input buffer.
set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN [get_nets -of [get_pins BUFG_inst_0/O]]
set_property LOC PLLE3_ADV_X1Y0 [get_cells PLLE3_ADV_inst_0]
set_property LOC PLLE3_ADV_X1Y4 [get_cells PLLE3_ADV_inst_1]

Figure 57: CLOCK_DEDICATED_ROUTE Set to ANY_CMT_COLUMN

Using the CLOCK_LOW_FANOUT Constraint

You can use the CLOCK_LOW_FANOUT constraint to contain the loads of a clock buffer in a
single clock region. You can set the CLOCK_LOW_FANOUT constraint on a clock net segment
directly driven by a global clock buffer or on a list of flip-flops.

Note: The CLOCK_LOW_FANOUT constraint takes lower precedence when used with other clocking
constraints. If CLOCK_LOW_FANOUT is in conflict with other clock constraints, such as
USER_CLOCK_ROOT, CLOCK_DELAY_GROUP, or CLOCK_DEDICATED_ROUTE, CLOCK_LOW_FANOUT
is not obeyed.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 105
 Chapter 3: Design Creation with RTL

Constraint Example for Flip-Flops

Setting the CLOCK_LOW_FANOUT constraint on a list of flip-flops driven by a global clock

buffer causes opt_design to create a new parallel global clock buffer to isolate the flip-flops.
During place_design, the isolated flip-flops that are driven by the newly created parallel
global clock buffer are contained to a single clock region.

The following example shows the CLOCK_LOW_FANOUT constraint applied to a list of flip-flops
that are used as part of a clock gating synchronization circuit to control the clock enable of a
global clock buffer.

set_property CLOCK_LOW_FANOUT TRUE [get_cells safeClockStartup_reg[*]]

In the design, an always-on clock network initially drives more than 2000 loads, including the
flip-flops that are part of the clock gating synchronization circuit used to clock gate other logic.
The following schematics show the clock gating synchronization circuit and additional logic
connected to the always-on clock network before and after opt_design creates a new parallel
global clock buffer to isolate the clock gating synchronization circuit.

Figure 58: Schematic Before opt_design Transform with CLOCK_LOW_FANOUT Applied

to Flip-Flops

Figure 59: Schematic After opt_design Transform with CLOCK_LOW_FANOUT Applied to

Flip-Flops

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 106
 Chapter 3: Design Creation with RTL

The Device window of the fully implemented design shows the clock gating synchronization
circuit with green markers along with the always-on logic and clock-gated logic. The clock gating
synchronization circuit is placed in the same CLOCK_REGION as the MMCM, close to the global
clock buffers.

Figure 60: Fully Implemented Design with Placement of Clock Gating Synchronization
Circuit

Constraint Example for Clock Nets

If you set the CLOCK_LOW_FANOUT property on a clock net segment directly driven by a global
clock buffer and the fanout of the global clock buffer is less than 2000 loads, the placement of
the loads is contained to a single clock region.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 107
 Chapter 3: Design Creation with RTL

The following example shows the CLOCK_LOW_FANOUT constraint applied to the clock net
segment directly driven by a global clock buffer. The clock network drives less than 2000 loads
and is contained to a single clock region. The input clock port, clkIn has a PACKAGE_PIN
assignment to a GCIO located in the CLOCK_REGION X2Y0 and drives a PLLE3_ADV. The
PLLE3_ADV drives a global clock buffer that subsequently drives the clock network with 1379
loads. The loads of the global clock buffer are all placed in the CLOCK_REGION X2Y0.

# PACKAGE_PIN AF9 - IOBank 64 - CLOCK_REGION X2Y0

set_property PACKAGE_PIN AF9 [get_ports clkIn]
set_property IOSTANDARD LVCMOS18 [get_ports clkIn]
set_property CLOCK_LOW_FANOUT TRUE [get_nets -of [get_pins
clkOut0_bufg_inst/O]]

Figure 61: CLOCK_LOW_FANOUT Example in the Device Window and Schematic

Window

Clocking Topology Recommendations

Xilinx recommends using simple clock tree topologies with the minimum number of clock buffers
required for the design. Using extra clock buffers requires more routing tracks, which can lead to
placement errors or routing conflicts in clock regions where the clock routing requirement is high
and is close to the maximum capacity.

Following are clocking topology recommendations for BUFGCE/BUFGCTRL/BUFGCE_DIV

connectivity.

Parallel Clock Buffers

Use parallel clock buffers to achieve the following:

• Ensure predictable placement across implementation runs.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 108
 Chapter 3: Design Creation with RTL

When the parallel clock buffers are directly driven by the same input clock port, MMCM, PLL,
or GT*_CHANNEL, the buffers are always placed in the same clock region as their driver
regardless of the netlist changes or logic placement variation.
• Match the insertion delays between parallel branches of the clock tree.
Xilinx recommends parallel buffers over cascaded clock buffers, especially when there are
synchronous paths between the branches. When using cascaded buffers, the clock insertion
delay is not matched between the branches of the clock trees even when using the
CLOCK_DELAY_GROUP or USER_CLOCK_ROOT constraints. This can result in high clock
skew, which makes timing closure challenging if not impossible.

The following figure shows three parallel BUFGCE buffers driven by the MMCM CLKOUT0 port.

Figure 62: Parallel BUFGCE on MMCM Output

Cascaded Clock Buffers

In general, Xilinx does not recommend using cascaded buffers to artificially increase the delay
and reduce the skew between unrelated clock trees branches. Unlike connections between
BUFGCTRLs, other clock buffer connections do not have a dedicated path in the architecture.
Therefore, the relative placement of clock buffers is not predictable, and all placement rules take
precedence over placing unconstrained cascaded buffers.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 109
 Chapter 3: Design Creation with RTL

However, you can use cascaded clock buffers to achieve the following:

• Route the clock to another clock buffer located in a different clock region.
This method is typical when using a clock multiplexer for clocks generated by MMCMs
located in different clock regions. Although one of the MMCMs can directly drive the
BUFGCTRL (BUFGMUX), the other MMCM requires an intermediate clock buffer to route the
clock signal to the other region. The following figure shows an example.

Figure 63: Routing the Clock to Another Clock Region

Clock Region 1

Clock Region 2

X15518-121919

• Balance the number of clock buffer levels across the clock tree branches when there is a
synchronous path between those branches.
For example, consider an MMCM clock called clk0 that drives both group A (sequential cells
driven via a BUFGCTRL located in a different clock region) and group B (sequential cells). To
better match the delay between the branches, insert a BUFGCE for group B and place it in the
same clock region as the BUFGCTRL. This ensures that the synchronous paths between group
A and group B have a controlled amount of skew. The following figure shows an example.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 110
 Chapter 3: Design Creation with RTL

Note: The Vivado logic optimization command opt_design is not aware of the timing relationship
between timing clocks and clock network branches. As a result, opt_design removes as many
cascaded or redundant clock buffers as possible. In this example, opt_design removes
BUFGCE_inst_1 unless you set a DONT_TOUCH="TRUE" property on it. If there are only asynchronous
paths between the clock tree branches, the branches do not need to be balanced as long as there is
proper synchronization circuitry on the receiving clock domain.

Figure 64: Balancing Clock Trees for Synchronous Paths Between Clock Regions

Group A

Synchronous Paths
Clock Region 1

Clock Region 2

Group B

X15519-121919

• Build clock multiplexers as described in Clock Multiplexing.

To reduce the variation of insertion delays and skew, Xilinx recommends the following when
using cascaded clock buffers:

• Keep the cascaded buffers in the same or adjacent clock regions.

• When clock tree branches are balanced, assign all the clock buffers of the same level to the
same clock region.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 111
 Chapter 3: Design Creation with RTL

Note: If absolutely required, Xilinx recommends using two cascaded BUFGCTRLs instead of cascaded
BUFGCEs. Using dedicated routing, you can cascade two adjacent BUFGCTRLs with minimum delay when
both BUFGCTRLs are placed inside the same clock region.

Clock Multiplexing
You can build a clock multiplexer using a combination of parallel and cascaded BUFGCTRLs. The
placer finds the optimal placement based on the clock buffer site availability. If possible, the
placer places BUFGCTRLs in adjacent sites to take advantage of the dedicated cascade paths. If
that is not possible, the placer will attempt to place the BUFGCTRLs from the same level in the
adjacent clock regions.

The following figure shows a 4:1 MUX with balanced cascading. The first level of BUFGCTRL
buffers are both placed in the directly adjacent sites (X0Y2, X0Y0) of the last BUFGCTRL (X0Y1).
This configuration ensures a comparable insertion delay for all the clocks reaching the last
BUFGCTRL. You can use an equivalent structure for a 3:1 MUX.

Figure 65: 4:1 MUX Using Parallel BUFGCTRL

When creating a 5:1 or larger clock MUX structure, it is common to create a symmetrical clock
structure as shown in the following figure. However, this is a suboptimal solution, because each
BUFGCTRL only has one cascade path to the two adjacent BUFGCTRLs, which does not provide
minimal delay for all connections between the BUFGCTRLs.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 112
 Chapter 3: Design Creation with RTL

Figure 66: Non-Recommended 8:1 Balanced Clock MUX Structure

To support larger clock multiplexers (from 5:1 to 8:1 MUX), Xilinx recommends using cascaded
BUFGCTRL buffers as shown in the following figure. This figure shows an optimal 8:1 MUX that
uses 7 BUFGCTRL buffers.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 113
 Chapter 3: Design Creation with RTL

Figure 67: 8:1 MUX Using Cascaded BUFGCTRL

Note: When using wide BUFGCTRL-based clock multiplexers, the clock insertion delays cannot be
balanced because some paths are longer than other paths in hardware. Therefore, this method is
recommended for multiplexing asynchronous clocks only.

PLL/MMCM Feedback Path and Compensation Mode

PLLs do not support delay compensation and always operate in INTERNAL compensation mode,
which means they do not need a feedback path. Similarly, MMCMs set to INTERNAL
compensation mode do not need a feedback path. In both cases, the Vivado tools do not always
automatically remove unnecessary feedback clock buffers. You must remove the clock buffers
manually to reduce the amount of high fanout clock resource utilization. This is especially
important for designs with high clocking usage where clock contention might occur.

When the MMCM compensation is set to ZHOLD or BUF_IN, the placer assigns the same clock
root to the nets driven by the feedback buffer and by all buffers directly connected to the
CLKOUT0 pin. This ensures that the insertion delays are matched so that the I/O ports and the
sequential cells connected to CLKOUT0 are phase-aligned and hold time is met at the device
interface. The Vivado tools consider all the loads of these nets to optimally define the clock root.

The Vivado tools do not automatically match the insertion delay with the other MMCM outputs.
To match the insertion delay for the nets driven by other MMCM output buffers, use the
following properties:

• CLOCK_DELAY_GROUP
Apply the same CLOCK_DELAY_GROUP property value to the nets directly driven by
feedback clock buffer, the CLKOUT0 buffers, and the other MMCM output buffers as needed.
This is the preferred method.
• USER_CLOCK_ROOT

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 114
 Chapter 3: Design Creation with RTL

If you need to force a specific clock root, use the same USER_CLOCK_ROOT property value
on the nets driven by the feedback clock buffer, the CLKOUT0 buffers, and the other MMCM
output buffers as needed.

BUFG_GT Divider
The BUFG_GT buffers can drive any loads in the fabric and include an optional divider you can
use to divide the clock from the GT*_CHANNEL. This eliminates the need to use an extra
MMCM or BUFG_DIV to divide the clock.

SelectIO Clocking
The UltraScale device SelectIO primitives have maximum skew requirements between clock pins.
Using the optimal clocking topology for the SelectIO primitives prevents maximum skew
violations, improves interface timing between the UltraScale device and the fabric logic, and uses
fewer clocking resources.

ISERDESE3 and IDDRE1 Clocking

For ISERDESE3 and IDDRE1 clocking in UltraScale and UltraScale+ devices, maximum skew
requirements exist between the clock and inverted clock pins. To meet the maximum skew
requirements, Xilinx recommends using a single net for the clock and inverted clock pins when
using the local inversion.

In the following figure, the left side shows a suboptimal configuration that uses the CLKOUT0B
output of the MMCM. The right side of the figure shows the optimal configuration that uses the
local inversion on the CLK_B and CB pins of the ISERDESE3 and IDDRE1. Using the optimal
configuration guarantees that the maximum skew requirement is met while using fewer global
clock resources.

Figure 68: Suboptimal to Optimal Clocking Topologies for ISERDESE3 and IDDRE1

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 115
 Chapter 3: Design Creation with RTL

OSERDESE3 Clocking
For OSERDESE3 clocking in UltraScale and UltraScale+ devices, maximum skew requirements
exist between the high-speed clock and divided clock pins. To meet the maximum skew
requirements, Xilinx recommends using parallel global clock buffers where one of the global clock
buffers is a BUFGCE_DIV. This removes the additional clock uncertainty between the two
outputs of the MMCM.

In the following figure, the left side shows a suboptimal configuration that uses two separate
outputs of the MMCM. The right side of the figure shows the optimal configuration that uses a
single MMCM output and the BUFGCE_DIV cell, which provides the divided clock using the
BUFGCE_DIVIDE property.

Note: The high-speed clock does not need to be driven by a BUFGCE. Alternatively, you can use
BUFGCE_DIV with a BUFGCE_DIVIDE property setting of 1.

Figure 69: Suboptimal to Optimal Clocking Topologies for OSERDESE3

I/O Timing with MMCM ZHOLD/BUF_IN Compensation

ZHOLD compensation indicates that the MMCM is configured to provide a negative hold for all
I/O registers of an entire I/O column. When a clock capable I/O (CCIO) drives a single MMCM
that is configured in ZHOLD compensation mode, the placer will attempt to place the MMCM
with the CCIO in the same clock region. In this case, the CCIO can drive the MMCM directly
without going through a BUFG. This allows the ZHOLD compensation of the MMCM to remain
in effect.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 116
 Chapter 3: Design Creation with RTL

However, if a CCIO drives an MMCM configured in ZHOLD mode in addition to another MMCM,
logic optimization will attempt to legalize the clock routing to the MMCMs by inserting a BUFG
after the CCIO. Because the MMCM with ZHOLD compensation is no longer driven directly by a
CCIO, the compensation is changed to BUF_IN. To avoid this, ensure that the CCIO drives the
MMCM configured in ZHOLD mode directly and drives the additional MMCM through a BUFG.
In addition, set the CLOCK_DEDICATED_ROUTE property for the net driven by the BUFG to
ANY_CMT_COLUMN.

Because the clock insertion delay varies with the clock root locations and the clock root
placement depends on placement of the loads, there might be variability between runs. This
variability affects the timing inside the device as well as the I/O timing.

When dealing with high-frequency I/Os, you might want more control over the I/O timing and
less variability between runs. One way to achieve this is to force the clock root placement. You
can run the tool in automated mode and look at the clock root region. If the I/O timing is
satisfactory, you can force the clock root placement on the buffer nets associated with I/O
timing. To determine the placement of the clock roots, use the report_clock_utilization
[-clock_roots_only] Tcl command.

In the following example, the I/O ports are located in the X0Y0 region. The Vivado placer
determined the placement of the clock roots in X1Y2 based on the I/O placement as well as
placement of other loads.

Figure 70: Clock Utilization Summary with Unconstrained Clock Root

The following summary shows the I/O timing when the clock root is unconstrained.

Figure 71: Timing Summary with Unconstrained Clock Root

In the following example, the clock roots are moved next to the I/O registers in X0Y0, which
reduces the clock insertion delays and timing pessimism and therefore, improves the I/O timing.

Figure 72: Clock Utilization Summary with User Constrained Clock Root

The following summary shows the I/O timing when the clock root is moved.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 117
 Chapter 3: Design Creation with RTL

Figure 73: Timing Summary with User Constrained Clock Root

Synchronous CDC
When the design includes synchronous CDC paths between clocks that originate from the same
MMCM/PLL, you can use the following techniques to better control the clock insertion delays
and skew and therefore, the slack on those paths.

IMPORTANT! If the CDC paths are between clocks that originate from different MMCM/PLLs, the clock
insertion delays across the MMCMs/PLLs are more difficult to control. In this case, Xilinx recommends that
you treat these clock domain crossings as asynchronous and make design changes accordingly.

When a path is timed between two clocks that originate from different output pins of the same
MMCM/PLL, the MMCM/PLL phase error adds to the clock uncertainty for the path. For designs
using high clock frequencies, the phase error can cause issues with timing closure both for setup
and hold.

The following figure shows an example of paths both with and without the phase error. Path 1 is
a CDC path clocked by two buffers connected to the same MMCM output and does not include
the phase error. Path 2 is clocked by two clocks that originate from two different MMCM
outputs and does include the phase error.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 118
 Chapter 3: Design Creation with RTL

Figure 74: MMCM and Phase Error

Path 1

Path 2 X15234-121919

When two synchronous clocks from the same MMCM/PLL have a simple period ratio (/2 /4 /8),
you can prevent the phase error between the two clock domains using a single MMCM/PLL
output connected to two BUFGCE_DIV buffers. The BUFGCE_DIV buffer performs the clock
division (/1 /2 /4 /8). Other ratios are possible (/3 /5 /6 /7) but this requires modifying the clock
duty cycle and making mixed edge timing paths more challenging.

Note: Because the BUFGCE and BUFGCE_DIV do not have the same cell delays, Xilinx recommends using
the same clock buffer for both synchronous clocks (two BUFGCE or two BUFGCE_DIV buffers).

The following figure shows two BUFGCE_DIVs that divide the CLKOUT0 clock by 1 and by 2
respectively.

IMPORTANT! To ensure safe timing between parallel BUFGCE_DIV cells where the BUFGCE_DIVIDE
property is set to a value greater than 1, both buffers must use the same enable signal (CE) and the same
reset signal (RST). Otherwise, the divided clocks might become phase shifted from one another in
hardware, which is not reported by the Vivado tools.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 119
 Chapter 3: Design Creation with RTL

Figure 75: MMCM Synchronous CDC with BUFGCE_DIVs Connected to One MMCM
Output

To automatically balance several clocks that originate from the same MMCM or PLL, set the
same CLOCK_DELAY_GROUP property value on the nets driven by the clock buffers that need
to be balanced. Following are additional recommendation:

• Avoid setting the CLOCK_DELAY_GROUP constraint on too many clocks, because this
stresses the clock placer resulting in suboptimal solutions or errors.
• Review the critical synchronous CDC paths in the Timing Summary Report to determine which
clocks must be delay matched to meet timing.
• Limit the use of the CLOCK_DELAY_GROUP on groups of synchronous clocks with tight
requirements and with identical clocking topologies.

IMPORTANT! Xilinx recommends using the Clocking Wizard for creating optimal clocking structures,
which use a mix of BUFGCEs and BUFGCE_DIVs along with related clock grouping constraints.

GT Interface Clocking
Each GT interface requires several clocks, including some clocks that are shared across bonded
GT*_CHANNEL cells located in one or several GT quads. UltraScale devices provide up to 128
GT*_CHANNEL sites, which can lead to the use of several hundreds of clocks in a design. Most
GT clocks have a low fanout with loads placed locally in the clock region next to the associated
GT*_CHANNEL. Some GT clocks drive loads across the entire device and require the utilization
of clock routing resource in many clock regions. The UltraScale architecture includes the
following enhancements to efficiently support the high number of GT clocks required.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 120
 Chapter 3: Design Creation with RTL

BUFG_GT with Dynamic Divider

In UltraScale devices, the BUFG_GT buffer simplifies GT clocking. Because the BUFG_GT
includes dynamic division capabilities, MMCMs are no longer required to perform simple integer
divides on GT output clocks. This saves clocking resources and provides an improved low skew
clock path when both a divided GT*_CHANNEL output clock and full-rate clock are required.

You can use the BUFG_GT global clock buffer for GT interfaces where the user logic operates at
half the clock frequency of the internal PCS logic or for PCIe interfaces where the
GT*_CHANNEL needs to generate multiple clock frequencies for user_clk, sys_clk, and pipe_clk.
The following figure compares clocking requirements between 7 series and UltraScale devices for
a single-lane GT interface where the frequency of TXUSRCLK2 is equal to half of the frequency
of TXUSRCLK.

Figure 76: Clocking Requirements Comparison

7 Series Devices (MMCM used for divide) UltraScale Devices (BUFG_GT used for divide)
LOCKED

BUFG3 BUFG_GT
CLKOUT0
+2
MMCM
1
BUFH/BUFG BUFG_GT
TXOUTCLK CLKOUT1 TXOUTCLK
CLKIN +1

BUFG3

TXUSRCLK22 UltraScale TXUSRCLK2

7 Series
Devices
FPGAs TXUSRCLK2 GTH TXUSRCLK22
Transceiver
Transceiver

Design in
TXDATA (32/40/64/80 Design in TXDATA (32/40/64/80
bits) bits) UltraScale
FPGA
Architecture

X15237-121919

You can use any output clock of the GT*_CHANNELs within a Quad or any reference clock
generated by an IBUFDS_GTE3/ODIV2 pin within a Quad to drive any of the 24 BUFG_GT
buffers located in the same clock region. A BUFG_GT_SYNC is always required to synchronize
reset and clear of BUFG_GTs driven by a common clock source.

Note: The Vivado tools automatically insert the BUFG_GT_SYNC primitive if it is not present in the design.

Some applications still require the use of an MMCM to generate complex non-integer clock
division of the GT output clocks or the IBUFDS_GTE3/ODIV2 reference clock. In these cases, a
BUFG_GT must directly drive the MMCM. By default, the placer tries to place the MMCM on the
same clock region row as the BUFG_GT. If other MMCMs try to use the same MMCM site, you
must verify that the automated MMCM placement is still as close as possible to the BUFG_GT to
avoid wasting clocking resources due to long routes.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 121
 Chapter 3: Design Creation with RTL

Single Quad vs. Multi-Quad Interface

In a multi-channel interface, a master channel can generate [RT]XUSRCLK[2] for all the
GT*CHANNELs of the interface. If a multi-channel interface spans multiple quads, the maximum
allowed distance for a GT*CHANNEL from the reference clock source is 2 clock regions above
and below.

The following figure shows a multi-quad interface. The GT*CHANNELs are marked in yellow, the
TXUSRCLK is highlighted in blue, and the TXUSRCLK2 is highlighted in red. The BUFG_GTs
driving both TXUSRCLK and TXUSRCLK2 are located in the center quad and are marked in blue
and red.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 122
 Chapter 3: Design Creation with RTL

Figure 77: TXUSRCLK/TXUSRCLK2 Clock Routing for a Multi-Quad Interface

If the GT interface is contained within a single Quad, the placer treats the BUFG_GT clocks as
local clocks. In this case, the placer attempts to place the BUFG_GT clock loads in the clock
regions horizontally adjacent to the BUFG_GT, starting with the clock region that contains the
BUFG_GT and potentially using up to half the width of the device.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 123
 Chapter 3: Design Creation with RTL

To override the placer regional clock constraint, assign any of the BUFG_GT clock loads to a
Pblock. The following figure shows a single-quad interface. The GT*CHANNELs are marked in
yellow, the TXUSRCLK is highlighted in blue, and the TXUSRCLK2 is highlighted in red. All the
TXUSRCLK2 loads are placed in the same clock region as the GT*CHANNELs.

Figure 78: TXUSRCLK/TXUSRCLK2 Clock Routing for a Single-Quad Interface

[RT]XUSRCLK/[RT]XUSRCLK2 Skew Matching

When [RT]XUSRCLK2 operates at half the frequency of [RT]XUSRCLK (i.e., separate BUFG_GTs
with divide by 1 and divide by 2), a tight skew requirement exists between the [RT]XUSRCLK/
[RT]XUSRCLK2 pair at each GT*CHANNEL of a GT interface. To meet the skew requirement,
GT*CHANNELs can be a maximum of 2 clock regions above or below the master channel that
generates the [RT]XUSRCLK/[RT]XUSRCLK2 pair. In addition, the placer tightly controls skew as
follows:

• Assigns the BUFG_GT pairs to the upper or lower 12 BUFG_GTs in a Quad

• Assigns the clock root for both clocks close to the clock region containing the BUFG_GTs

RECOMMENDED: To avoid skew violations, Xilinx highly recommends following this clocking topology
when [RT]XUSRCLK2 operates at half the frequency of [RT]XUSRCLK.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 124
 Chapter 3: Design Creation with RTL

Integrated Block for PCI Express CORECLK/PIPECLK/USERCLK Skew Matching

The UltraScale Integrated Block for PCI Express® requires three clocks: CORECLK, USERCLK,
and PIPECLK. The three clocks are sourced by BUFG_GTs driven by the TXOUTCLK pin of one of
the GT*_CHANNELs of the physical interface. A tight skew requirement exists between the
CORCLK and PIPECLK pins and the CORECLK and USERCLK pins. To meet the skew
requirement, the placer tightly controls skew as follows:

• Assigns the BUFG_GTs that drive the three PCIe clocks in groups to the upper or lower 12
BUFG_GTs in a Quad
• Assigns the clock root for all three clocks to the same clock region
Note: For more information on PCIe clocking requirements, see the UltraScale Devices Gen3 Integrated
Block for PCI Express LogiCORE IP Product Guide (PG156).

7 Series Device Clocking

Note: This section uses Virtex®-7 clocking resources as an example. The clocking resources for Virtex-6
devices are similar. If you are using a different architecture, see the 7 Series FPGAs Clocking Resources User
Guide (UG472) or the UltraScale Architecture Clocking Resources User Guide (UG572) depending on your
device.

Virtex-6 and Virtex-7 devices contain thirty-two global clock buffers known as BUFGs. BUFGs
can serve most clocking needs for designs with less demanding needs in terms of number of
clocks, design performance, and clocking control. Global clocking resources include BUFG,
BUFGCE, BUFGMUX, and BUFGCTRL primitives, which each have their own features. For more
information on the features of these global clock components, see the Clocking Resources Guide
(7 Series FPGAs Clocking Resources User Guide (UG472) or UltraScale Architecture Clocking
Resources User Guide (UG572)) and Libraries Guide (Vivado Design Suite 7 Series FPGA and
Zynq-7000 SoC Libraries Guide (UG953) or UltraScale Architecture Libraries Guide (UG974)) for your
device.

RECOMMENDED: If clocking demands exceed the number of BUFGs, or if better overall clocking
characteristics are desired, analyze the clocking needs against the available clocking resources, and select
the best resource for the task.

In addition to global clocking resources, regional clocking resources are also available, which
allow tighter control of clock networks. Regional clocking resources include the Horizontal Clock
Region Buffers (BUFH, BUFHCE), Regional Clock Buffer (BUFR), I/O Clock Buffer (BUFIO), and
Multi-Regional Clock Buffer (BUFMR). For more information on the features of these regional
clock components, see the Clocking Resources Guide (7 Series FPGAs Clocking Resources User
Guide (UG472) or UltraScale Architecture Clocking Resources User Guide (UG572)) and Libraries
Guide (Vivado Design Suite 7 Series FPGA and Zynq-7000 SoC Libraries Guide (UG953) or UltraScale
Architecture Libraries Guide (UG974)) for your device.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 125
 Chapter 3: Design Creation with RTL

Using Horizontal Clock Region Buffers for Clock Gating

You can use the Horizontal Clock Region Buffer (BUFHCE) with BUFGs to perform a medium-
grained clock gating function. For portions of a clock domain ranging from a few hundred to a
few thousand loads in which you want to stop clocking intermittently, the BUFHCE can be an
effective clocking resource. A BUFG can drive multiple BUFHCEs in the same or different clock
regions, which allows you to individually control clocking in several low clock skew domains.

Figure 79: Horizontal Clock Region Buffers

Enable
CE

I O Gated
Logic

BUFHCE
BUFG

Clock I O Non-gated
Logic

X13496-121919

When used independently, all loads connected to the BUFH must reside in the same clock
region. This makes it well-suited for very high-speed, more fine-grained (fewer loads) clocking
needs. BUFHCE can be used to achieve medium-grained clock-gating within the specific clock
region. You must ensure that the resources driven by the BUFH do not exceed the available
resources in the clock region and that no other conflicts exist.

The phase relationship might be different between the BUFH and clock domains driven by
BUFGs, other BUFHs, or any other clocking resource. The single exception is when two BUFHs
are driven to horizontally adjacent regions. In this case, the skew between left and right clock
regions when both BUFHs driven by the same clock source should have a very controlled phase
relationship in which data may safely cross the two BUFH clock domains. BUFHs can be used to
gain access to MMCMs or PLLs in opposite regions to a clock input or GT. However, care must be
taken in this approach to ensure that the MMCM or PLL is available.

Additional Clocking Considerations for SSI Devices

In general, all clocking considerations mentioned above also apply to SSI technology devices.
However, there are additional considerations when targeting these devices due to their
construction. When using a BUFMR, it cannot drive clocking resources across an SLR boundary.
Accordingly, Xilinx recommends that you place the clocks driving BUFMRs into the bank or
clocking region in the center clock region within an SLR. This gives access to all three clock
regions on the left or right side of the SLR.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 126
 Chapter 3: Design Creation with RTL

In terms of global clocking, for designs requiring sixteen or fewer global clocks (BUFGs), no
additional considerations are necessary. The tools automatically assign BUFGs in a way to avoid
any possible contention. When more than 16 (but fewer than 32) BUFGs are required, some
consideration to pin selection and placement must be done to avoid any chance of contention of
resources based on global clocking line contention and/or placement of clock loads.

As in all other Xilinx 7 series devices, Clock-Capable I/Os (CCIOs) and their associated Clock
Management Tile (CMT) have restrictions on the BUFGs they can drive within the given SLR.
CCIOs in the top or bottom half of the SLR can drive BUFGs only in the top or bottom half of the
SLR (respectively). For this reason, pin and associated CMT selection should be done in a way in
which no more that sixteen BUFGs are required in either the top or bottom half of all SLRs
collectively. In doing so, the tools can automatically assign all BUFGs in a way to allow all clocks
to be driven to all SLRs without contention.

For designs that require more than 32 global clocks, Xilinx recommends that you explore using
BUFRs and BUFHs for smaller clock domains to reduce the number of needed global clock
domains. BUFRs with the use of a BUFMR to drive resources within three clock regions that
encompasses one-half of an SLR (approximately 250,000 logic cells in a Virtex-7 class SLR).
Horizontally adjacent clock regions may have both left and right BUFH buffers driven in a low-
skew manner enabling a clocking domain of one-third of an SLR (approximately 167,000 logic
cells).

Using these resources when possible not only leads to fewer considerations for clocking resource
contention, but many times improves overall placement, resulting in improved performance and
power.

If more than 32 global clocks are needed that must drive more than half of an SLR or to multiple
SLRs, it is possible to segment the BUFG global clocking spines. Isolation buffers exist on the
vertical global clock lines at the periphery of the SLRs that allow use of two BUFGs in different
SLRs that occupy the same vertical global clocking track without contention. To make use of this
feature, more user control and intervention is required. In the figure below, BUFG0 through
BUFG2 in the three SLRs have been isolated, and hence have independent clocks within their
respective SLRs. On the other hand, the BUFG31 line has not been isolated. Hence, the same
BUFG31 (located in SLR2 in the figure) drives the clock lines in all the three SLRs - and BUFG31
located in other SLRs should be disabled.

Careful selection and manual placement (LOCs) must be used for the BUFGs. Additionally, all
loads for each clock domain must be manually grouped and placed in the appropriate SLR to
avoid clocking contention. If all global clocks are placed and all loads managed in a way to not
create any clocking contention and allow the clock to reach all loads, this can allow greater use of
the global clocking resources beyond 32.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 127
 Chapter 3: Design Creation with RTL

Figure 80: Optional Isolation on Clock Lines for SSI Devices

Interposer

BUFG31 (X0Y127)

96 97 98 99 12
BUFG2 (X0Y98)
7
BUFG1 (X0Y97)
SLR3
BUFG0 (X0Y96)

Interposer Clock Backbone Tracks 0 1 2 3 31

BUFG31 (X0Y95)

64 65 66 67 95

BUFG2 (X0Y66)

BUFG1 (X0Y65)
SLR2
BUFG0 (X0Y64)

Interposer Clock Backbone Tracks 0 1 2 3 31

BUFG31 (X0Y63)

32 33 34 35 63

BUFG2 (X0Y34)

BUFG1 (X0Y33) SLR1

BUFG0 (X0Y32)

Interposer Clock Backbone tracks 0 1 2 3 31

BUFG31 (X0Y31)

SLR Clock Backbone 0 1 2 3 31

BUFG2 (X0Y2)

BUFG1 (X0Y1) SLR0

BUFG0 (X0Y0)

Interposer
X14051_122019

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 128
 Chapter 3: Design Creation with RTL

Clock Skew for Global Clocking Resources in SSI

Technology Devices
Clock skew in any large device might represent a significant portion of the overall timing budget
for a given path. Too much clock skew may not only represent issues with maximum clock speed,
but may also manifest itself into stringent hold time requirements. Having multiple die in a device
worsens the process portion of the PVT equation, but is managed by the Xilinx assembly process
in which only die of similar speed are packaged together.

Even with that extra action, the Xilinx timing tools accounts for these differences as a part of the
timing report. During path analysis, these aspects are analyzed as a part of the setup and hold
calculations, and are reported as a part of the path delay against the specified requirements. No
additional user calculations or consideration are necessary for SSI technology devices, because
the timing analysis tools consider these factors in their calculations.

Skew can increase if using the top or bottom SLR as the delay-differential is higher among points
farther away from each other. For this reason, Xilinx recommends for global clocks that must
drive more than one SLR to be placed into the center SLR. This allows a more even distribution of
the overall clocking network across the part resulting in less overall clock skew.

When targeting UltraScale devices, there is less repercussion to clock placement. However, it is
still highly suggested to place the clock source as close as possible to the central point of the
clock loads to reduce clock insertion delay and improve clock power.

Designing the Clock Structure

Now that you understand the major considerations for clocking decisions, let us see how you can
achieve the desired clocking for your design.

Inference
Without user intervention, Vivado synthesis automatically specifies a global buffer (BUFG) for all
clock structures up to the maximum allowed in an architecture (unless otherwise specified or
controlled by the synthesis tool). As discussed above, the BUFG provides a well-controlled, low-
skew network suitable for most clocking needs. Nothing additional is required unless your design
clocking exceeds the number or capabilities of BUFGs in the part.

Applying additional control of the clocking structure, however, may prove to show better
characteristics in terms of jitter, skew, placement, power, performance, or other characteristics.

Synthesis Constraints and Attributes

A simple way to control clocking resources is to use the CLOCK_BUFFER_TYPE synthesis
constraint or attribute. Synthesis constraints may be used to:

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 129
 Chapter 3: Design Creation with RTL

• Prevent BUFG inference.

• Replace a BUFG with an alternative clocking structure.
• Specify a clock buffer where one would not exist otherwise.

Using synthesis constraints allows this type of control without requiring any modification to the
code.

Attributes can be placed in either of the following locations:

• Directly in the HDL code, which allows them to persist in the code
• As constraints in the XDC file, which allows this control without any changes needed to the
source HDL code

Use of IP
Certain IP assists in the creation of the clocking structures. Clocking Wizard and IO Wizard
specifically can assist in the selection and creation of the clocking resources and structure,
including:

• BUFG
• BUFGCE
• BUFGCE_DIV (UltraScale devices)
• BUFGCTRL
• BUFIO (7 series devices)
• BUFR (7 series devices)
• Clock modifying blocks such as:
○ Mixed Mode Clocking Manager (MMCM)

○ Phase-locked loop (PLL) components

More complex IP, such as PCIe or Transceivers Wizard IP, might also include clocking structures
as part of the overall IP. This might provide additional clocking resources if properly taken into
account. If not taken into account, it might limit some clocking options for the remainder of the
design.

Xilinx highly recommends that, for any instantiated IP, the clocking requirements, capabilities,
and resources are well understood and leveraged where possible in other portions of the design.

Related Information

Working with Intellectual Property (IP)

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 130
 Chapter 3: Design Creation with RTL

Instantiation
The most low-level and direct method of controlling clocking structures is to instantiate the
desired clocking resources into the HDL design. This allows you to access all possible capabilities
of the device and exercise absolute control over them. When using BUFGCE, BUFGMUX,
BUFHCE, or other clocking structure that requires extra logic and control, instantiation is
generally the only option. However, even for simple buffers, sometimes the quickest way to
obtain a desired result is to be direct and instantiate it into your design.

An effective style to manage clocking resources (especially when instantiating) is to contain the
clocking resources in a separate entity or module instantiated at the top or near the top of the
code. By having it at the top-level of code, it may more easily be distributed to multiple modules
in your design.

Be aware of where clocking resources can and should be shared. Creating redundant clocking
resources is not only a waste of resources, but generally consume more power, create more
potential conflicts and placement decisions resulting in longer overall implementation tool
compile times and potentially more complex timing situations. This is another reason why having
the clocking resources near the top module is important.

TIP: You can use Vivado HDL templates to instantiate specific clocking primitives.

Related Information

Using Vivado Design Suite HDL Templates

Controlling the Phase, Frequency, Duty-Cycle, and

Jitter of the Clock
This section provides techniques for fine-tuning the clock characteristics.

Using Clock Modifying Blocks (MMCM and PLL)

You can use an MMCM or PLL to change the overall characteristics of an incoming clock. An
MMCM is most commonly used to remove the insertion delay of the clock (phase align the clock
to the incoming system synchronous data) or for conditioning and controlling the clock
characteristics, such as:

• Creating tighter control of phase

• Filtering jitter in the clock
• Changing the clock frequency
• Correcting or changing the clock duty cycle

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 131
 Chapter 3: Design Creation with RTL

To use the MMCM or PLL, several attributes must be coordinated to ensure that the MMCM is
operating within specifications and delivering the desired clocking characteristics on its output.
For this reason, Xilinx highly recommends that you use the Clocking Wizard to properly configure
this resource.

You can also directly instantiate the MMCM or PLL, which allows even greater control. However,
be sure to use the proper settings to avoid causing the following issues:

• Increasing clock uncertainty due to increased jitter

• Building incorrect phase relationships
• Making timing closure more difficult

IMPORTANT! When using the Clocking Wizard to configure the MMCM or PLL, the Clocking Wizard
by default attempts to configure the MMCM for low output jitter using reasonable power
characteristics.

Depending on your goals, you can change the settings in the Clocking Wizard to further minimize
jitter and thus, improve timing at the cost of higher power. Alternatively, you can reduce power
but increase output jitter.

While using MMCM or PLL, be sure to do the following:

• Do not leave any inputs floating. Relying on synthesis or other optimization tools to tie off the
floating values is not recommended, because the values might be different than expected.
• Connect RST to the user logic, so that it can be asserted by logic controlled by a reliable
clocking source. Grounding of RST can cause problems if the clock is interrupted.
• Use LOCKED output in the implementation of reset. For example, hold the synchronous logic
clocked from the PLL in reset until LOCKED is asserted. The LOCKED signal must be
synchronized before it is used in a synchronous portion of the design. Xilinx recommends
adding LOCKED to a processor map so it is visible when debugging.
• Confirm the connectivity between CLKFBIN and CLKFBOUT. The BUFG only needs to be
included in the feedback path if the PLL/MMCM output clock needs to be phase aligned with
the input reference clock, for example, when using ZHOLD compensation mode.
• To avoid the MMCM or PLL phase error timing penalty on synchronous clock domain crossing
paths in UltraScale devices, use BUFGCE_DIVs instead of BUFGCE.

RECOMMENDED: Explore the different settings within the Clocking Wizard to ensure that the most
desirable configuration is created based on your overall design goals.

Related Information

Synchronous CDC

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 132
 Chapter 3: Design Creation with RTL

Using IDELAYs on Clocks to Control Phase

For 7 series devices, if only minor phase adjustments are necessary, you can use IDELAY or
ODELAY (instead of MMCM or PLL) to add additional delay. This increases the phase offset of
the clock in relation to any associated data. When using UltraScale devices, you cannot use an
IDELAY on an input clock source. Therefore, if phase manipulation is necessary, Xilinx
recommends using an MMCM.

Using Gated Clocks

Xilinx devices include dedicated clock networks that can provide a large-fanout, low-skew
clocking resource. Fine-grained clock gating techniques included in the HDL code can disrupt the
functionality and prevent efficient use of the dedicated clocking resources. Therefore, when
writing HDL to target a device, Xilinx does not recommend that you code clock gating constructs
into the clock path. Instead, control clocking by using coding techniques to infer clock enables to
stop portions of the design, either for functionality or power reasons.

Converting Clock Gating to Clock Enable

If the code already contains clock gating constructs, or if it is intended for a different technology
that requires such coding styles, Xilinx recommends that you use a synthesis tool that can remap
gates placed within the clock path to clock enables in the data path. Doing so allows for a better
mapping to the clocking resources; and simplifies the timing analysis of the circuit for data
entering and exiting the gated domain. For example, use the -gated_clock_conversion
auto option with Vivado synthesis to attempt automatic conversion to register clock enable
logic. For the complex gated clock structures, use the GATED_CLOCK attribute in the RTL code
to guide Vivado synthesis.

Gating the Clock Buffer

When larger portions of the clock network can be shut down for periods of time, you can enable
or disable the clock network using a BUFGCE or BUFGCTRL. In addition, when targeting
UltraScale devices, you can gate the BUFGCE_DIV and BUFG_GT. For 7 series devices, you can
also use the BUFHCE, BUFR, and BUFMRCE to gate the clock.

When a clock can be slowed down during periods of time, you can also use these buffers with
additional logic to periodically enable the clock net. Alternatively, you can use a BUFGMUX or
BUFGCTRL to switch the clock source from a faster clock signal to a slower clock.

Any of these techniques can effectively reduce dynamic power. However, depending on the
requirements and clock topology, one technique may prove more effective than another. For
example, in 7 series devices:

• A BUFR might work best if it is an externally generated clock (under 450 MHz) that is only
needed to source up to three clock regions.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 133
 Chapter 3: Design Creation with RTL

• For Virtex-7 devices, a BUFMRCE might also be needed to use this technique with more than
one clock region (but only up to three vertically adjacent regions).
• A BUFHCE is better suited for higher-speed clocks that can be contained in a single clock
region. Although a BUFGCE may span the device and is the most flexible approach, it might
not be the best choice for the greatest power savings.

Controlling and Synchronizing Device Startup

After the device completes configuration, a sequence of events occurs in which the device
completes the configuration state and enters into general operation. In most configuration
sequences, one of the last steps is the deassertion of the Global Set Reset (GSR), followed by the
deassertion of the Global Enable (GWE) signal. When this happens, the design is in a known
initial state and is then released for operation.

If this release point is not synchronized to the given clock domain or if the clock is operating at a
faster time than the GWE can safely be released, portions of the design can go into an unknown
state. For some designs, this does not matter. In other designs, this can cause the design to
become unstable or to incorrectly process the initial data set.

If the design must start up in a known state, Xilinx recommends that you take action to control
the start-up synchronization process using any of the following methods:

• Use clock enables, local reset (synchronized), or both, on critical parts of the design, such as a
state machine, to ensure that the start-up of those portions of the design are controlled and
known.
• Use instantiated clock buffer components with clock enable capability.
Delay the reset release by as many cycles as needed before enabling the design clock. The
following example shows how to delay the first design clock edge after the reset is released in
an UltraScale device. By setting ASYNC_REG=TRUE on the synchronizer registers, all registers
are placed in a single SLICE and therefore, do not need to be driven by a global clock resource.
To prevent clock buffer insertion on the synchronizer clock, use the
CLOCK_BUFFER_TYPE=NONE property on the input clock port.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 134
 Chapter 3: Design Creation with RTL

Figure 81: Reset Synchronization and Delay for Safe Clock Startup Example

Synchronizer/Reset
Delay Clock

Design Clock
X18183-121919

• When using an MMCM, you can select the Safe Clock Startup option from the Clocking
Wizard to ensure that design clocks are enabled only after they are stable and reliable.
The following example shows the synchronization stages of an UltraScale device MMCM
LOCKED signal connected to the CE pin of the BUFGCE, which drives the user logic. A second
BUFGCE is connected in parallel to the high fanout BUFGCE (user clock) and is dedicated to
the logic controlling the BUFGCE/CE pin. This topology helps timing closure on the
BUFGCE/CE in UltraScale devices by minimizing the clock skew between the synchronizer
and the BUFGCE pin.

Figure 82: MMCM Safe Clock Startup Example

High Fanout Clock (routed to several or all clock regions)

Low Fanout Clock (routed within MMCM clock region)

X18185-020321

TIP: If the MMCM or PLL compensation mode is set to ZHOLD or BUF_IN, all clocks from CLKOUT0
are grouped with the feedback clock and use the same CLOCK_ROOT. If this introduces timing
violations on BUFGCE/CE, create a CLOCK_DELAY_GROUP constraint between the high fanout clock
and the feedback clock only. Optionally, you can also set a USER_CLOCK_ROOT constraint on the low
fanout clock net to constrain the loads to the same clock region as the MMCM. For 7 series devices, the
second clock buffer is usually not needed for helping timing closure due to the different clocking
architecture.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 135
 Chapter 3: Design Creation with RTL

Avoiding Local Clocks

Local clocks are clock nets routed with regular fabric resources instead of dedicated global
clocking resources. In most cases, the Vivado synthesis and Vivado logic optimization tools insert
clock buffers where mandated by the architecture or for clock nets with more than 30 clock
loads. Local clocks typically occur when:

• A global clock is divided by a counter implemented with fabric logic

• Clock gating conversion is not able to remove all LUTs from the clock path
• Too many clock buffers are used in 7 series devices
Note: UltraScale devices have more clock buffers than 7 series devices, and high utilization of low
fanout clock buffers is usually not a concern.

In general, avoid using local clocks. Local clocks introduce several challenges to the
implementation tools:

• Unpredictable clock skew, leading to difficult timing closure

• Increase of low to medium fanout nets that are processed with special care by the router,
leading to potential routability problems

TIP: If local clocks introduce timing QoR problems, try floorplanning the clock driver and loads to a
small area using a Pblock. Use report_clock_utilization to identify the location of the local
clocks, review the clock placement, and decide on how to reduce their number or impact.

Creating an Output Clock

An effective way to forward a clock out of a device for clocking devices external to the device, is
to use an ODDR component. By tying one of the inputs High and the other Low, you can easily
create a well controlled clock in terms of phase relationship and duty cycle (for example, by
holding D1 to 0 and the D2 pin to 1, you can achieve a 180 degree phase shift). By utilizing the
set/reset and clock enable, you also have control over stopping the clock and holding it at a
certain polarity for sustained amounts of time.

If further phase control is necessary for an external clock, an MMCM or PLL can be used with
external feedback compensation and/or coarse or fine grained, fixed or variable phase
compensation. This allows great control over clock phase and propagation times to other devices
simplifying external timing requirements from the device.

Clocking Recommendations for Platforms and

Dynamic Function eXchange
This section covers the clocking guidelines for Dynamic Function eXchange (DFX) designs. In
general, clocks in a DFX design are categorized as internal clocks and boundary clocks:

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 136
 Chapter 3: Design Creation with RTL

• Reconfigurable module internal clocks: Clocks with driver and all loads inside the
reconfigurable module (RM).

• Boundary clocks: Clocks with nets crossing the cell boundary of the reconfigurable module as
follows:

• Driver in the static region and loads in the RM

• Driver in the RM and loads in the static region
• Driver in the static region and loads distributed between RM and static region
• Driver in the RM region and loads distributed between RM and static region

The following figure shows an example of the different boundary clocks.

Figure 83: DFX Clock Tile Sharing

Boundary clock net with driver in static region and loads in static and reconfigurable partition
Boundary clock net with driver in static region and loads in reconfigurable partition
Internal reconfigurable module clock net
Boundary clock net with driver in reconfigurable partition and loads in static region
Boundary clock nets with driver in reconfigurable partition and loads in reconfigurable partition and static region

X25409-062421

For more information on DFX, see the Vivado Design Suite User Guide: Dynamic Function eXchange
(UG909).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 137
 Chapter 3: Design Creation with RTL

DFX Behavior for Clock Nets

Reconfigurable Module Internal Clock Nets
In a reconfigurable module (RM) internal clock net, the clock root is placed at the center of the
loads inside the reconfigurable partition (RP) Pblock. This clock root placement offers more
flexibility for placement and routing of the RM internal clock in subsequent implementations.
Xilinx recommends this approach whenever possible to achieve better skew and optimal clock
root placement.

Boundary Clock Nets

After the first implementation, boundary clock net tracks are locked. The partition pin locations
(PPLOCs) on the boundary clock nets are distributed to all clock regions covered by the
reconfigurable partition (RP) Pblock.

The clock root of the boundary clock net can be placed anywhere in the device, because the
boundary clock net can drive both static and RP loads. Xilinx recommends using the
USER_CLOCK_ROOT constraint on the boundary clock net to manually constrain the
CLOCK_ROOT location due to the following:

• If the loads of the boundary clock are located mainly in the static region, the clock root might
be placed in the static region.
• If the first implementation uses training logic in the RP Pblock, boundary clock nets might be
locked down after the first implementation with an off-center clock root location.
• Because the boundary clock net is distributed to all clock regions covered by the RP Pblock,
the clock insertion delay for the boundary clock is relatively high compared with the internal
RM clock nets.

Clock Domain Crossing

The clock domain crossing (CDC) circuits in the design directly impact design reliability. You can
design your own circuits, but the Vivado Design Suite must recognize the circuit and you must
apply the ASYNC_REG attributes correctly. Xilinx provides XPMs to ensure correct circuit design,
including:

• Driving specific features in place_design that reduce mean time between failures (MTBF)
on synchronization circuits.
• Ensuring recognition by report_synchronizer_mtbf.
• Avoiding report_cdc errors and warnings, which typically show up late in the design cycle
when iterations are longer.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 138
 Chapter 3: Design Creation with RTL

TIP: For CDC violations that can be safely ignored, you can use the waiver mechanism to waive the
violations. For details, see this link in the Vivado Design Suite User Guide: Design Analysis and Closure
Techniques (UG906).

A CDC circuit is required when crossing between two asynchronous clocks or when attempting
to relax timing between two synchronous clocks by adding false path constraints. When using
XPMs, you can select a single-bit or a multi-bit bus to cross between the domains.

Single-Bit CDC
The following figure shows the decisions required when using a single-bit crossing.

Figure 84: Single-Bit CDC Decision Tree

Single-Bit CDC

Yes Reset signal? No

Asynchronous? Is it a pulse?
No Yes No Yes

Use Use Use Use

XPM_CDC_SYNC_RST XPM_CDC_ASYNC_RST XPM_CDC_SINGLE XPM_CDC _PULSE
X17900-101016

Note: For more information on the different single-bit synchronizers, see the Libraries Guide for your
device.

Multi-Bit CDC
The following figure shows the decisions required when using a multi-bit crossing.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 139
 Chapter 3: Design Creation with RTL

Figure 85: Multi-Bit CDC Decision Tree

Multi-Bit CDC

Is the data
Yes known to be
static?

No
Do not add CDC circuits
Manage CDC using waivers for
report_cdc
Is a transfer
required every
clock cycle? Yes

No

Is the data
Yes
buffered?

Use
XPM_FIFO_ASYNC
No

Is the data a
Yes
counter?

Use
XPM_CDC_GRAY
No

Must all data bits

No be received on the same Yes
cycle?
Use Use
XPM_CDC_ARRAY_SINGLE XPM_CDC_HANDSHAKE
X17901-101216

Note: For more information on the different multi-bit synchronizers, see the Libraries Guide for your
device.

Optimizing for MTBF

The total MTBF of a design is a function of:

• Synchronizer MTBF
• Device failure in time (FIT) rate due to single-event upsets (SEUs)

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 140
 Chapter 3: Design Creation with RTL

Note: The device FIT rate due to SEUs largely depends on process and device size.

The synchronizer MTBF is design dependent and varies with the following:

• Number of asynchronous CDC points

• Number of synchronizer stages at each crossing point
• Frequency of the destination FF
• Toggle rate of the source

Selecting the Correct Value for the DEST_SYNC_FF Parameter

The DEST_SYNC_FF parameter sets the number of metastability protection registers when using
an XPM CDC module. The value of this register influences MTBF, design size, and latency at the
crossing point. Selecting the correct value of this register is an iterative process that requires the
following:

1. Run the design through the Vivado Design Suite implementation flow.
2. Based on your targeted device, do one of the following:
• For 7 series devices, select the default value for DEST_SYNC_FF. This is a conservative
approach to meeting typical reliability requirements. For critical designs, conduct further
analysis.
• For UltraScale devices, run the report_synchonizer_mtbf command, which reports
the MTBF for the entire design. By iterating through the flow as shown in the following
figure, you can find a suitable trade-off between MTBF, latency, and resources.

Note: You can also use this iterative process for a user CDC circuit in which the ASYNC_REG attribute is
correctly applied to all the synchronization registers.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 141
 Chapter 3: Design Creation with RTL

Figure 86: Synchronizer MTBF Optimization Flow for UltraScale Device

Determine XPM
synchronizer stages

Set DEST_SYNC_FF
starting with default
value

Implement Design

Increase DEST_SYNC_FF Decrease DEST_SYNC_FF

parameter on XPM_CDC parameter on XPM_CDC

Run report_synchronizer_mtbf

Need to improve
Yes
MTBF?

No

Yes
Need to
improve resource
or latency?

No

Finalize DEST_SYNC_FF

X17899-122019

Constraining the Design Correctly

XPM CDCs provide their own set_max_delay -datapath_only constraints. XPM CDCs are
not compatible with the set_clock_groups constraint, which has a higher precedence and
will overwrite the constraints in the XPM.

Related Information

Defining Clock Groups and CDC Constraints

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 142
 Chapter 4: Design Constraints

Chapter 4

Design Constraints
Design constraints define the requirements that must be met by the compilation flow for the
design to be functional in hardware. For complex designs, constraints also define guidance for
the tools to help with convergence and closure. Not all constraints are used by all steps in the
compilation flow. For example, physical constraints are used only during the implementation
steps: optimization, placement, and routing.

Because synthesis and implementation algorithms are timing-driven, creating proper timing
constraints is essential. Over-constraining or under-constraining your design makes timing
closure difficult. You must use reasonable constraints that correspond to your application
requirements. For more information on constraints, see the following resources:

• Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906)
• Applying Design Constraints video tutorials available from the Vivado Design Suite Video
Tutorials page on the Xilinx® website

Note: Traditional and platform-based design flows use design constraints in a similar manner. However,
platform-based designs require extra attention for signals crossing the boundary from the static region of
the design to the dynamic region of the design. Constraining these signals properly ensures flexibility of
the platform and minimizes platform revisions.

Organizing the Design Constraints for

Compilation
The constraints are usually organized by category, by design module, or both, in one or many
files. Regardless of how you organize them, you must understand their overall dependencies and
review their final sequence once loaded in memory. For example, because timing clocks must be
defined before they can be used by any other constraints, you must make sure that their
definition is located at the beginning of your constraint file, in the first set of constraint files
loaded in memory, or both.

Recommended Constraint Files

There are many ways to organize your constraints depending on the size and complexity of your
project. Following are a few suggestions.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 143
 Chapter 4: Design Constraints

Simple Design
For a simple design with a small team of designers:

• 1 file for all constraints

• 1 file for physical + 1 file for timing
• 1 file for physical + 1 file for timing (synthesis) + 1 file for timing (implementation)

Complex Design
For a complex design with IP cores or several designer teams:

• 1 file for top-level timing + 1 file for top-level physical + 1 file per IP/major block

Validating the Read Sequence

After you settle on the organization of your project constraint files, you must validate the read
sequence of the files depending on the content of the files. In Project Mode, you can modify the
constraint file sequence in the Vivado® IDE or by using the reorder_files Tcl command. In
Non-Project Mode, the sequence is directly defined by the read_xdc (for XDC files) and
source (for constraints generated by Tcl scripts) commands in your compilation flow Tcl script.

Recommended Constraints Sequence

The constraints language (XDC) is based on Tcl syntax and interpretation rules. Like Tcl, XDC is a
sequential language:

• Variables must be defined before they can be used. Similarly, timing clocks must be defined
before they can be used in other constraints.
• For equivalent constraints that cover the same paths and have the same precedence, the last
one applies.
• When a path is covered by multiple timing exceptions, the constraint with the higher
precedence applies.

When considering the priority rules above, the timing constraints should overall use the following
sequence:

## Timing Assertions Section

# Primary clocks
# Virtual clocks
# Generated clocks
# Delay for external MMCM/PLL feedback loop
# Clock Uncertainty and Jitter
# Input and output delay constraints
# Clock Groups and Clock False Paths
## Timing Exceptions Section

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 144
 Chapter 4: Design Constraints

# False Paths
# Max Delay / Min Delay
# Multicycle Paths
# Case Analysis
# Disable Timing

When multiple XDC files are used, you must pay particular attention to the clock definitions and
validate that the dependencies are ordered correctly.

The physical constraints can be located anywhere in any constraint file.

Creating Synthesis Constraints

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:
○ DONT_TOUCH / KEEP / KEEP_HIERARCHY / MARK_DEBUG

○ MAX_FANOUT

○ RAM_STYLE / ROM_STYLE / USE_DSP / SHREG_EXTRACT

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

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 145
 Chapter 4: Design Constraints

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

Creating Implementation Constraints

The implementation constraints must accurately reflect the requirements of the final application.
Physical constraints such as I/O location and I/O standard are dictated by the board design,
including the board trace delays, as well as the design internal requirements derived from the
overall system requirements. Before you proceed to implementation, Xilinx highly recommends
that you validate the correctness and accuracy of all your constraints. An improper constraint will
likely contribute to degradation of the implementation QoR and can lower the confidence level in
the timing signoff quality.

In many cases, the same constraints can be used during synthesis and implementation. However,
because the design objects can disappear or have their name changed during synthesis, you must
verify that all synthesis constraints still apply properly with the implementation netlist. If this is
not the case, you must create an additional XDC file containing the constraints that are valid for
implementation only.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 146
 Chapter 4: Design Constraints

Creating Block-Level Constraints

When working on a multi-team project, it is convenient to create individual constraint files for
each major block of the top-level design. Each of these blocks is usually developed and validated
separately before the final integration into one or many top-level designs.

The block-level constraints must be developed independently from the top-level constraints, and
must be as generic as possible so that they can be used in various contexts. In addition, these
constraints must not affect any logic that is beyond the block boundaries.

When implementing a sub-block it is desirable to have the full clocking network included in
timing analysis to ensure accurate skew and clock domain crossing analysis. This might require an
HDL wrapper containing the clocking components and an additional constraint file to replicate
top level clocking constraints. It is used only in the timing validation of the sub-module.

For more information on constraints scoping as well as rules, guidelines, and mechanisms for
loading the block-level constraints into the top-level design, see this link in the Vivado Design
Suite User Guide: Using Constraints (UG903).

Specifying Constraints for the Vitis Environment

In the Vitis™ environment, you can specify the hardware kernel as a C/C++ kernel or as an RTL
kernel:

• When using a C/C++ kernel, you must specify additional user constraints for synthesis or
implementation using Vitis HLS. The Vitis HLS output must then be packaged in the IP
packager, and this packaged IP includes both the user and tool-generated constraints. For
information, see the Vitis HLS User Guide (UG1399).
• When using an RTL kernel, you must specify additional synthesis and implementation
constraints during IP packaging. For information, see the Vivado Design Suite User Guide:
Creating and Packaging Custom IP (UG1118).

In the Vitis environment, all of the design constraints for synthesis and implementation must be
packaged with the IP. If additional constraints are required for synthesis after the IP is packaged,
you must repackage the IP to include the missing constraints.

However, after the IP is packaged, you can specify additional XDC constraints to be used only
during implementation. Although the Vitis environment abstracts the underlying Vivado tools
process for implementing the programmable logic region, the Vitis environment also provides
advanced options to control the Vivado tools flow. With these advanced controls, you can
specify certain Tcl scripts to be executed before (Pre) or after (Post) each implementation phase,
including the following: init_design, opt_design, place_design, phys_opt_design,
route_design, or write_bitstream. For more information on Tcl scripting, see the Vivado
Design Suite User Guide: Using Tcl Scripting (UG894). You can leverage the Pre and Post Tcl scripts
to execute certain Vivado tools commands, such as to apply additional XDC constraints through
the read_xdc or source Tcl commands.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 147
 Chapter 4: Design Constraints

You can specify the Pre and Post Tcl scripts either through the Vitis environment configuration
file or directly on the v++ compiler command line.

To specify the Pre and Post Tcl scripts inside the Vitis environment configuration file, use the
parameters prop=run.impl_1.STEP.<PHASE>.TCL.<PRE|POST> inside the [vivado]
section.

Where:

• <PHASE> specifies the implementation phase: INIT_DESIGN, OPT_DESIGN,

PLACE_DESIGN, PHYS_OPT_DESIGN, ROUTE_DESIGN, or WRITE_BITSTREAM.
• PRE executes the script before the specified implementation phase.
• POST executes the script after the specified implementation phase.

For example:

[vivado]
prop=run.impl_1.STEPS.OPT_DESIGN.TCL.PRE=<pathToTclScript>
prop=run.impl_1.STEPS.OPT_DESIGN.TCL.POST=<pathToTclScript>
prop=run.impl_1.STEPS.PLACE_DESIGN.TCL.PRE=<pathToTclScript>
prop=run.impl_1.STEPS.PLACE_DESIGN.TCL.POST=<pathToTclScript>
prop=run.impl_1.STEPS.PHYS_OPT_DESIGN.TCL.PRE=<pathToTclScript>
prop=run.impl_1.STEPS.PHYS_OPT_DESIGN.TCL.POST=<pathToTclScript>
prop=run.impl_1.STEPS.ROUTE_DESIGN.TCL.PRE=<pathToTclScript>
prop=run.impl_1.STEPS.ROUTE_DESIGN.TCL.POST=<pathToTclScript>

To specify the Pre and Post Tcl scripts as a v++ parameter, use the --vivado.prop
run.impl_1.STEP.<PHASE>.TCL.<PRE|POST>=<pathToTclScript> command line
option. For example, to specify a Tcl script to be executed before opt_design:

--vivado.prop run.impl_1.STEP.OPT_DESIGN.TCL.PRE=<pathToTclScript>

Where:

• --vivado is the v++ command line option to specify directives for the Vivado tools.
• prop indicates a property setting.
• run. indicates a run property.
• impl_1. indicates the name of the run.
• STEP.OPT_DESIGN.TCL.PRE indicates the run property you are specifying.
• <pathToTclScript> indicates the property value.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 148
 Chapter 4: Design Constraints

Defining Timing Constraints

Defining Timing Constraints in Four Steps
The process of defining good constraints is broken into the four major steps shown in the
following figure. The steps follow the timing constraints precedence and dependency rules, as
well as the logical way of providing information to the timing engine to perform the analysis.

Figure 87: Steps for Developing Timing Constraints

XDC:
create_clock
create_generated_clock Create Clocks Reports:
set_system_jitter (Primary/Virtual/Generated) Clock Networks
set_input_jitter (External Feedback/Uncertainty) Check Timing
set_clock_uncertainty
set_external_delay

XDC: Reports:
Input/Output Delays Check Timing
set_input_delay
(System/Source Synchronous) Report Timing
set_output_delay

XDC: Reports:
Clock Groups and CDC Clock Interaction
set_clock_groups
(Asynchronous/Exclusive) Check Timing
set_false_path

XDC:
set_false_path
Reports:
set_min/max_delay Timing Exceptions Timing Summary
set_multicycle_path (Ignore/Max/Min) Report Timing
set_case_analysis
set_disable_timing

X13445-122019

• The first two steps refer to the timing assertions where the default timing path requirements
are derived from the clock waveforms and I/O delay constraints.
• During the third step, relationships between the asynchronous/exclusive clock domains that
share at least one logical path are reviewed. Based on the nature of the relationships, clock
groups or false path constraints are entered to ignore the timing analysis on these paths.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 149
 Chapter 4: Design Constraints

• The last step corresponds to the timing exceptions, where the designer can decide to alter the
default timing path requirements by ignoring, relaxing or tightening them with specific
constraints.

Constraints creation is associated with constraints identification and constraints validation tasks
that are only possible with the various reports generated by the timing engine. The timing engine
only works with a fully mapped netlist, for example, after synthesis. While it is possible to enter
constraints with an elaborated netlist, it is recommended to create the first set of constraints
with the post-synthesis netlist so that analysis and reports on the constraints can be performed
interactively.

When creating timing constraints for a new design or completing existing constraints, Xilinx
recommends using the Timing Constraints Wizard to quickly identify missing constraints for the
first three steps in the previous figure. The Timing Constraints Wizard follows the methodology
described in this section to ensure the design constraints are safe and reliable for proper timing
closure. You can find more information on the Timing Constraints Wizard in Vivado Design Suite
User Guide: Using Constraints (UG903).

The following sections describe in detail the four steps described above:

• Defining Clock Constraints

• Constraining Input and Output Ports
• Defining Clock Groups and CDC Constraints
• Specifying Timing Exceptions

Refer to each section for a detailed methodology and use case when you are at the appropriate
step in the constraint creation process.

Defining Clock Constraints

Clocks must be defined first so that they can be used by other constraints. The first step of the
timing constraint creation flow is to identify where the clocks must be defined and whether they
must be defined as a primary clock or a generated clock.

IMPORTANT! When defining a clock with a specific name (-name option), you must verify that the clock
name is not already used by another clock constraint or an existing auto-generated clock. The Vivado
Design Suite timing engine issues a message when a clock name is used in several clock constraints to warn
you that the first clock definition is overridden. When the same clock name is used twice, the first clock
definition is lost as well as all constraints referring to that name and entered between the two clock
definitions. Xilinx recommends that you avoid overriding clock definitions unless no other constraints are
impacted and all timing paths remain constrained.

Identifying Clock Sources

The unconstrained clock sources can be identified in the design by the Clock Networks report
and the Check Timing report.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 150
 Chapter 4: Design Constraints

Clock Networks Report

Both constrained and unconstrained clock source points are listed in two separate categories. For
each unconstrained source point, you must identify whether a primary clock or a generated clock
must be defined.
% report_clock_networks
Unconstrained Clocks
Clock sysClk (endpoints: 15633 clock, 0 nonclock)
Port sysClk
Clock TXOUTCLK (endpoints: 148 clock, 0 nonclock)
GTXE2_CHANNEL/TXOUTCLK
(mgtEngine/ROCKETIO_WRAPPER_TILE_i/gt0_ROCKETIO_WRAPPER_TILE_i/gtxe2_i)
Clock Q (endpoints: 8 clock, 0 nonclock)
FDRE/Q (usbClkDiv2_reg)

Check Timing Report

The no_clock check reports the groups of active leaf clock pins with no clock definition. Each
group is associated with a clock source point where a clock must be defined to clear the issue.
% check_timing -override_defaults no_clock
1. checking no_clock
--------------------
There are 15633 register/latch pins with no clock driven by root clock pin: sysClk
(HIGH)
There are 148 register/latch pins with no clock driven by root clock pin:
mgtEngine/ROCKETIO_WRAPPER_TILE_i/gt0_ROCKETIO_WRAPPER_TILE_i/gtxe2_i/TXOUTCLK
(HIGH)
There are 8 register/latch pins with no clock driven by root clock pin:
usbClkDiv2_reg/C (HIGH)

With check_timing, the same clock source pin or port can appear in several groups depending
on the topology of the entire clock tree. In such case, creating a clock on the recommended
source pin or port will resolve the missing clock definition for all the associated groups.

Related Information

Checking That Your Design is Properly Constrained

Creating Primary Clocks

A primary clock is a clock that defines a timing reference for your design and that is used by the
timing engine to derive the timing path requirements and the phase relationship with other
clocks. Their insertion delay is calculated from the clock source point (driver pin/port where the
clock is defined) to the clock pins of the sequential cells to which it fans out.

For this reason, it is important to define the primary clocks on objects that correspond to the
boundary of the design, so that their delay, and indirectly their skew, can be accurately
computed.

The following sections describe the typical primary clock roots.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 151
 Chapter 4: Design Constraints

Input Ports
You can use an input port as the primary clock root as shown in the following figure.

Figure 88: create_clock for Input Ports

REGA REGB
Data Path
D Q D Q

sysclk IBUF BUFG

Recommended primary clock

source point: sysclk port
X13446-121919

Constraint example:

create_clock -name SysClk -period 10 -waveform {0 5} [get_ports sysclk]

In this example, the waveform is defined to have a 50% duty cycle. The -waveform argument is
shown above to illustrate its usage and is only necessary to define a clock with a duty cycle other
than 50%. For more information, see the create_clock Tcl command in the Vivado Design Suite Tcl
Command Reference Guide (UG835). For a differential clock input buffer, the primary clock only
needs to be defined on the P-side of the pair.

Gigabit Transceiver Output Pins in 7 Series Devices

You can use a gigabit transceiver output pin (e.g., a recovered clock) as the primary clock root as
shown in the following figure.

Figure 89: create_clock on a Primitive Pin

Constraint example:

create_clock -name txclk -period 6.667 [get_pins gt0/TXOUTCLK]

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 152
 Chapter 4: Design Constraints

RECOMMENDED: For designs that target 7 series devices, Xilinx recommends also defining the GT
incoming clocks, because the Vivado tools calculate the expected clocks on the GT output pins and
compare these clocks with the user-created clocks. If the clocks differ or if the incoming clocks to the GT
are missing, the tools issue a methodology check warning.

Note: For designs that target UltraScale™ and UltraScale+™ devices, Xilinx does not recommend defining a
primary clock on the output of GTs, because GT clocks are automatically derived when the REFCLK input
clocks are defined.

Certain Hardware Primitive Output Pins

You can use the output pin of certain hardware primitives as the primary clock root, such as the
output pin shown in the following figure, which does not have a timing arc from an input pin of
the same primitive.

Figure 90: Clock Path Broken Due to a Missing Timing Arc

instB
D Q
instA

sysclk IBUF
IN OUT

X
no arc
Recommended primary clock
source point: instA/OUT
X13448-121919

IMPORTANT! No primary clock should be defined in the transitive fanout of another primary clock
because this situation does not correspond to any hardware reality. It will also prevent proper timing
analysis by preventing the complete clock insertion delay calculation. Any time this situation occurs, the
constraints must be revisited and corrected.

The following figure shows an example in which the clock clk1 is defined in the transitive fanout
of the clock clk0. The clock clk1 overrides clk0 starting at the output of BUFG1, where it is
defined. Therefore, the timing analysis between REGA and REGB is not accurate because of the
invalid skew computation between clk0 and clk1.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 153
 Chapter 4: Design Constraints

Figure 91: create_clock in the Fanout of Another Clock is Not Recommended

REGA REGB
Data Path
D Q D Q

sysclk IBUF BUFG0

BUFG1

NOT RECOMMENDED
create_clock –name clk1 –period 10 [get_pins BUFG1/0]
create_clock –name clk0 –period 10 [get_ports sysclk]
X13449-121919

Creating Generated Clocks

A generated clock is a clock derived from another existing clock called the master clock. It usually
describes a waveform transformation performed on the master clock by a logic block. Because
the generated clock definition depends on the master clock characteristics, the master clock
must be defined first. For explicitly defining a generated clock, the create_generated_clock
command must be used.

Auto-Derived Clocks
Most generated clocks are automatically derived by the Vivado timing engine which recognizes
the clock modifying blocks (CMB) and the transformation they perform on the master clocks.

In the Xilinx 7 series device family, the CMBs are:

• MMCM*/ PLL*
• BUFR
• PHASER*

In the Xilinx UltraScale device family, following are the CMBs:

• MMCM* / PLL*
• BUFG_GT / BUFGCE_DIV
• GT*_COMMON / GT*_CHANNEL / IBUFDS_GTE3
• BITSLICE_CONTROL / RX*_BITSLICE
• ISERDESE3

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 154
 Chapter 4: Design Constraints

For any other combinatorial cell located on the clock tree, the timing clocks propagate through
them and do not need to be redefined at their output, unless the waveform is transformed by the
cell. In general, you must rely on the auto-derivation mechanism as much as possible as it
provides the safest way to define the generated clocks that correspond to the actual hardware
behavior.

If the auto-derived clock name chosen by the Vivado Design Suite timing engine does not seem
appropriate, you can force your own name by using the create_generated_clock command
without specifying the waveform transformation. This constraint should be located right after the
constraint that defines the master clock in the constraint file. For example, if the default name of
a clock generated by a MMCM instance is net0, you can add the following constraint to force
your own name (fftClk in the given example):

create_generated_clock -name fftClk [get_pins mmcm_i/CLKOUT0]

To avoid any ambiguity, the constraint must be attached to the source pin of the clock. For more
information, see Vivado Design Suite User Guide: Using Constraints (UG903).

User-Defined Generated Clocks

When all the primary clocks have been defined, you can use the Clock Networks or Check Timing
(no_clock) reports to identify the clock tree portions that do not have a timing clock and define
the generated clocks accordingly.

It is sometimes difficult to understand the transformation performed by a cone of logic on the

master clock. In this case, you must adopt the most conservative constraint. For example, the
source pin is a sequential cell output. The master clock is at least divided by two, so the proper
constraint should be, for example:

create_generated_clock -name clkDiv2 -divide_by 2 \

-source [get_pins fd/C] [get_pins fd/Q]

Finally, if the design contains latches, the latch gate pins also need to be reached by a timing
clock and will be reported by Check Timing (no_clock) if the constraint is missing. You can
follow the examples above to define these clocks.

Path Between Master and Generated Clocks

Unlike primary clocks, generated clocks must be defined in the transitive fanout of their master
clock, so that the timing engine can accurately compute their insertion delay. Failure to follow
this rule will result in improper timing analysis and most likely in invalid slack computation. For
example, in the following figure gen_clk_reg/Q is being used as a clock for the next flop
(q_reg), and it is also in the fanout cone of the primary clock c1. Hence gen_clk_reg/Q
should have a create_generated_clock on it, rather than a create_clock.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 155
 Chapter 4: Design Constraints

Figure 92: Generated Clock in the Fanout Of Master Clock

create_generated_clock -name GC1 -source [get_pins gen_clk_reg/C] -divide_by 2

[get_pins gen_clk_reg/Q]

Verifying Clocks Definition and Coverage

When all design clocks are defined and applied in memory, you can verify the waveform of each
clock, the relationship between master and generated clocks by using the report_clocks
command:

Clock Period Waveform Attributes Sources

sysClk 10.00000 {0.00000 5.00000} P {sysClk}
clkfbout 10.00000 {0.00000 5.00000} P,G {clkgen/mmcm_adv_inst/CLKFBOUT}
cpuClk 20.00000 {0.00000 10.00000} P,G {clkgen/mmcm_adv_inst/CLKOUT0}
…
====================================================
Generated Clocks
====================================================
Generated Clock : cpuClk
Master Source : clkgen/mmcm_adv_inst/CLKIN1
Master Clock : sysClk
Edges : {1 2 3}
Edge Shifts : {0.000 5.000 10.000}
Generated Sources : {clkgen/mmcm_adv_inst/CLKOUT0}

You can also verify that all internal timing paths are covered by at least one clock. The Check
Timing report provides two checks for that purpose:

• no_clock: Reports any active clock pin that is not reached by a defined clock.

• unconstrained_internal_endpoint: Reports all the data input pins of sequential cells that have
a timing check relative to a clock but the clock has not been defined.

If both checks return zero, the timing analysis coverage will be high.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 156
 Chapter 4: Design Constraints

Alternatively, you can run the XDC and Timing Methodology checks to verify that all clocks are
defined on recommended netlist objects without introducing any constraint conflict or inaccurate
timing analysis scenario.

Use the following command to run these checks:

report_methodology -checks [get_methodology_checks {TIMING-* XDC*}]

Related Information

Running Report Methodology

Adjusting Clock Characteristics

After defining the clocks and their waveform, the next step is to enter any information related to
noise or uncertainty modeling. The XDC language differentiates uncertainty related to jitter and
phase error from the one related to skew and delay modeling.

Jitter
For jitter, it is best to use the default values used by the Vivado Design Suite. You can modify the
default computation as follows:

• If a primary clock enters the device with a random jitter greater than zero, use the
set_input_jitter command to specify the peak-to-peak jitter value in nanoseconds.
• To adjust the global jitter if the device power supply is noisy, use set_system_jitter.
Xilinx does not recommend increasing the default system jitter value.

For generated clocks, the jitter is derived from the master clock and the characteristics of the
clock modifying block. You do not need to adjust these numbers.

Additional Uncertainty
When you need to add extra margin on the timing paths of a clock or between two clocks, you
must use the set_clock_uncertainty command. This is also the best and safest way to
over-constrain a portion of a design without modifying the actual clock edges and the overall
clocks relationships. The clock uncertainty defined by you is additive to the jitter computed by
the Vivado tools, and can be specified separately for setup and hold analysis.

For example, the margin on all intra-clock paths of the design clock clk0 needs to be tightened
by 500 ps to make the design more robust to noise for both setup and hold:

set_clock_uncertainty -from clk0 -to clk0 0.500

Note: Tightening the hold margin on a design can lead to hold violations on dedicated intra-site and
cascade paths that the router cannot fix by detouring the intra-site net.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 157
 Chapter 4: Design Constraints

If you specify additional uncertainty between two clocks, the constraint must be applied in both
directions (assuming data flows in both directions). The example below shows how to increase
the uncertainty by 250 ps between clk0 and clk1 for setup only:

set_clock_uncertainty -from clk0 -to clk1 0.250 -setup

set_clock_uncertainty -from clk1 -to clk0 0.250 -setup

Clock Latency at the Source

It is possible to model the latency of a clock at its source by using the set_clock_latency
command with the -source option. This is useful in two cases:

• To specify the clock delay propagation outside the device independently from the input and
output delay constraints.
• To model the internal propagation latency of a clock used by a block during out-of-context
compilation. In such a compilation flow, the complete clock tree is not described, so the
variation between min and max operating conditions outside the block cannot be
automatically computed and must be manually modeled.

This constraint should only be used by advanced users as it is usually difficult to provide valid
latency values.

MMCM or PLL External Feedback Loop Delay

When the MMCM or PLL feedback loop is connected for compensating a board delay instead of
an internal clock insertion delay, you must specify the delay outside the device for both best and
worst delay cases by using the set_external_delay command. Failure to specify this delay
makes I/O timing analysis associated with the MMCM or PLL irrelevant and can potentially lead
to an impossible timing closure situation. Also, when using external compensation, you must
adjust the input and output delay constraint values accordingly instead of just considering the
clock trace delay on the board like in normal cases.

Constraining Input and Output Ports

In addition to specifying the location and I/O standard for each port of the design, input and
output delay constraints must be specified to describe the timing of external paths to/from the
interface of the device. These delays are defined relative to a clock that is usually also generated
on the board and enters the device. In some cases, the delays must be defined related to a virtual
clock when the I/O path is related to a clock that has a waveform different from the board clock.

IMPORTANT! I/O delays can only be constrained for interfaces using I/O logic, such as ISERDES/
OSERDES/IDDR/ODDR/IOB registers or fabric. For guidance on component mode timing, see Designing
Using SelectIO Interface Component Primitives (XAPP1324). For high-speed I/O interfaces created using
UltraScale device SelectIO native mode, see Answer Record 68618.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 158
 Chapter 4: Design Constraints

System Level Perspective

The I/O paths are modeled like register-to-register paths by the Vivado Design Suite timing
engine, except that you must define a constraint to model the part of the path delay located
outside the device. When analyzing internal paths, minimum and maximum delays are considered
for both setup and hold analysis. This is also true for I/O paths. For this reason, it is important to
describe both min and max delay conditions. The I/O timing paths are analyzed as single-cycle
paths by default, which means the following:

• For max delay analysis (setup), the data is captured one clock cycle after the launch edge for
single data rate interface, and half clock cycle after the launch edge for a double data rate
interface.
• For min delay analysis (hold), the data is launched and captured by the same clock edge.

If the relationship between the clock and I/O data must be timed differently, like for example in a
source synchronous interface, different I/O delays and additional timing exceptions must be
specified. This corresponds to an advanced I/O timing constraints scenario.

Defining Input Delays

The input delay is defined relative to a clock at the interface of the device. Unless
set_clock_latency has been specified on the source pin of the reference clock, the input
delay corresponds to the absolute time from the launch edge, through the clock trace, the
external device and the data trace. If clock latency has already been specified separately, you can
ignore the clock trace delay.

Figure 93: Input Delay Computation

FPGA DEVICE

Board
Internal Delay REGB
Device
DIN D Q
D Q Ddata
Tsetup
Tco
Thold

Input Delay

BUFG
CLK

Dclock_to_ExtDev Dclock_to_ FPGA

Board Clock Generator

X13450-121919

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 159
 Chapter 4: Design Constraints

The input delay values for the both types of analysis are:
Input Delay(max) = Tco(max) + Ddata(max) + Dclock_to_ExtDev(max) - Dclock_to_FPGA(min)
Input Delay(min) = Tco(min) + Ddata(min) + Dclock_to_ExtDev(min) - Dclock_to_FPGA(max)

The following figure shows a simple example of input delay constraints for both setup (max) and
hold (min) analysis, assuming the sysClk clock has already been defined on the CLK port:
set_input_delay -max -clock sysClk 5.4 [get_ports DIN]
set_input_delay -min -clock sysClk 2.1 [get_ports DIN]

Figure 94: Interpreting Min and Max Input Delays

Launch Edge
PERIOD
Source
Clock CLK

Min Input Delay

DIN Old Data New Data

Max Input Delay

Destination
Clock CLK

Capture Edge Capture Edge

(hold check) (setup check)
X13451-121919

A negative input delay means that the data arrives at the interface of the device before the
launch clock edge.

Defining Output Delays

Output delays are similar to input delays, except that they refer to the output path minimum and
maximum time outside the device to be functional under all conditions.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 160
 Chapter 4: Design Constraints

Figure 95: Output Delay Computation

FPGA DEVICE

Board
REGB Internal Delay
Device
D Q DOUT
Ddata D Q

Tco Tsetup
Thold
Output Delay

BUFG
CLK

Dclock_to_ FPGA Dclock_to_ExtDev

Board Clock Generator

X23060-111419

The output delay values for the both types of analysis are:
Output Delay(max) = Tsetup + Ddata(max) + Dclock_to_FPGA(max) - Dclock_to_ExtDev(min)
Output Delay(min) = Ddata(min) - Thold + Dclock_to_FPGA(min) - Dclock_to_ExtDev(max)

The following figure shows a simple example of output delay constraints for both setup (max) and
hold (min) analysis, assuming the sysClk clock has already been defined on the CLK port:
set_output_delay -max -clock sysClk 2.4 [get_ports DOUT]
set_output_delay -min -clock sysClk -1.1 [get_ports DOUT]

Figure 96: Interpreting Min and Max Output Delays

Launch Edge (FPGA)

PERIOD

Source
Clk CLK

DOUT Old Data New Data

Min Output Delay Max Output Delay

Destination
CLK TH(DestDev) TSU(DestDev) TH(DestDev)
Clk

Capture Edge Capture Edge

(hold check) (setup check)
X13453-121919

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 161
 Chapter 4: Design Constraints

The output delay corresponds to the delay on the board before the capture edge. For a regular
system synchronous interface where the clock and data board traces are balanced, the setup
time of the destination device defines the output delay value for max analysis. And the
destination device hold time defines the output delay for min analysis. The specified min output
delay indicates the minimum delay that the signal will incur after coming out of the design,
before it will be used for hold analysis at the destination device interface. Thus, the delay inside
the block can be that much smaller. A positive value for min output delay means that the signal
can have negative delay inside the design. This is why min output delay is often negative. For
example, the following code example indicates that the delay inside the design until DOUT has to
be at least +0.5 ns to meet the hold time requirement.

set_output_delay -min -0.5 -clock CLK [get_ports DOUT]

Choosing the Reference Clock

Depending on the clock tree topology that controls the sequential cells related to input or output
ports, you have to choose the most appropriate clock to define the input or output delay
constraints. If the clock of the I/O path register is a generated clock, the delay constraint usually
needs to be defined relative to the primary clock, which is defined upstream of the generated
clocks. There are some exceptions to this rule that are explained in this section.

Identifying the Clocks Related to Each Port

Before defining the I/O delay constraint, you must identify which clocks are related to each port.
You can identify the clocks using the methods described in the following sections.

Browse the Board Schematics

For a group of I/O ports connected to another device interface on the board, you can use the
board clock that is connected to both the Xilinx device and to the external device interface as the
reference clock for the input or output delay constraints. To control the timing of the related
group of ports, you must verify in the external device data sheet that the board clock is internally
transformed for timing the I/O ports, which ensures that the design generates the same clock
inside the Xilinx device.

Browse the Design Schematics

For each port, you can expand the path schematics to the first level of sequential cells, and then
trace the clock pins of those cells back to the clock source(s). This approach can be impractical
for ports that are connected to high fanout nets.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 162
 Chapter 4: Design Constraints

Report Timing from or to the Port

Whether a port is already constrained or not, you can use the report_timing command to
identify its related clocks in the design. Once all the timing clocks have been defined, you can
report the worst path from or to the I/O port, create the I/O delay constraint relative to the clock
reported, and rerun the same timing report from/to the other clocks of the design. If it appears
that the port is related to more than one clock, create the corresponding constraint and repeat
the process.

For example, the din input port is related to the clocks clk1 and clk2 inside the design:

report_timing -from [get_ports din] -sort_by group

The report shows that the din port is related to clk1. The input delay constraint is (for both min
and max delay in this example):

set_input_delay -clock clk1 5 [get_ports din]

Rerun timing analysis with the same command as previously, and observe that din is also related
to clk2 due to the -sort_by group option, which reports N paths per endpoint clock. You
can add the corresponding delay constraint and rerun the report to validate that the din port is
not related to another clock.

You can also run the same analysis using the Timing Summary report with the -
report_unconstrained option. With only clock constraints in your design, the
Unconstrained Paths section appears as follows:

------------------------------------------------
| Unconstrained Path Table
------------------------------------------------
Path Group From Clock To Clock
---------- ---------- --------
(none)
(none) clk1
(none) clk2
(none) clk1
(none) clk2

The fields without a clock name (or <NONE> in the Vivado IDE) refer to a group of paths where
the startpoints (From Clock) or the endpoints (To Clock) are not associated with a clock. The
unconstrained I/O ports fall in this category. You can retrieve their name by browsing the rest of
the report. For example in the Vivado IDE, by selecting the Setup paths for the clk1 to NONE
category, you can see the ports driven by clk1 in the To column:

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 163
 Chapter 4: Design Constraints

Figure 97: Getting a List of Unconstrained Output Ports

After adding the new constraints and applying them in memory, you must rerun the report to
determine which ports are still unconstrained. For most designs, you must increase the number
of reported paths to make sure all the I/O paths are listed in the report.

Use Automatically Identified Sampling Clocks

You can use the set_input_delay and set_output_delay constraints without specifying
the related clock. The Vivado Design Suite timing engine will analyze the design and associate
each port with all the sampling clocks automatically. Then by reporting timing on the I/O paths,
you can see how the tool constrained each I/O port. This is convenient for quickly constraining a
design, but this type of generic constraints can become a problem if they are too generic and do
not model the hardware reality accurately.

Using a Primary Clock

A primary clock (that is, an incoming board clock) should be used when it directly controls the I/O
path sequential cells, without traversing any clock modifying block. I/O delay lines are not
considered as clock modifying blocks because they only affect the clock insertion delay and not
the waveform. This case is illustrated by the two examples provided in Defining Input Delays and
Defining Output Delays. Most of the time, the external device also has its interface
characteristics defined with respect to the same board clock.

When the primary clock is compensated by a PLL or MMCM inside the device with the zero hold
violation (ZHOLD) mode, the I/O paths sequential cells are connected to an internal copy (for
example, a generated clock) of the primary clock. Because the waveforms of both clocks are
identical, Xilinx recommends using the primary clock as the reference clock for the input/output
delay constraints.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 164
 Chapter 4: Design Constraints

Figure 98: Input Delay in the Presence of a ZHOLD MMCM in Clock Path

mmcm
data_reg[0]
+
CLK IN1 CLK OUT1
CLK C
Input Delay
mmcm_zhold CE
Q
DIN_IBUF_inst CLR
I O
DIN D
IBUF
FDCE
X13454-121919

The constraints are identical to the example provided in Defining Input Delays because the
ZHOLD MMCM acts like a clock buffer with a negative insertion delay, which corresponds to the
amount of compensation.

Using a Virtual Clock

When the board clock traverses a clock modifying block which transforms the waveform in
addition to compensating the overall insertion delay, it is recommended to use a virtual clock as a
reference clock for the input and output delay instead of the board clock. There are three main
cases for using a virtual clock:

• The internal clock and the board clock have different period: The virtual clock must be defined
with the same period and waveform as the internal clock. This results in a regular single-cycle
path requirement on the I/O paths.
• For input paths, the internal clock has a positive shifted waveform compared to the board
clock: the virtual clock is defined like the board clock, and a multicycle path constraint of two
cycles for setup is defined from the virtual clock to the internal clock. These constraints force
the setup timing analysis to be performed with a requirement of one clock cycle + amount of
phase shift.
• For output paths, the internal clock has a negative shifted waveform compared to the board
clock: the virtual clock is defined like the board clock and a multicycle path constraint of two
cycles for setup is defined from the internal clock to the virtual clock. These constraints force
the setup timing analysis to be performed with a requirement of one clock cycle + amount of
phase shift.

To summarize, the use of a virtual clock adjusts the default timing analysis to avoid treating I/O
paths as clock domain crossing paths with a tight and unrealistic requirement.

IMPORTANT! You only need to use the multicycle path for I/O paths with phase-shifted clocks when the
phase-shift results in modification of the clock waveform. When the phase shift is added to the insertion
delay of the clock modifying block and the clock waveform is preserved, you do not need to use a
multicycle path. For more information, see this link in the Vivado Design Suite User Guide: Design Analysis
and Closure Techniques (UG906).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 165
 Chapter 4: Design Constraints

For example, consider the sysClk board clock that runs at 100 MHz and gets multiplied by an
MMCM to generate clk266 that runs at 266 MHz. An output that is generated by clk266
should use clk266 as the reference clock. If you try to use sysClk as the reference clock (for
the set_output_delay specification), it will appear as asynchronous clocks, and the path can
no longer be timed as a single cycle.

Using a Generated Clock

For an output source synchronous interface, the design generates a copy of the internal clock
and forwards it to the board along with the data. This clock is usually used as the reference clock
for the output data delay constraints whenever the intent is to control and report on the phase
relationship (skew) between the forwarded clock and the data. The forwarded clock can also be
used in input and output delay constraints for a system synchronous interface.

Rising and Falling Reference Clock Edges

The clock edges used in the I/O constraint must reflect the data sheet of the external device
connected to the device. By default, the set_input_delay and set_output_delay
commands define a delay constraint relative to the rising reference clock edge. You must use the
clock_fall option to specify a delay relative the falling clock edge. You can also specify
separate constraints for delays related to both rising and falling clock edges by using the
add_delay option with the second constraint on a port.

In most cases, the I/O reference clock edges correspond to the clock edges used to latch or
launch the I/O data inside the device. By analyzing the I/O timing paths, you can review which
clock edges are used and verify that they correspond to the actual hardware behavior. If by
mistake a rising clock edge is used as a reference clock for an I/O path that is only related to the
falling clock edge internally, the path requirement is ½-period, which makes timing closure more
difficult.

Verifying Delay Constraints

Once the I/O timing constraints have been entered, it is important to review how timing is
analyzed on the I/O paths and the amount of slack violation for both setup and hold checks. By
using the timing reports from/to all ports for both setup and hold analysis (that is, delay type
= min_max), you can verify that:

• The correct clocks and clock edges are used as reference for the delay constraints.
• The expected clocks are launching and capturing the I/O data inside the device.
• The violations can reasonably be fixed by placement or by setting the proper delay line tap
configuration. If this is not the case, you must review the I/O delay values entered in the
constraints and evaluate whether they are realistic, and whether you must modify the design
to meet timing.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 166
 Chapter 4: Design Constraints

I/O Path Report Command Lines Example

report_timing -from [all_inputs] -nworst 1000 -sort_by group \
-delay_type min_max

report_timing -to [all_outputs] -nworst 1000 -sort_by group \

-delay_type min_max

Improper I/O delay constraints can lead to impossible timing closure. The implementation tools
are timing driven and work on optimizing the placement and routing to meet timing. If the I/O
path requirements cannot be met and I/O paths have the worst violations in the design, the
overall design QoR will be impacted.

Input to Output Feed-through Path

There are several equivalent ways to constrain a combinatorial path from an input port to an
output port.

Example One
Use a virtual clock with a period greater or equal to the target maximum delay for the feed-
through path, and apply max input and output delay constraints as follows:

create_clock -name vclk -period 10

set_input_delay -clock vclk <input_delay_val> [get_ports din] -max
set_output_delay -clock vclk <output_delay_val> [get_ports dout] -max

where

input_delay_val(max) + feedthrough path delay (max) + output_delay_val(max)

<= vclk period.

In this example, only the maximum delay is constrained.

Example Two
Use a combination of min and max delay constraints between the feedthrough ports. Example:

set_max_delay -from [get_ports din] -to [get_ports dout] 10

set_min_delay -from [get_ports din] -to [get_ports dout] 2

This is a simple way to constrain both minimum and maximum delays on the path. Any existing
input and output delay constraints on the same ports are also used during the timing analysis. For
this reason, this style is not very popular.

The max delay is usually optimized and reported against the Slow timing corner, while the min
delay is in the Fast timing corner. It is best to run a few iterations on the feedthrough path delay
constraints to validate that they are reasonable and can be met by the implementation tools,
especially if the ports are placed far from one another.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 167
 Chapter 4: Design Constraints

Using XDC Templates - Source Synchronous Interfaces

Xilinx recommends using I/O constraint templates for the source synchronous interfaces. The
source synchronous constraints can be written in several ways. The templates provided by the
Vivado Design Suite are based on the default timing analysis path requirement. The syntax is
simpler, but the delay values must be adjusted to account for the fact that the setup analysis is
performed with different launch and capture edges (1-cycle or 1/2-cycle) instead of same edge
(0-cycle). The timing reports can be more difficult to read as the clock edges do not directly
correspond to the active ones in hardware. You can navigate to these templates in the Vivado
IDE through Tools → Language Templates → XDC → Timing Constraints → Input Delay
Constraints → Source Synchronous.

Defining Clock Groups and CDC Constraints

The Vivado IDE times the paths between all the clocks in your design by default. You can use the
following constraints to modify this default behavior:

• set_clock_groups: Disables timing analysis between groups of clocks that you identify but
not between the clocks within a same group.

• set_false_path: Disables timing analysis between the clocks only in the direction
specified by the -from and -to options.

In some cases, you might want to use the following constraints on one or more paths of the clock
domain crossing (CDC) to limit latency or bus skew:

• set_max_delay -datapath_only: Sets the maximum delay constraints on asynchronous

CDC paths to limit the latency.

Note: If clock groups or false path constraints already exist between the clocks or on the same CDC
paths, the maximum delay constraints will be ignored. Therefore, it is important to thoroughly review
every path between all clock pairs before choosing one CDC timing constraint over another to avoid
constraints collision.

RECOMMENDED: Xilinx also recommends running report_methodology to identify when a

set_max_delay -datapath_only constraint is overridden by a set_clock_groups or
set_false_path constraint.

• set_bus_skew: Constrains a set of signals between asynchronous CDC paths by bus skew
instead of latency.

TIP: You can also set a bus skew constraint from the Vivado IDE. In the Timing Constraints window,
expand Assertions, and double-click Set Bus Skew.

Related Information

Running Report Methodology

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 168
 Chapter 4: Design Constraints

Reviewing Clock Interactions

Clocks that have a logical path between them are timed. The possible clock relationships are
synchronous, asynchronous, and exclusive.

Synchronous
Clock relationships are synchronous when two clocks have a fixed phase relationship. This is the
case when two clocks share the following:

• Common circuitry (common node)

• Primary clock (same initial phase)

Asynchronous
Clock relationships are asynchronous when the clocks do not have a fixed phase relationship.
This is the case when one of the following is true for the clocks:

• Do not share any common circuitry in the design and do not have a common primary clock.
• Do not have a common period within 1000 cycles (unexpandable) and the timing engine
cannot properly time them together.
• Have a common clock but do not share a common node.
• Are part of a topology that does not ensure a known phase relationship through the clocks
auto-derivation process.

If two clocks are synchronous but their common period is very small, the setup paths
requirement is too tight for timing to be met. Xilinx recommends that you treat the two clocks as
asynchronous and implement safe asynchronous CDC circuitry.

Exclusive
Clock relationships are exclusive when they propagate on a same clock tree and reach the same
sequential cell clock pins but cannot physically be active at the same time.

Categorizing Clock Pairs

The clock pairs can be categorized by using the Clock Interaction and Check Timing reports.

Clock Interaction Report

The Clock Interaction report provides a high-level summary of how two clocks are timed
together:

• Do the two clocks have a common primary clock? When clocks are properly defined, all clocks
that originate from the same source in the design share the same primary clock.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 169
 Chapter 4: Design Constraints

• Do the two clocks have a common period? This shows in the setup or hold path requirement
column (unexpandable), when the timing engine cannot determine the most pessimistic setup
or hold relationship.
• Are the paths between the two clocks partially or completely covered by clock groups or
timing exception constraints?
• Is the setup path requirement between the two clocks very tight? This can happen, when two
clocks are synchronous, but their period is not specified as an exact multiple (for example, due
to rounding off). Over multiple clock cycles, the edges could drift apart, causing the worst case
timing requirement to be very tight.

Check Timing Report

The Check Timing report (multiple_clock) identifies the clock pins that are reached by more
than one clock and a set_clock_groups or set_false_path constraint has not already
been defined between these clocks.

Constraining Exclusive Clock Groups

You can use the regular timing or clock network reports to review the clock paths and identify
the situations where two clocks propagate on a same clock tree and are used at the same time in
a timing path where the startpoint and endpoint clock pins are connected to the same clock tree.
This analysis can be a time consuming task. Instead, you can review the multiple_clock
section of the Check Timing report. This section returns a list of clock pins and their associated
timing clocks.

Based on the clock tree topology, you must apply different constraints as described in the
following sections.

Overlapping Clocks Defined on the Same Clock Source

This occurs when two clocks are defined on the same netlist object with the create_clock -
add command and represent the multiple modes of an application. In this case, it is safe to apply
a clock groups constraint between the clocks. For example:

create_clock -name clk_mode0 -period 10 [get_ports clkin]

create_clock -name clk_mode1 -period 13.334 -add [get_ports clkin]
set_clock_groups -physically_exclusive -group clk_mode0 -group clk_mode1

If the clk_mode0 and clk_mode1 clocks generate other clocks, the same constraint needs to
be applied to their generated clocks as well, which can be done as follows:

set_clock_groups -physically_exclusive \
-group [get_clocks -include_generated_clock clk_mode0] \
-group [get_clocks -include_generated_clock clk_mode1]

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 170
 Chapter 4: Design Constraints

Overlapping Clocks Driven by a Clock Multiplexer

When two or more clocks drive into a multiplexer (or more generally a combinatorial cell), they all
propagate through and become overlapped on the fanout of the cell. Realistically, only one clock
can propagate at a time, but timing analysis allows reporting several timing modes at the same
time.

For this reason, you must review the CDC paths and add new constraints to ignore some of the
clock relationships. The correct constraints are dictated by how and where the clocks interact in
the design.

The following figure shows an example of two clocks driving into a multiplexer and the possible
interactions between them before and after the multiplexer.

Figure 99: Multiplexed Clocks

D Q
FD0

D Q D Q
FDM0 FDM1 C

clk0 I0
O
clk1 I1
D Q
B
FD1

X13455-121919

• Case in which the paths A, B, and C do not exist

clk0 and clk1 only interact in the fanout of the multiplexer (FDM0 and FDM1). It is safe to
apply the clock groups constraint to clk0 and clk1 directly.
set_clock_groups -logically_exclusive -group clk0 -group clk1

• Case in which only the paths A or B or C exist

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 171
 Chapter 4: Design Constraints

clk0 and/or clk1 directly interact with the multiplexed clock. To keep timing paths A, B, and
C, the constraint cannot be applied to clk0 and clk1 directly. Instead, it must be applied to
the portion of the clocks in the fanout of the multiplexer, which requires additional clock
definitions.
create_generated_clock -name clk0mux -divide_by 1 \
-source [get_pins mux/I0] [get_pins mux/O]

create_generated_clock -name clk1mux -divide_by 1 \

-add -master_clock clk1 \
-source [get_pins mux/I1] [get_pins mux/O]

set_clock_groups -physically_exclusive -group clk0mux -group clk1mux

Constraining Asynchronous Clock Groups and Clock Domain

Crossings
The asynchronous relationship can be quickly identified in the Clock Interaction report: clock
pairs with no common primary clock or no common period (unexpanded). Even if clock periods
are the same, the clocks will still be asynchronous, if they are being generated from different
sources. The asynchronous Clock Domain Crossing (CDC) paths must be reviewed carefully to
ensure that they use proper synchronization circuitry that does not rely on timing correctness
and that minimizes the chance for metastability to occur. Asynchronous CDC paths usually have
high skew and/or unrealistic path requirements. They should not be timed with the default timing
analysis, which cannot prove they will be functional in hardware.

Report CDC
The Report CDC (report_cdc) command performs a structural analysis of the clock domain
crossings in your design. You can use this information to identify potentially unsafe CDCs that
might cause metastability or data coherency issues. Report CDC is similar to the Clock
Interaction report, but Report CDC focuses on structures and related timing constraints. Report
CDC does not provide timing information because timing slack does not make sense on paths
that cross asynchronous clock domains.

Report CDC identifies the most common CDC topologies as follows:

• Single bit synchronizers

• Multi-bit synchronizers for buses
• Asynchronous reset synchronizers
• MUX and CE controlled circuitry
• Combinatorial logic before synchronizer
• Multi-clock fanin to synchronizer
• Fanout to destination clock domain

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 172
 Chapter 4: Design Constraints

For more information on the report_cdc command, see this link in the Vivado Design Suite User
Guide: Design Analysis and Closure Techniques (UG906). Also, see report_cdc in the Vivado Design
Suite Tcl Command Reference Guide (UG835).

Specific constraints should be applied to prevent default timing analysis on asynchronous clock
domain crossings.

Related Information

Global Constraints Between Clocks in Both Directions

Constraints on Individual CDC Paths

Global Constraints Between Clocks in Both Directions

When there is no need to limit the maximum latency, the clock groups can be used. Following is
an example to ignore paths between clkA and clkB:

set_clock_groups -asynchronous -group clkA -group clkB

When two master clocks and their respective generated clocks form two asynchronous domains
between which all the paths are properly synchronized, the clock groups constraint can be
applied to several clocks at once:

set_clock_groups -asynchronous \
-group {clkA clkA_gen0 clkA_gen1 } \
-group {clkB clkB_gen0 clkB_gen1 }

Or simply:

set_clock_groups -asynchronous \
-group [get_clocks -include_generated_clock clkA] \
-group [get_clocks -include_generated_clock clkB]

Constraints on Individual CDC Paths

If a CDC bus uses gray-coding (for example, FIFO) or if latency needs to be limited between the
two asynchronous clocks on one or more signals, you must use the set_max_delay constraint
with the option -datapath_only to ignore clock skew and jitter on these paths, plus override
the default path requirement by the latency requirement. It is usually sufficient to use the source
clock period for the max delay value, just to ensure that no more than one data is present on the
CDC path at any given time.

When the ratio between clock periods is high, choosing the minimum of the source and
destination clock periods is also a good option to reduce the transfer latency. A clean
asynchronous CDC path should not have any logic between the source and destination
sequential cells, so the Max Delay Datapath Only constraint is normally easy to meet for the
implementation tools.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 173
 Chapter 4: Design Constraints

Some asynchronous CDC paths require a skew control between the bits of the bus instead of a
constraint on the bus latency. Using a bus skew constraint prevents the receiving clock domain
from latching multiple states of the bus on the same clock edge. You can set the bus skew
constraint on the bus with set_bus_skew command. For example, you can apply
set_bus_skew to a CDC bus that uses gray-coding instead of using the Max Delay Datapath
Only constraint. For more information, see this link in the Vivado Design Suite User Guide: Using
Constraints (UG903).

For the paths that do not need latency control, you can define a point-to-point false path
constraint.

Clock Exceptions Precedence Over set_max_delay

When writing the CDC constraints, verify that the precedence is respected. If you use
set_max_delay -datapath_only on at least one path between two clocks, the
set_clock_groups constraint cannot be used between the same clocks, and the
set_false_path constraint can only be used on the other paths between the two clocks.

In the following figure, the clock clk0 has a period of 5 ns and is asynchronous to clk1. There
are two paths from the clk0 domain to the clk1 domain. The first path is a 1-bit data
synchronization. The second path is a multi-bit gray-coded bus transfer.

Figure 100: Multiple Interactions Between Two Asynchronous Clocks

GCB0[N..0] GCB1a[N..0] GCB1b[N..0]

D Q D Q D Q

REG0 REG1a REG1b

D Q D Q D Q

clk0 IBUF0 BUFG0 BUFG1 IBUF1 clk1

X13456-121919

The designer decides that the gray-coded bus transfer requires a Max Delay Datapath Only to
limit the delay variation among the bits, so it becomes impossible to use a Clock Groups or False
Path constraint between the clocks directly. Instead, two constraints must be defined:

set_max_delay -from [get_cells GCB0[*]] -to [get_cells [GCB1a[*]] \

-datapath_only 5
set_false_path -from [get_cells REG0] -to [get_cells REG1a]

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 174
 Chapter 4: Design Constraints

There is no need to set a false path from clk1 to clk0 because there is no path in this example.

Specifying Timing Exceptions

Timing exceptions are used to modify how timing analysis is done on specific paths. By default,
the timing engine assumes that all paths should be timed with a single cycle requirement for
setup analysis to cover the most pessimistic clocking scenario. For certain paths, this is not true.
Following are a few examples:

• Asynchronous CDC paths cannot be safely timed due to the lack of fixed phase relationship
between the clocks. They should be ignored (Clock Groups, False Path), or simply have
datapath delay constraint (Max Delay Datapath Only)
• The sequential cells launch and capture edges are not active at every clock cycle, so the path
requirement can be relaxed accordingly (Multicycle Path)
• The path delay requirement needs to be tightened to increase the design margin in hardware
(Max Delay)
• A path through a combinatorial cell is static and does not need to be timed (False Path, Case
Analysis)
• The analysis should be done with only a particular clock driven by a multiplexer (Case
Analysis).

In any case, timing exceptions must be used carefully and must not be added to hide real timing
problems.

Timing Exceptions Guidelines

Use a limited number of timing exceptions and keep them simple whenever possible. Otherwise,
you will face the following challenges:

• The implementation compile time significantly increases when many exceptions are used,
especially when they are attached to a large number of netlist objects.
• Constraints debugging becomes extremely complicated when several exceptions cover the
same paths.
• Presence of constraints on a signal can hamper the optimization of that signal. Therefore,
including unnecessary exceptions or unnecessary points in exception commands can hamper
optimization.

Following is an example of timing exceptions that can negatively impact the run time:

set_false_path -from [get_ports din] -to [all_registers]

• If the din port does not have an input delay, it is not constrained. So there is no need to add a
false path.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 175
 Chapter 4: Design Constraints

• If the din port feeds only to sequential elements, there is no need to specify the false path to
the sequential cells explicitly. This constraint can be written more efficiently:
set_false_path -from [get_ports din]

• If the false path is needed, but only a few paths exist from the din port to any sequential cell
in the design, then it can be more specific (all_registers can potentially return thousands
of cells, depending upon the number of registers used in the design):
set_false_path -from [get_ports din] -to [get_cells blockA/config_reg[*]]

Timing Exceptions Precedence and Priority Rules

Timing exceptions are subject to strict precedence and priority rules. The most important rules
are as follows:

• The more specific the constraint, the higher the priority. For example:
set_max_delay -from [get_clocks clkA] -to [get_pins inst0/D] 12
set_max_delay -from [get_clocks clkA] -to [get_clocks clkB] 10

The first set_max_delay constraint has a higher priority because the -to option uses a pin,
which is more specific than a clock.
• The exceptions priority is as follows:
1. set_false_path
2. set_max_delay or set_min_delay
3. set_multicycle_path

The set_clock_groups command is not considered a timing exception even though it is

equivalent to two set_false_path commands between two clocks. It has higher precedence
than the timing exceptions.

The set_case_analysis and set_disable_timing commands disable timing analysis on

specific portions of the design. They have higher precedence than the timing exceptions.

For details on XDC precedence and priorities, see this link in the Vivado Design Suite User Guide:
Using Constraints (UG903).

Adding False Path Constraints

False path exceptions can be added to timing paths to ignore slack computation on these paths.
It is usually difficult to prove that a path does not need timing to be functional, even with
simulation tools. Xilinx does not usually recommend using a false path unless the risk associated
with it has been properly assessed and appear to be acceptable.

Use Cases
The typical cases for using the false path constraint are:

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 176
 Chapter 4: Design Constraints

• Ignoring timing on a path that is never active. For example, a path that crosses two
multiplexers that can never let the data propagate in a same clock cycle because of the select
pins connectivity.

Figure 101: Path Cannot be Sensitized

MUX0 MUX1
REG0 REG1
D Q I0 I0 D Q
O O
I1 I1
S S

X13457-121919

set_false_path -through [get_pins MUX0/I0] -through [get_pins MUX1/I1]

• Ignoring timing on an asynchronous CDC path.

• Ignoring static paths in the design. Some registers take a value once during the initialization
phase of the application and never toggle again. When they appear to be on the critical path
of the design, they can be ignored for timing to relax the constraints on the implementation
tools and help with timing closure. It is sufficient to define a false path constraint from the
static register only, without explicitly specifying the paths endpoints. For example, the paths
from a 32-bit configuration register config_reg[31..0] to the rest of the design can be
ignored by adding the following false path constraint:
set_false_path -from [get_cells config_reg[*]]

Impact on Implementation

All the implementation steps are sensitive to the false path timing exception.

Impact on Synthesis
The false path constraint is supported by synthesis and only impacts max delay (setup/recovery)
path optimization. False path exceptions are recommended for portions of the design where
timing can safely be ignored and for asynchronous CDC paths with no datapath delay
requirements.

Impact on Implementation
All the implementation steps are sensitive to the false path timing exception.

Adding Min and Max Delay Constraints

The min and max delay exceptions are used to override the default path requirement respectively
for hold/removal and setup/recovery checks by replacing the launch and capture edge times with
the delay value from the constraint.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 177
 Chapter 4: Design Constraints

Use Cases
Common reasons for using the min or max delay constraints are as follows:

• Overconstraining a few paths of the design by tightening the setup/recovery path

requirement.
This is useful for forcing the logic optimization or placement tools to work harder on some
critical path cells, which can provide more flexibility to the router to meet timing later on (after
removing the max delay constraint).
• Replacing a multicycle constraint.
This is a valid but not recommended way to relax the setup requirement on a path that has
active launch and capture edges every N clock cycles. Although it is the only option to
overconstrain a multicycle path by a fraction of a clock period to help with timing closure
during the routing step. For example, a path with a multicycle constraint of 3 appears to be
the worst violating path after route and fails timing by a few hundred ps.
The original multicycle path constraint can be replaced by the following constraint during
optimization and placement, where 14.5 corresponds to 3 clock periods (of 5 ns each), minus
500 ps that correspond to amount of extra margin desired:
set_max_delay -from [get_pins <startpointCell>/C] \
-to [get_pins <endpointCell>/D] 14.5

• Constraining the maximum datapath delay on asynchronous CDC paths

This technique is described in Defining Clock Groups and CDC Constraints.

It is not common or recommended to force extra delay insertion on a path by using the
set_min_delay constraint. The default min delay requirement for hold or removal is usually
sufficient to ensure proper hardware functionality when the slack is positive.

Impact on Synthesis
The set_max_delay constraint is supported by synthesis, including the -datapath_only
option. The set_min_delay constraint is ignored.

Impact on Implementation
The set_max_delay constraint replaces the setup path requirement and influences the entire
implementation flow. The set_min_delay constraint replaces the hold path requirement and
only affects the router behavior whenever it introduces the need to fix hold.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 178
 Chapter 4: Design Constraints

Avoiding Path Segmentation

Path segmentation is introduced when specifying invalid startpoint or endpoint for the -from or
-to options of the set_max_delay and set_min_delay commands only. When a
set_max_delay introduces path segmentation on a path, the default hold analysis no longer
takes place. You must constrain the same path with set_min_delay if you desire to constrain
the hold analysis as well. The same rule applies with the set_min_delay command relative to
the setup analysis.

Path segmentation must only be used by experts as it alters the fundamentals of timing analysis:

• Path segmentation breaks clock skew computation on the segmented path.

• Path segmentation can break more paths than the one constrained by the segmenting
set_max_delay or set_min_delay command.

Valid Startpoints and Endpoints

Path segmentation is reported by the tools in the log file when the constraints are applied. You
must avoid it by using valid startpoints and endpoints:

• Startpoints: Clock, clock pin, sequential cell (implies valid startpoint pins of the cell), input or
inout port.

• Endpoints: Clock, input data pin of sequential cell, sequential cell (implies valid endpoint pins
of the cell), output or inout port.

For details on path segmentation, see this link in the Vivado Design Suite User Guide: Using
Constraints (UG903).

Adding Multicycle Path Constraints

Multicycle path exceptions must reflect the design functionality and must be applied on paths
that do not have an active clock edge at every cycle, on either the source clock, the destination
clock or both clocks. The path multiplier is expressed in terms of clock cycles, either based on the
source clock when the -start option is used, or the destination clock when the -end option is
used. This is particularly convenient for modifying the setup and hold relationships between the
startpoint and endpoint independently of the clock period value.

The hold relationships are always tied to the setup ones. Consequently, in most cases, the hold
relationship also needs to be separately adjusted after the setup one has been modified. This is
why a second constraint with the -hold option is needed. The main exception to this rule is for
synchronous CDC paths between phase-shifted clocks: only setup needs to be modified.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 179
 Chapter 4: Design Constraints

Relaxing the Setup Requirement While Keeping Hold Unchanged

This occurs when the source and destination sequential cells are controlled by a clock enable
signal that activates the clock every N cycles. The following example has a clock enable active
every three cycles, with the same clock for both startpoint and endpoint:

Figure 102: Enabled Flops with Same Clock Signal

REGA REGB
D Q D Q

EN EN

X13458-121919

Figure 103: Timing Diagram for Setup/Hold Check

BEFORE
launch edge

Source clock (REGA)

Setup
Hold (default) Hold (default) active edges
(default)

Destination clock (REGB)

capture edge

Clock Enable
X13459-121919

Constraints:

set_multicycle_path -from [get_pins REGA/C] -to [get_pins REGB/D] -setup 3

set_multicycle_path -from [get_pins REGA/C] -to [get_pins REGB/D] -hold 2

Figure 104: Setup/Hold Checks Modified After Multicycle Specification

AFTER
launch edge

Source clock (REGA)

Hold Setup Hold

Destination clock (REGB)

capture edge

Clock Enable
X13460-121919

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 180
 Chapter 4: Design Constraints

Note: With the first command, as the setup capture edge moved to the third edge (that is, by two cycles
from its default position), the hold edge also moved by two cycles. The second command is for bringing the
hold edge back to its original location by moving it again by two cycles (in the reverse direction).

For more information on other common multicycle path scenarios, such as phase shift and
multicycle paths between synchronous clocks, see this link in the Vivado Design Suite User Guide:
Using Constraints (UG903).

IMPORTANT! When the clock phase shift does not modify the clock waveform but is instead included in
the insertion delay of the clock modifying block, you do not need to add a setup-only multicycle path to
properly time the path from or to the clock. For more information, see this link in the Vivado Design Suite
User Guide: Design Analysis and Closure Techniques (UG906).

Impact on Synthesis and Implementation

The set_multicycle_path constraint is supported by synthesis and can greatly improve the
timing QoR (for setup only) by relaxing long paths that are functionally not active at every clock
cycle.

As for synthesis, multicycle path exceptions help the implementation timing-driven algorithms to
focus on the real critical paths. The hold requirements are important only during routing. If a
setup relationship was adjusted with a set_multicycle_path constraint but not its
corresponding hold relationships, the worst hold requirement may become too hard to meet if it
is over 2 or 3 ns. This situation can have a negative impact on setup slack because of the
additional delay inserted by the router while fixing hold violations.

Common Mistakes
Following are common mistakes that you must avoid:

• Relaxing setup without adjusting hold back to same launch and capture edges in the case of a
multicycle path not functionally active at every clock cycle.
The hold requirement can become very high (at least one clock period in most cases) and
impossible to meet.
• Setting a multicycle path exception between incorrect points in the design.
This occurs when you assume that there is only one path from a startpoint cell to an endpoint
cell. In some cases, this is not true. The endpoint cell can have multiple data input pins,
including clock enable and reset pins, which are active on at least two consecutive clock
edges.
For this reason, Xilinx recommends that you specify the endpoint pin instead of just the cell
(or clock). For example, the endpoint cell REGB has three input pins: C, EN and D. Only the
REGB/D pin should be constrained by the multicycle path exception, not the EN pin because
it can change at every clock cycle. If the constraint is attached to a cell instead of a pin, all the
valid endpoint pins are considered for the constraints, including the EN (clock enable) pin.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 181
 Chapter 4: Design Constraints

To be safe, Xilinx recommends that you always use the following syntax:
set_multicycle_path -from [get_pins REGA/C] \
-to [get_pins REGB/D] -setup 3
set_multicycle_path -from [get_pins REGA/C] \
-to [get_pins REGB/D] -hold 2

Other Advanced Timing Constraints

A few other timing constraints can be set to ignore and modify the default timing analysis as
described in the following sections.

Case Analysis
The case analysis command is commonly used to describe a functional mode in the design by
setting constants in the logic like what configuration registers do. It can be applied to input ports,
nets, hierarchical pins, or leaf cell input pins. The constant value propagates through the logic and
turns off the analysis on any path that can never be active. The effect is similar to how the false
path exception works.

The most common example is to set a multiplexer select pin to 0 or 1 to only allow one of the
two multiplexer inputs to propagate through. The following example turns off the analysis on the
paths through the mux/S and mux/I1 pins:

set_case_analysis 0 [get_pins mux/S]

Disable Timing
The disable timing command turns off a timing arc in the timing database, which completely
prevents any analysis through that arc. The disabled timing arcs can be reported by the
report_disable_timing command.

CAUTION! Use the disable timing command carefully. It can break more paths than desired!

Data Check
The set_data_check command sets the equivalent of a setup or hold timing check between
two pins in a design. For example, this constraint can be used to report timing on asynchronous
interfaces. This command is ignored by the implementation tools and must only be used for
timing reporting purposes, typically by expert users.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 182
 Chapter 4: Design Constraints

Max Time Borrow

The set_max_time_borrow command sets the maximum amount of time a latch can borrow
from the next stage (logic after the latch), and give it the previous stage (logic before the latch).
Latches are not recommended in general as they are difficult to test and validate in hardware.
This command should be used by expert users.

Defining Power and Thermal Constraints

When developing your design in the Vivado tools or Vitis environment, you must ensure that
your design is within the constraints of your power delivery and thermal solution, which is
typically based on early power estimation as determined by Xilinx Power Estimator (XPE). It is
extremely important to ensure your design is properly constrained, because changes to your
power delivery and thermal solution can be costly.

At a minimum, Xilinx recommends applying the total power budget, maximum process, and
worst-case junction temperature to create a worst-case power analysis, using the following XDC
constraints:

set_operating_conditions -design_power_budget <Power in Watts>

set_operating_conditions -process maximum
set_operating_conditions -junction_temp <Max Tj based on Temp Grade>

POWER TIP: For a worst-case power estimation and until the Theta Ja (ΘJa) of the thermal solution is
known, Xilinx recommends setting the Tj to the maximum allowed for the targeted temperature range.
Theta Ja can be calculated as follows based on the thermal simulation result: ΘJa = (Tj – Ta)/ Pd.
Units are Celsius per watt (°C/W).

The most accurate power estimation can be achieved after the Theta Ja of the thermal design is
known. You can apply the Theta Ja and the maximum supported ambient temperature (Ta) of the
application to report_power using the following constraints to replace the junction
temperature setting. Using these constraints allows report_power to estimate the junction
temperature more accurately and therefore, give a more accurate static power estimation.

set_operating_conditions -design_power_budget <Power in Watts>

set_operating_conditions -process maximum
set_operating_conditions -ambient_temp <Max Supported by Application>
set_operating_conditions -thetaja <Increase in Tj for every W dissipated
C/W>

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 183
 Chapter 4: Design Constraints

In addition, you can specify the power delivery design using XDC constraints. Using this
approach allows report_power to report the margin on the total power, check the power
estimation on the power rails, and report the margin based on the specified estimation and
power rail consolidation. For more information on these constraints, see the Vivado Design Suite
User Guide: Power Analysis and Optimization (UG907).

create_power_rail <power rail name> -power_sources {supply1, supply2 ,..}

add_to_power_rail <power rail name> -power_sources {supply1, supply2, ..}
set_operating_conditions -supply_current_budget {<supply rail name>
<current budget in Amp>} -voltage {<supply rail name> <voltage>}

POWER TIP: Ensure the text power report is used for the most detailed power rail constraints reporting.

Defining Physical Constraints

Physical constraints are used to control floorplan, specific placement, I/O assignments, routers
and similar functions. Make sure that each pin has an I/O location and standard specified.
Physical constraints are covered in the following user guides:

• For locking placement and routing, including relative placement of macros, see the Vivado
Design Suite User Guide: Using Constraints (UG903).
• For floorplanning, see the Vivado Design Suite User Guide: Design Analysis and Closure
Techniques (UG906).
• For configuration, see the Vivado Design Suite User Guide: Programming and Debugging (UG908).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 184
 Chapter 5: Design Implementation

Chapter 5

Design Implementation
After selecting your device, choosing and configuring the IP, and writing the RTL and the
constraints, the next step is implementation. Implementation compiles the design through
synthesis and place and route, and then generates the file that is used to program the device. The
implementation process might have some iterative loops. This chapter describes the various
implementation steps, highlights points for special attention, and gives tips and tricks to identify
and eliminate specific bottlenecks.

IMPORTANT! You must regularly validate that synthesis and implementation occur without errors and
with minimal timing violations before adding new blocks or generating a platform for the Vitis™ tools.

Note: The implementation steps are run automatically as part of the Vitis environment flow. You can
improve performance by applying the techniques described in this chapter using the Vitis command line
options and configuration file. For more information, see the Vitis Unified Software Platform Documentation.

Running Synthesis
Synthesis takes in RTL and timing constraints and generates an optimized netlist that is
functionally equivalent to the RTL. In general, the synthesis tool can take any legal RTL and
create the logic for it. Synthesis requires realistic timing constraints.

For additional information about synthesis, refer to the following resources:

• Vivado Design Suite User Guide: Synthesis (UG901)

• Vivado Design Suite QuickTake Video: Design Flows Overview

Related Information

Design Constraints
Baselining the Design

Synthesis Flows
In the Vivado® Design Suite, you can run the synthesis flows described in the following sections,
which each have different advantages and trade-offs.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 185
 Chapter 5: Design Implementation

Global Synthesis
In the global synthesis flow, the full design is synthesized in one run, which offers the following
advantages:

• Allows the synthesis tool to perform the maximum optimization. Because the synthesis tool is
aware of the full design, the tool can optimize between hierarchies that other flows might not.
• Enables easy analysis after the synthesis run.

The disadvantage of this flow is longer compile time. Every time synthesis is run, the full design is
rerun. However, this disadvantage can be mitigated by using incremental synthesis.

Note: If your design includes XDC constraints, you must reference the objects to the top-level design.

Related Information

Incremental Synthesis

Block Design Synthesis

The block design synthesis flow allows you to create complex systems using custom and Xilinx IP.
In this flow, a block design (BD) file is created using the Vivado IP integrator. Xilinx or custom IP
is added to the .bd file and connected as a system. This flow offers the following advantages:

• Encapsulates a great deal of functionality into a small design.

• Allows focus on the system rather than individual parts of the system.
• Enables easier and faster setup and synthesis of the design.

The following figure shows an example of a block design.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 186
 Chapter 5: Design Implementation

Figure 105: Block Design Example

When creating the block design, you can run synthesis using either out-of-context (OOC)
synthesis mode or global synthesis mode. If you use out-of-context synthesis mode, the block
design is synthesized separately from the rest of the design. This allows for faster resynthesis
when hierarchies outside the BD file are modified. If you use global synthesis mode, the full
design is compiled and synthesized each time. Global synthesis mode is easier to set up because
constraints are set on a global level. However, using this mode results in a higher run time on
resynthesis. You can improve run time using incremental synthesis.

Out-of-Context Synthesis
In the out-of-context (OOC) synthesis flow, certain levels of hierarchy are synthesized separately
from the top-level. The out-of-context hierarchy are synthesized first. Then, the top-level
synthesis is run, and each of the out-of-context runs are treated as a black box. Xilinx IP are often
run in out-of-context synthesis mode. After all of the out-of-context synthesis runs and top-level
synthesis runs are complete, the Vivado tools assemble the design from all of the synthesis runs
when you open the top-level synthesized design. This flow offers the following advantages:

• Reduces compile time for subsequent synthesis runs. Only the runs you specify are
resynthesized, leaving the other runs as is.
• Ensures stability when design changes are made. Only the runs that include changes are
resynthesized.

The disadvantage of this flow is that it requires additional setup. You must be careful in selecting
which modules to set as out-of-context synthesis modules. Any additional XDC constraints must
be defined separately and must only be used for the out-of-context synthesis runs.

The following figure shows a design that has a top-level synthesis run (synth_1) and two lower-
level out-of-context synthesis runs.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 187
 Chapter 5: Design Implementation

Figure 106: Top-Level Synthesis with Two Out-of-Context Synthesis Runs

For more information on setting up out-of-context synthesis runs, see this link in the Vivado
Design Suite User Guide: Synthesis (UG901).

Incremental Synthesis
You can use incremental synthesis to reuse existing synthesis results. This approach reduces
typical synthesis compile times by 50%. When used with the incremental implementation flow,
this approach also improves overall compile time and timing closure consistency.

When a design is synthesized, it is broken into RTL partitions. Incremental synthesis reuses RTL
partitions from a previous synthesis run. RTL partitions are typically created along logical
hierarchies. Incremental synthesis only runs if the design is large enough that synthesis creates at
least 4 RTL partitions, each containing at least 25000 instances. Instances include both logical
hierarchy and RTL primitives.

Following are the different modes available when using the synth_design -
incremental_mode <value> command:

• off: Incremental synthesis is not run.

• quick: Fastest results but no cross boundary optimizations. This mode limits logic
performance.

• default: Most logic optimizations enabled, including cross-boundary optimization. Compile

time is significantly reduced from non-incremental synthesis.

• aggressive: All optimizations are enabled. Compile time is significantly reduced from non-
incremental synthesis.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 188
 Chapter 5: Design Implementation

The quick mode is typically recommended for low-performance designs only. Without cross
boundary optimizations, typical designs have reduced performance. However, if a design is well
constructed with registered hierarchical boundaries, performance might not be affected. Due to
the limits on cross-boundary optimization, resynthesis in a given area is caused by RTL changes
only in that area. Changes in another synthesis partition do not trigger changes beyond that
partition. This leads to more reuse and a faster synthesis result. For other modes, this is not the
case, and RTL changes might trigger the resynthesis of more partitions beyond just the partition
the cell is in. When more than 50% of partitions are modified, a full resynthesis is triggered.

For high-performance designs, the default, aggressive, and off modes are recommended.
More optimizations are enabled in aggressive and off modes, which might lead to more
resynthesis but higher QoR.

To more aggressively address compile time concerns, you can compare the incremental synthesis
against OOC synthesis. OOC synthesis is typically used by IP, and setup is automatic. Global
synthesis with incremental synthesis offers the advantage of cross-boundary optimizations as
well as compile time benefits. Following are areas to consider:

• Compile time
OOC synthesis is faster, because it reduces the amount of code that is elaborated each time.
RTL is only elaborated if the RTL is modified within the OOC module.
• Performance
Incremental synthesis has a performance advantage over OOC synthesis, because
optimization is not possible across OOC boundaries.
• Setup
For non-IP flows, when you create an OOC synthesis run, you must create a wrapper when
generics/parameters are passed from higher modules. In addition, you must create a separate
timing constraint file to target the OOC-level ports. Incremental synthesis does not have these
requirements.

For more information, see the Vivado Design Suite User Guide: Synthesis (UG901).

Synthesis Optimizations
By default, Vivado synthesis applies optimizations that yield the best results for the largest
number of designs. However, you can adjust the default synthesis optimizations as described in
the following sections.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 189
 Chapter 5: Design Implementation

Synthesis Settings
You can set several global settings that affect the entire design using the Vivado Design Suite
Synthesis Settings. These settings optimize how logic is inferred and how incremental synthesis is
run. Xilinx recommends using default options when you start your design and changing the
options based on the specific needs of your design. For more information, see this link in the
Vivado Design Suite User Guide: Synthesis (UG901).

Figure 107: Vivado Synthesis Settings

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 190
 Chapter 5: Design Implementation

Synthesis Attributes
Synthesis attributes allow you to control the logic inference in a specific way. Although synthesis
algorithms are set to give the best results for the largest number of designs, there are often
designs with differing requirements. In this case, you can use attributes to alter the design to
improve QoR. For information on the attributes supported by synthesis, see the Vivado Design
Suite User Guide: Synthesis (UG901).

POWER TIP: Evaluate synthesis settings carefully, because these settings can have a considerable impact
on the power consumption of a design. For example, a low setting for the control set threshold increases
the usage of register clock enables at the expense of less dense packing. Run the report_power
command after synthesis to evaluate the impact of synthesis settings on power.

Note: Before retargeting your design to a new device, Xilinx recommends reviewing any synthesis
attributes from previous design runs that target older devices.

When using the KEEP, DONT_TOUCH, and MAX_FANOUT attributes, be aware of the special
considerations described in the following sections.

KEEP and DONT_TOUCH

KEEP and DONT_TOUCH are valuable attributes for debugging a design. They direct the tool to
not optimize the objects on which they are placed.

• KEEP is used by the synthesis tool and is not passed along as a property in the netlist. KEEP
can be used to retain a specific signal, for example, to turn off specific optimizations on the
signal during synthesis.
• DONT_TOUCH is used by the synthesis tool and then passed along to the place and route
tools so the object is never optimized.

Take care when using these attributes:

• A KEEP attribute on a register that receives RAM output prevents that register from being
merged into the RAM, thereby preventing a block RAM from being inferred.
• Do not use these attributes on a level of hierarchy that is driving a 3-state output or
bidirectional signal in the level above. If the driving signal and the 3-state condition are in this
level of hierarchy, the IOBUF is not inferred, because the tool must change the hierarchy to
create the IOBUF.
• Attributes that disable optimization often result in larger, higher power-consuming circuits.
Xilinx recommends using these controls sparingly and removing them when no longer needed.

Also, be aware that there is a difference between putting DONT_TOUCH on a signal or on a level
of hierarchy:

• If the attribute is placed on a signal, that signal is kept.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 191
 Chapter 5: Design Implementation

• If the attribute is placed on a level of hierarchy, the tool does not touch the boundaries of that
hierarchy, and no constant propagation occurs through the hierarchy. However, optimizations
inside that level of hierarchy are retained.

MAX_FANOUT
MAX_FANOUT forces the synthesis to replicate logic to meet a fanout limit. The tool is able to
replicate logic, but not inputs or black boxes. Accordingly, if a MAX_FANOUT attribute is placed
on a signal that is driven by a direct input to the design, the tool is unable to handle the
constraint.

Take care to analyze the signals on which a MAX_FANOUT is placed. If a MAX_FANOUT is

placed on a signal that is driven by a register with a DONT_TOUCH or drives signals that are in a
different level of hierarchy when the DONT_TOUCH attribute is on that hierarchy, the
MAX_FANOUT attribute will not be honored.

Synthesis appends the replicated cells with _rep for the first replication and subsequent
replications are _rep__0, _rep__1 and so on. These cells can be seen in the post synthesized
netlist by selecting Edit → Find on cells.

IMPORTANT! Use MAX_FANOUT sparingly during synthesis. The place_design and

phys_opt_design commands in the Vivado® tools perform placement-based replication, which is
more effective than logical replication in synthesis. If a specific fanout is desired, it is often worth the time
and effort to manually code the extra registers.

Block-Level Synthesis Strategy

With Vivado synthesis, you can use various strategies and global settings to customize how the
design is synthesized. In most cases, these options are global and affect the entire design. You
can use the block-level synthesis strategy to synthesize different levels of hierarchy with
different global options in a top-down flow. This flow is faster and easier to perform than a
bottom-up compile. You can set constraints for the full design rather than setting constraints for
a lower level and then resetting for the top level.

Set the block-level synthesis strategy in the XDC file using the following syntax:

set_property BLOCK_SYNTH.<option_name> <value> [get_cells <instance_name>]

Where:

• <option_name> is the option to be set.

• <value> is the value to be assigned to the option.
• <instance_name> is the hierarchical instance on which to set the option.

Note: These properties are always set on hierarchical instances. This allows modules or entities that are
instantiated more than once to be synthesized with different options.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 192
 Chapter 5: Design Implementation

For example, you can set the following strategies in an XDC file:

set_property BLOCK_SYNTH.RETIMING 1 [get_cells U1]

set_property BLOCK_SYNTH.STRATEGY {AREA_OPTIMIZED} [get_cells U2]
set_property BLOCK_SYNTH.STRATEGY {AREA_OPTIMIZED} [get_cells U3]
set_property BLOCK_SYNTH.STRATEGY {DEFAULT} [get_cells U3/inst1]

Vivado synthesis is performed as shown in the following figure.

Figure 108: Block-Level Synthesis Strategy Example

Top (default settings)

U1 U2

retiming area

U3
inst1
area
default

X19285-121919

You can set multiple BLOCK_SYNTH properties on the same instance to experiment with
different options. For example:

set_property BLOCK_SYNTH.STRATEGY {ALTERNATE_ROUTABILITY} [get_cells inst]

set_property BLOCK_SYNTH.FSM_EXTRACTION {OFF} [get_cells inst]

When working with IP, you can use the block-level synthesis strategy as follows:

• If the IP is compiled globally, you can use this strategy on the top level of the IP.
• If the IP is out-of-context, you cannot use the strategy, because the IP appears as a black box.
Instead, use global settings when compiling the IP.

Note: For more information on this feature and the supported strategies and options, see the Vivado Design
Suite User Guide: Synthesis (UG901).

Moving Past Synthesis

Be sure that the netlist you obtained during synthesis is of good quality so that it does not create
problems downstream. The following sections cover important items to check before proceeding
with the rest of the implementation flow.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 193
 Chapter 5: Design Implementation

Reviewing and Cleaning DRCs

The report_drc command runs design rule checks (DRCs) to look for common design issues
and errors. There are multiple rule decks. The default rule deck checks the following:

• Post-synthesis netlist
• I/O, BUFG, and other placement specific requirements
• Attributes and wiring on MGTs, IODELAYs, MMCMs, PLLs and other primitives

RECOMMENDED: Review and correct DRC violations as early as possible in the design process to avoid
timing or logic related issues later in the implementation flow.

TIP: For DRC violations that can be safely ignored, you can use the waiver mechanism to waive the
violations. For details, see this link in the Vivado Design Suite User Guide: Design Analysis and Closure
Techniques (UG906).

Running Report Methodology

The Vivado tools provide a Methodology Report that specifically checks for compliance with
methodology. The tools run different checks depending on the stage of the design process:

• RTL design: RTL lint-style checks

• Synthesized and implemented designs: Netlist, constraints, and timing checks

In Project Mode, the tools automatically run Report Methodology during implementation
(opt_design or route_design) by default. To run these checks manually, use either of the
following methods:

• At the Tcl prompt, open the design to be validated, and enter following Tcl command:
report_methodology
• To run these checks from the Vivado IDE, open the design to be validated, and select Reports
→ Report Methodology.

RECOMMENDED: To identify common design issues, run this report the first time you synthesize the
design. Run this report again after significant module additions, constraint changes, or clocking circuit
changes.

Note: For Xilinx®-supplied IP cores, the violations are already reviewed and checked.

Any violations are listed in the Methodology window, as shown in the following figure. If a
specific methodology violation does not need to be fixed, make sure that you understand the
violation and its implication clearly and why the violation does not negatively impact your design.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 194
 Chapter 5: Design Implementation

IMPORTANT! You must resolve all Critical Warnings and most Warnings to ensure good QoR, timing
analysis accuracy, and reliable hardware stability are met. For methodology check violations that can be
safely ignored, you can use the waiver mechanism to waive the violations. For details, see this link in the
Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906).

Note: Methodology checks related to RAMB and DSP primitive optional pipelining (SYNTH-6, SYNTH-11,
SYNTH-12 and SYNTH-13) are not reported when setup timing is greater than 1 ns on all of the input or
output paths for the primitives.

Figure 109: Methodology Window

For more information on running Report Methodology, see the Vivado Design Suite User Guide:
System-Level Design Entry (UG895). Also, see this link in the Vivado Design Suite User Guide: Design
Analysis and Closure Techniques (UG906).

Related Information

Fixing Issues Flagged by report_methodology

Reviewing the Synthesis Log

You must review the synthesis log files and confirm that all messages given by the tool match
your expectations in terms of the design intent. Pay special attention to Critical Warnings and
Warnings. In most cases, Critical Warnings need to be fixed for a reliable synthesis result.

CAUTION! If a message appears more than 100 times, the tool writes only the first 100 occurrences to
the synthesis log file. You can change the limit of 100 through the Tcl command set_param
messaging.defaultLimit.

Reviewing Timing Constraints

You must provide clean timing constraints, along with timing exceptions, where applicable. Bad
constraints result in long compile time, performance issues, and hardware failures.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 195
 Chapter 5: Design Implementation

RECOMMENDED: Review all Critical Warnings and Warnings related to timing constraints which indicate
that constraints have not been loaded or properly applied.

Related Information

Organizing the Design Constraints for Compilation

Assessing Post-Synthesis Quality of Results

Report QoR Assessment combines logic level checks, utilization checks, and the most common
clocking topology checks into one summary report that gives you an overall assessment of the
design. This report helps you understand the severity of the timing closure issues. Xilinx
recommends that you run this report on the synthesized design after any significant netlist
update on a design with correct timing constraints.

Report QoR Assessment provides a score between 1 and 5 that indicates how likely the design is
to close timing. The following table shows the definition of each score. Scores of 1 and 2 have no
chance of meeting timing closure and a score of 3 is unlikely to close. Therefore, low scores mean
more work in closing timing.

Table 4: Report QoR Assessment Scoring

Score Meaning
1 Design will likely not complete implementation.
2 Design will complete implementation but will not meet timing.
3 Design will likely not meet timing.
4 Design will likely meet timing.
5 Design will meet timing.

In the report, the detailed table provides information on the basis for the score. The thresholds in
the detailed table are not absolute limits for the device. Instead, the thresholds indicate when
timing closure might become increasingly difficult to achieve. After you exceed the threshold of
any of these items, the difficulty in closing timing increases exponentially.

Plan to correct any items that are marked for review in the Report QoR assessment. Many of the
items might be resolved automatically using Report QoR Suggestions.

Following Guidelines to Address Remaining Violations

IMPORTANT! Analyze timing post-synthesis to identify the major design issues that must be resolved
before you move forward in the flow.

HDL changes tend to have the biggest impact on QoR. You are therefore better off solving
problems before implementation to achieve faster timing convergence. When analyzing timing
paths, pay special attention to the following:

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 196
 Chapter 5: Design Implementation

• Most frequent offenders (that is, the cells or nets that show up the most in the top worst
failing timing paths)
• Paths sourced by unregistered block RAMs
• Paths sourced by SRL
• Paths containing unregistered, cascaded DSP blocks
• Paths with large number of logic levels
• Paths with large fanout

Related Information

Timing Closure

Dealing with High Levels of Logic

Identifying long logic paths is useful to diagnose difficult QoR challenges. Estimated net delays
post-synthesis are close to the best possible placement. To evaluate if a path with high logic-level
delay is meeting timing, you can generate timing reports with no net delay. Timing closure cannot
be achieved on paths that are still violating timing with no net delays.

Related Information

Timing Closure

Reviewing Utilization
It is important to review utilization for LUT, FF, block RAM, and DSP components independently.
A design with low LUT/FF utilization might still experience placement difficulties if block RAM
utilization is high. The report_utilization command generates a comprehensive utilization
report with separate sections for all design objects.

Note: After synthesis, utilization numbers might change due to optimization later in the design flow.

Reviewing Clock Trees

This section discusses reviewing clock trees, including clock buffer utilization and clock tree
topology.

Clock Buffer Utilization

The report_clock_utilization command provides details on clock primitive utilization.
Observe the architecture clocking rules to avoid downstream placement issues. Invalid placement
constraints or very high fanout for regional clock buffers might cause issues in the placer. For
designs with very high clock buffer utilization, it might be necessary to lock the clock generators
and some regional clock buffers to aid placement.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 197
 Chapter 5: Design Implementation

For some interfaces needing very tight timing relationship, it is sometimes better to lock specific
resources for these signals which need very tight timing relationship, for example, source
synchronous interfaces. In general, as a starting point for your design, lock only the I/Os unless
there are specific reasons not to follow this approach as cited above.

Related Information

Timing Closure

Clock Tree Topology

When working with clock trees, follow these recommendations:

• Run the report_clock_networks command to show the clock network in detail tree view.
• Utilize clock trees in a way to minimize skew.
• For the outputs of PLLs and MMCMs, use the same clock buffer type to minimize skew.
• Look for unintended cascaded BUFG elements that can introduce additional delay, skew, or
both.

Implementing the Design

Vivado Design Suite implementation includes all steps necessary to place and route the netlist
onto the device resources, while meeting the design's logical, physical, and timing constraints. For
additional information about implementation, refer to the following resources:

• Vivado Design Suite User Guide: Implementation (UG904)

• Vivado Design Suite QuickTake Video: Design Flows Overview

Using Project Mode vs. Non-Project Mode

You can run implementation in Project Mode or Non-Project Mode. Project Mode provides the
project infrastructure such as runs management, file sets management, reports generation, and
cross probing. Non-Project Mode provides easy integration and is driven by a Tcl script which
must explicitly call all the desired reports along the flow. For additional information about these
modes, see this link in the Vivado Design Suite User Guide: Design Flows Overview (UG892).

Strategies
Strategies are used by the Vivado Design Suite to control both the tool options and the reports
that are generated by synthesis and implementation runs in Project Mode. You can use the
strategies to adjust the implementation goals and to control the reports that are generated. For
more information on strategies, see the Vivado Design Suite User Guide: Implementation (UG904).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 198
 Chapter 5: Design Implementation

RECOMMENDED: Try the default strategy Vivado Implementation Defaults first. It provides a good
trade-off between compile time and design performance.

Note: Strategies are tool and version specific. In some cases, strategies might require a longer compile time.

Directives
Directives provide different modes of behavior for the following implementation commands:

• opt_design
• place_design
• phys_opt_design
• route_design

Use the default directive initially. Use other directives when the design nears completion to
explore the solution space for a design. You can specify only one directive at a time. For more
information on directives, see the Vivado Design Suite User Guide: Implementation (UG904).

Iterative Flows
In Non-Project Mode, you can iterate between various optimization commands with different
options. For example, you can run phys_opt_design -directive
AggressiveFanoutOpt followed by phys_opt_design -directive
AlternateFlowWithRetiming to run different physical synthesis optimizations on a placed
design that does not meet timing.

Running phys_opt_design iteratively can provide timing improvement. The

phys_opt_design command attempts to optimize the top timing problem paths. By running
phys_opt_design iteratively, more critical paths can benefit from the optimization. Running
phys_opt_design at the post-route stage reroutes any nets that might have been unrouted.
Therefore, after running phys_opt_design at post-route, you do not need to explicitly run
route_design.

Analyzing a Design at Different Stages Using

Checkpoints
The Vivado Design Suite uses a physical design database to store placement and routing
information. Design checkpoint files (.dcp) allow you to save (write_checkpoint command)
and restore (read_checkpoint command) this physical database at key points in the design
flow. Checkpoints are a snapshot of the design at a specific point in the flow. In Project Mode,
the Vivado tools automatically generate design checkpoint files and store them in the
implementation runs directory. These can be opened in a separate instance of the Vivado tools.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 199
 Chapter 5: Design Implementation

This design checkpoint file includes the following:

• Current netlist, including any optimizations made during implementation

• Design constraints
• Implementation results

Checkpoint designs can be run through the remainder of the design flow using Tcl commands.
They cannot be modified with new design sources.

A few common examples for the use of checkpoints are:

• Saving results so you can go back and do further analysis on that part of the flow.
• Trying place_design using multiple directives and saving the checkpoints for each. This
would allow you to select the place_design checkpoint with the best timing results for the
subsequent implementation steps.

For more information on checkpoints, see the Vivado Design Suite User Guide: Implementation
(UG904).

Using Interactive Report Files

After opening a checkpoint, you can read in and immediately analyze generated reports in the
Vivado IDE. To generate the reports, use the following reporting commands and append the -
rpx <filename.rpx> option:

report_timing_summary
report_timing
report_power
report_methodology
report_drc

After the checkpoint is open, you can open the interactive report file using Reports → Open
Interactive Report.

Note: In Project Mode, the interactive reports are generated and opened automatically.

RECOMMENDED: When a report is generated, there is a size limit on the RPX file. Therefore, Xilinx
recommends using the catch command to prevent errors that might stop the flow. For example: catch
{report_timing_summary -rpx timing_summary.rpx -file timing_summary.rpt} .

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 200
 Chapter 5: Design Implementation

Using Incremental Implementation Flows

In the Vivado Design Suite, you can use incremental implementation to reuse existing placement
and routing data, which reduces implementation compile time and produces more predictable
results. When working with designs that have 95% or higher reuse, incremental place and route
typically achieves at least a twofold improvement over normal place and route compile times
while maintaining the WNS of the reference run. For more information, see this link in the Vivado
Design Suite User Guide: Implementation (UG904).

RECOMMENDED: Incremental implementation is most useful during critical stages of the design cycle
when changes to the flow scripts are difficult to make. Ensure that your flow scripts include incremental
implementation early in the design cycle so you can enable incremental implementation during critical
periods.

Note: For further improvement in compile times and QoR, you can also use incremental synthesis.

Related Information

Incremental Synthesis

Incremental Implementation Flow Modes

Automatic Incremental Implementation Mode
You can use automatic incremental implementation mode to activate the incremental
implementation flow but allow the Vivado tools to defer running incremental implementation
until more is known about the reference checkpoint and the current design. When the
read_checkpoint command is issued, the Vivado tools determine whether to run the
implementation flow with the default flow algorithms or with the incremental flow algorithms.
Automatic mode provides push-button ease of use, because the tools manage the reference
design data for incremental implementation.

Note: The automatic incremental implementation mode is less aggressive than running the default
incremental implementation flow and enables better maintenance of QoR when running the incremental
implementation flow.

Project Mode

In Project Mode, the Vivado tools manage updating of the checkpoint as well as which algorithms
to use. To enable the automatic incremental implementation mode in Project Mode, right-click an
implementation run in the Design Runs window, select Set incremental Compile → Automatically
use the checkpoint from the previous run.

The equivalent Tcl command is:

set_property AUTO_INCREMENTAL_CHECKPOINT 1 [get_runs <runName>]

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 201
 Chapter 5: Design Implementation

Non-Project Mode

In Non-Project Mode, the Vivado tools manage which algorithms to use, but you must decide
whether to update the checkpoint. To enable the automatic incremental implementation mode in
Non-Project Mode, use the -auto_incremental option. Following is an example command:

read_checkpoint -incremental -auto_incremental <reference>.dcp

When updating the checkpoint, ensure that WNS did not degrade beyond acceptable limits by
using the following command at the end of the implementation flow:

if {[get_property SLACK [get_timing_path -setup]] > -0.250} {

file copy -force <postroute>.dcp <reference>.dcp
}

High and Low Reuse Modes

If you use the incremental implementation flow without enabling automatic incremental
implementation mode, the reuse level triggers one of the following reuse modes:

• High Reuse Mode: High reuse mode is enabled when cell reuse is equal to or greater than
75%. This mode triggers incremental algorithms to be run and is the standard mode for
incremental implementation.

• Low Reuse Mode: Low reuse mode is enabled when cell reuse is less than 75%. This mode
reuses the cell placement of certain cells but runs the default algorithms. This mode can be
effective when targeting block placement of DSPs, BRAMs, or a hierarchical cell.

Incremental Directives and Target WNS

You can use incremental directives to specify the target WNS for the implementation flow. The
target WNS determines whether the implementation tools try to close timing or only try to
achieve the same level of timing closure as the reference checkpoint. When the implementation
flow uses the default algorithms, the incremental directive is ignored and the place_design
and route_design directives are used.

The following table shows each incremental directive and the corresponding target WNS
behavior.

Table 5: Incremental Directive and Target WNS Behavior

Incremental Directive Target WNS Behavior

RuntimeOptimized Same as the reference checkpoint
TimingClosure 0.000
Quick Flow is not timing driven, and placement is driven by related
logic

Note: Incremental directives replace directive mapping from previous releases.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 202
 Chapter 5: Design Implementation

Parallel Runs
To improve your chances of meeting timing using the default flow, it is common to implement
many parallel runs, each with different placer directives. For incremental flows, the directive
indicates whether to close or maintain timing. To achieve a spread of results, target the desired
incremental directive with different reference checkpoints.

Compile Time Considerations

When using the RuntimeOptimized directive with automatic incremental implementation mode
or high reuse mode, compile times can be reduced by half if 95% or more of the design is reused.
As reuse declines, the benefit to compile time also declines. This is typically predictable unless
changes impact critical paths.

When using the TimingClosure directive with automatic incremental implementation mode or
high reuse mode, time is spent on running extra algorithms to close timing. Compile time can
increase using this mode, especially when it is difficult to close timing or there are timing failures
in a congested areas. When the reference checkpoint meets timing, compile time reduction is
similar to using the RuntimeOptimized directive as described previously.

In low reuse mode, compile time is not predictable. When the place and route runs get closer to
meeting timing, the Vivado tools might increase compile time to meet timing. In other cases, the
Vivado tools might decrease compile time if existing placement and routing data is reused
efficiently.

Opening the Synthesized Design

The first steps after synthesis are to read the netlist from the synthesized design into memory
and apply design constraints. You can open the synthesized design in various ways, depending on
the flow used. For more information, see this link in the Vivado Design Suite User Guide:
Implementation (UG904).

Logic Optimization (opt_design)

Vivado Design Suite logic optimization optimizes the current in-memory netlist. Because this is
the first view of the assembled design (RTL and IP blocks), the design can usually be further
optimized. By default the opt_design command performs logic trimming, removing of cells
with no loads, propagating constant inputs, and block RAM power optimization. It also optionally
performs other optimizations such as remap, which combines LUTs in series into fewer LUTs to
reduce path depth.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 203
 Chapter 5: Design Implementation

Optimization Analysis
The opt_design command generates messages detailing the results for each optimization
phase. After optimization you can run report_utilization to analyze utilization
improvements. To better analyze optimization results, rerun opt_design with the -verbose
and -debug_log options for complete details on how each optimization affects the logic and
how user constraints prevent some optimizations. For more information, see this link and this link
in the Vivado Design Suite User Guide: Implementation (UG904).

Placement (place_design)
The Vivado Design Suite placer engine positions cells from the netlist onto specific sites in the
target Xilinx device.

Placement Analysis
Use the timing summary report after placement to check the critical paths.

• Paths with very large negative setup time slack may require that you check the constraints for
completeness and correctness, or logic restructuring to achieve timing closure.
• Paths with very large negative hold time slack are most likely due to incorrect constraints or
bad clocking topologies and should be fixed before moving on to route design.
• Paths with small negative hold time slack are likely to be fixed by the router. You can also run
report_clock_utilization after place_design to view a report that breaks down
clock resource and load counts by clock region.

For more information on placement, see this link in the Vivado Design Suite User Guide:
Implementation (UG904).

Related Information

Timing Closure

Physical Optimization (phys_opt_design)

Physical optimization is an optional step of the flow. It performs timing-driven optimization on
the negative-slack paths of a design. Optimizations involve replication, retiming, hold fixing, and
placement improvement. Because physical optimization automatically performs all necessary
netlist and placement changes, place_design is not required after phys_opt_design.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 204
 Chapter 5: Design Implementation

Need for Physical Synthesis

To determine if a design would benefit from physical synthesis, evaluate timing after placement.
Analyze failing paths for fanout. High fanout critical paths can benefit from fanout optimization.
Additionally, high-fanout data, address and control nets of large RAM blocks involving multiple
block RAMs that fail timing after route_design might benefit from Forced Net Replication. For
more information on physical synthesis, see this link in the Vivado Design Suite User Guide:
Implementation (UG904).

Routing (route_design)
The Vivado Design Suite router performs routing on the placed design and performs optimization
on the routed design to resolve hold time violations. By default, the router performs optimization
using a balance between runtime and design performance while alleviating congestion. Some
router directives sacrifice runtime for better design performance and more aggressive congestion
reduction. For more information on routing, see this link in the Vivado Design Suite User Guide:
Implementation (UG904).

Route Analysis
Nets that are routed sub-optimally are often the result of incorrect timing constraints. Before you
experiment with router settings, make sure that you have validated the constraints and the
timing picture seen by the router. Validate timing and constraints by reviewing timing reports
from the placed design before routing.

Common examples of poor timing constraints include cross-clock paths and incorrect multicycle
paths causing route delay insertion for hold fixing. Congested areas can be addressed by targeted
fanout optimization in RTL synthesis or through physical optimization. You can preserve all or
some of the design hierarchy to prevent cross-boundary optimization and reduce the netlist
density. Or you can use floorplan constraints to ease congestion.

Related Information

Timing Closure

Route Compile Time

You can use the route_design -ultrathreads option to reduce compile time at the
expense of repeatability. This option gives the router extra freedom to execute multiple threads,
which allows routing to finish faster but with slightly different results each time. The slack
between identical subsequent runs differs by a fractional percentage, but the compile time
savings are significant. Consider this option to reduce router compile time only if your
environment does not require strictly repeatable results.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 205
 Chapter 6: Design Closure

Chapter 6

Design Closure
Design closure consists of meeting all system performance, timing, and power requirements, and
successfully validating the functionality in hardware. During the design closure phase where you
are starting to run the design through the implementation tools, both timing and power
considerations should be your top priorities.

At this stage of design closure, estimation of design utilization, timing and power gain more
accuracy. This presents an opportunity to reaffirm that the timing and power goals are
achievable. To confirm the design can meet its requirements, Xilinx recommends conducting both
a timing and power baseline. A timing baseline is largely about evaluating timing paths after
accurate timing constraints have been defined. A power baseline needs to provide Vivado with
the right toggle information to determine accurate dynamic power information.

By combining the analysis of power requirements and timing requirements, if one item is off
significantly, a measure taken to resolve it can significantly impact the other. For example:

• An extreme measure might be necessary to meet a power budget such as scaling back
features. This will make timing closure significantly easier as the part is less congested.
• A less extreme measure might involve adding logic to reduce switching. This might make
timing closure more difficult, particularly if in a congested area of the die.

While many power saving items do not impact timing closure, it is possible that other items might
make timing closure harder. Applying the required power saving techniques early will help you
understand the true magnitude of the timing closure task.

Once you start to iterate from the baseline, you should recheck the power numbers when you
make an improvement to timing. This ensures that you understand what change caused a
regression. Generally, turning on wholesale power saving features early and then scaling back on
individual items that are causing timing issues helps to strike the right balance of meeting design
closure goals.

Conducting both power and timing analysis together and early in the design closure
implementation phase will save engineering time and enable more accurate project planning. In
addition, it creates time to allow engineering solutions to be explored than when this is realized
later in the design cycle.

TIP: For more information on reports mentioned in this chapter, see Vivado Design Suite User Guide:
Design Analysis and Closure Techniques (UG906).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 206
 Chapter 6: Design Closure

TIP: See the UltraFast Design Methodology Timing Closure Quick Reference Guide (UG1292) for a
condensed version of the techniques described in this chapter, including running initial design checks,
baselining the design, and resolving timing violations.

Timing Closure
Timing closure consists of the design meeting all timing requirements. It is easier to reach timing
closure if you have the right HDL and constraints for synthesis. In addition, it is important to
iterate through the synthesis stages with improved HDL, constraints, and synthesis options, as
shown in the following figure.

Figure 110: Design Methodology for Rapid Convergence

Run Synthesis
Review options & HDL
code

report_clock_networks
-> create_clock / Cross-probe
create_generated_clock Define & Refine Instances in critical path
report_clock_interaction Constraints In Netlist view and
-> set_clock_groups / set_false_path Elaborated view
check_timing schematics
-> I/O delays
report_timing_summary
-> Timing exceptions

Timing Acceptable?
N

Place & Route

X13422-121919

To successfully close timing, follow these general guidelines:

• When initially not meeting timing, evaluate timing throughout the flow.
• Focus on worst negative slack (WNS) of each clock as the main way to improve total negative
slack (TNS).
• Review large worst hold slack (WHS) violations (<-1 ns) to identify missing or inappropriate
constraints.
• Revisit the trade-offs between design choices, constraints, and target architecture.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 207
 Chapter 6: Design Closure

• Know how to use the tool options and Xilinx® design constraints (XDC).
• Be aware that the tools do not try to further improve timing (additional margin) after timing is
met.

The following sections provide recommendations for reviewing the completeness and
correctness of the timing constraints using methodology design rule checks (DRCs) and
baselining, identifying the timing violation root causes, and addressing the violations using
common techniques.

Note: Timing results after synthesis use estimated net delays and not the actual routing delays. To get the
final timing results, run implementation and then check the Report Timing Summary.

Understanding Timing Closure Criteria

Timing closure starts with writing valid constraints that represent how the design will operate in
hardware. Review the Timing Summary report as described in the following sections.

Checking for Valid Constraints

POWER TIP: When you have a design run with clean timing, consider using the Create Runs command in
the Vivado® IDE to run multiple strategies. Run the report_power command on each design with
accurate switching activity XDC constraints to find the best run from both a timing and power perspective.

Review the Check Timing section of the Timing Summary report to quickly assess the timing
constraints coverage, including the following:

• All active clock pins are reached by a clock definition.

• All active path endpoints have requirement with respect to a defined clock (setup/hold/
recovery/removal).
• All active input ports have an input delay constraint.
• All active output ports have an output delay constraint.
• Timing exceptions are correctly specified.

CAUTION! Excessive use of wildcards in constraints can cause the actual constraints to be different
from what you intended. Use the report_exceptions command to identify timing exception
conflicts and to review the netlist objects, timing clocks, and timing paths covered by each exception.

In addition to check_timing, the Methodology report (TIMING and XDC checks) flags timing
constraints that can lead to inaccurate timing analysis and possible hardware malfunction. You
must carefully review and address all reported issues.

Note: When baselining the design, you must use all Xilinx IP constraints. Do not specify user I/O
constraints, and ignore the violations generated by check_timing and report_methodology due to
missing user I/O constraints.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 208
 Chapter 6: Design Closure

Related Information

Baselining the Design

Checking for Positive Timing Slacks

The following timing metrics reflect the design timing score. Numbers must be positive to meet
timing.

• Setup/Recovery (max delay analysis): WNS > 0 ns and TNS = 0 ns

• Hold/Removal (min delay analysis): WHS > 0 ns and THS = 0 ns
• Pulse Width: WPWS > 0 ns and TPWS = 0 ns

Understanding Timing Reports

The Timing Summary report provides high-level information on the timing characteristics of the
design compared to the constraints provided. Review the timing summary numbers during
signoff:

• Total Negative Slack (TNS): The sum of the setup/recovery violations for each endpoint in the
entire design or for a particular clock domain. The worst setup/recovery slack is the worst
negative slack (WNS).

• Total Hold Slack (THS): The sum of the hold/removal violations for each endpoint in the entire
design or for a particular clock domain. The worst hold/removal slack is the worst hold slack
(WHS).

• Total Pulse Width Slack (TPWS): The sum of the violations for each clock pin in the entire
design or a particular clock domain for the following checks:

• Minimum low pulse width

• Minimum high pulse width
• Minimum period
• Maximum period
• Maximum skew (between two clock pins of a same leaf cell)

• Worst Pulse Width Slack (WPWS): The worst slack for all pulse width, period, or skew checks
on any given clock pin.

The Total Slack (TNS, THS or TPWS) only reflects the violations in the design. When all timing
checks are met, the Total Slack is null.

The timing path report provides detailed information on how the slack is computed on any logical
path for any timing check. In a fully constrained design, each path has one or several
requirements that must all be met in order for the associated logic to function reliably.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 209
 Chapter 6: Design Closure

The main checks covered by WNS, TNS, WHS, and THS are derived from the sequential cell
functional requirements:

• Setup time: The time before which the new stable data must be available before the next
active clock edge to be safely captured.

• Hold requirement: The amount of time the data must remain stable after an active clock edge
to avoid capturing an undesired value.

• Recovery time: The minimum time required between the time the asynchronous reset signal
has toggled to its inactive state and the next active clock edge.

• Removal time: The minimum time after an active clock edge before the asynchronous reset
signal can be safely toggled to its inactive state.

A simple example is a path between two flip-flops that are connected to the same clock net.

After a timing clock is defined on the clock net, the timing analysis performs both setup and hold
checks at the data pin of the destination flip-flop under the most pessimistic, but reasonable,
operating conditions. The data transfer from the source flip-flop to the destination flip-flop
occurs safely when both setup and hold slacks are positive.

For more information on timing analysis, see this link in the Vivado Design Suite User Guide: Design
Analysis and Closure Techniques (UG906).

Checking That Your Design is Properly Constrained

Before looking at the timing results to see if there are any violations, be sure that every
synchronous endpoint in your design is properly constrained.

Run check_timing to identify unconstrained paths. You can run this command as a standalone
command, but it is also part of report_timing_summary. In addition,
report_timing_summary includes an Unconstrained Paths section where N logical paths
without timing requirements are listed by the already defined source or destination timing clock.
N is controlled by the -max_path option.

After the design is fully constrained, run the report_methodology command and review the
TIMING and XDC checks to identify non-optimal constraints, which will likely make timing
analysis not fully accurate and lead to timing margin variations in hardware. To identify and
correct unrealistic target clock frequencies or setup path requirement, use the
report_qor_assessment command.

IMPORTANT! To address missing or incomplete constraints, use the Timing Constraints wizard or see the
Vivado Design Suite User Guide: Using Constraints (UG903).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 210
 Chapter 6: Design Closure

Fixing Issues Flagged by check_timing

The check_timing Tcl command reports that something is missing or wrong in the timing
definition. When reviewing and fixing the issues flagged by check_timing, focus on the most
important checks first. Following are the checks listed from most important to least important.

No Clock and Unconstrained Internal Endpoints

This allows you to determine whether the internal paths in the design are completely
constrained. You must ensure that the unconstrained internal endpoints are at zero as part of the
Static Timing Analysis signoff quality review.

Zero unconstrained internal endpoints indicate that all internal paths are constrained for timing
analysis. However, the correct value of the constraints is not yet guaranteed.

Generated Clocks
Generated clocks are a normal part of a design. However, if a generated clock is derived from a
master clock that is not part of the same clock tree, this can cause a serious problem. The timing
engine cannot properly calculate the generated clock tree delay. This results in erroneous slack
computation. In the worst case situation, the design meets timing according to the reports but
does not work in hardware.

Loops and Latch Loops

A good design does not have any combinational loops, because timing loops are broken by the
timing engine. The broken paths are not reported during timing analysis or evaluated during
implementation. This can lead to incorrect behavior in hardware, even if the overall timing
requirements are met.

No Input/Output Delays and Partial Input/Output Delays

All I/O ports must be properly constrained.

RECOMMENDED: Start by validating baselining constraints and then complete the constraints with the
I/O timing.

Multiple Clocks
Multiple clocks are usually acceptable. Xilinx recommends that you ensure that these clocks are
expected to propagate on the same clock tree. You must also verify that the paths requirement
between these clocks does not introduce tighter requirements than needed for the design to be
functional in hardware.

If this is the case, you must use set_clock_groups or set_false_path between these
clocks on these paths. Any time that you use timing exceptions, you must ensure that they affect
only the intended paths.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 211
 Chapter 6: Design Closure

Fixing Issues Flagged by report_methodology

The report_methodology command reports additional constraints and timing analysis issues,
which you must carefully review before and after running the place and route tools. This section
describes the main XDC and TIMING categories of checks, along with their relative impact on
timing closure and hardware stability. You must focus on resolving the checks that impact timing
closure first.

For more information on some of these checks, see this link in the Vivado Design Suite User Guide:
Design Analysis and Closure Techniques (UG906). Also, see the Adoption Of The Methodology
Report blog series for more information on how report_methodology helps to resolve issues
and save time.

IMPORTANT! To increase visibility, the summary of the methodology violations is also included in the
timing summary text report, because addressing these issues is critical for having proper signoff timing.

Methodology DRCs with Impact on Timing Closure

The DRCs shown in the following table flag design and timing constraint combinations that
increase the stress on implementation tools, leading to impossible or inconsistent timing closure.
These DRCs usually point to missing clock domain crossing (CDC) constraints, inappropriate clock
trees, or inconsistent timing exception coverage due to logic replication. They must be addressed
with highest priority.

IMPORTANT! Carefully verify timing checks with a severity of Critical Warning.

For more information on timing methodology checks, see this link in the Vivado Design Suite User
Guide: Design Analysis and Closure Techniques (UG906).

Table 6: Timing Closure Methodology DRCs

Check Severity Description

TIMING-6 Critical Warning No common clock between related clocks
TIMING-7 Critical Warning No common node between related clocks
TIMING-8 Critical Warning No common period between related clocks
TIMING-14 Critical Warning LUT on the clock tree
TIMING-15 Warning Large hold violation on inter-clock path
TIMING-16 Warning Large setup violation
TIMING-30 Warning Sub-optimal master source pin selection for generated clock
TIMING-31 Critical Warning Inappropriate multicycle path between phase shifted clocks
TIMING-32, TIMING-33, Warning Non-recommended bus skew constraint
TIMING-34, TIMING-37,
TIMING-38, TIMING-39
TIMING-36 Critical Warning Missing master clock edge propagation for generated clock
TIMING-42 Warning Clock propagation prevented by path segmentation

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 212
 Chapter 6: Design Closure

Table 6: Timing Closure Methodology DRCs (cont'd)

Check Severity Description

TIMING-44 Warning Unreasonable user intra and inter-clock uncertainty
TIMING-45
TIMING-48 Advisory Max Delay Datapath Only constraint on latch input
TIMING-49 Critical Warning Unsafe enable or reset topology from parallel BUFGCE_DIV
TIMING-50 Warning Unrealistic path requirement between same-level latches
TIMING-56 Warning Missing logically or physically excluded clock groups constraint
XDCB-3 Warning Same clock mentioned in multiple groups in the same
set_clock_groups command

XDCH-1 Warning Hold option missing in multicycle path constraint

XDCV-1 Warning Incomplete constraint coverage due to missing original object
used in replication
XDCV-2 Warning Incomplete constraint coverage due to missing replicated objects

Methodology DRCs with Impact on Signoff Quality and Hardware Stability

The DRCs shown in the following table do not usually flag issues that impact the ease of closing
timing. Instead, these DRCs flag problems with timing analysis accuracy due to non-
recommended constraints. Even when setup and hold slacks are positive, the hardware might not
function properly under all operating conditions. Most checks refer to clocks not defined on the
boundary of the design, clocks with unexpected waveform, missing timing requirements, or
inappropriate CDC circuitry. For this last category, use the report_cdc command to perform a
more comprehensive analysis.

IMPORTANT! Carefully verify timing checks with a severity of Critical Warning.

Table 7: Signoff Quality Methodology DRCs

Check Severity Description

TIMING-1, TIMING-2, Critical Warning Non-recommended clock source point definition
TIMING-3, TIMING-4,
TIMING-27
TIMING-5, TIMING-25, Critical Warning Unexpected clock waveform
TIMING-19
TIMING-9, TIMING-10 Warning Unknown or incomplete CDC circuitry
TIMING-11 Warning Inappropriate set_max_delay -datapath_only command

TIMING-12 Warning Clock Reconvergence Pessimism Removal disabled

TIMING-13, TIMING-23 Warning Incomplete timing analysis due to broken paths
TIMING-17 Critical Warning Non-clocked sequential cell
TIMING-18, TIMING-20, Warning Missing clock or input/output delay constraints
TIMING-26
TIMING-21, TIMING-22 Warning Issues with MMCM compensation
TIMING-24 Warning Overridden set_max_delay -datapath_only command

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 213
 Chapter 6: Design Closure

Table 7: Signoff Quality Methodology DRCs (cont'd)

Check Severity Description

TIMING-29 Warning Inconsistent pair of multicycle paths
TIMING-35 Critical Warning No common node in paths with the same clock
TIMING-40, TIMING-43 Warning Inappropriate clock topologies or requirements
TIMING-41 Warning Invalid forwarded clock defined on an internal pin
TIMING-46 Warning Multicycle path with tied CE pins
TIMING-47 Warning False path or asynchronous clock group between synchronous clocks
TIMING-51 Critical Warning No common phase between related clocks from parallel MMCMs or PLLs
TIMING-52 Critical Warning No common phase between related clocks from Spread Spectrum MMCM
TIMING-54 Critical Warning Scoped false path, clock group or max delay datapath only constraint
between clocks
TIMING-55 Critical Warning Multiple clocks reaching a CMB deskew pin
TIMING-56 Warning Missing logically or physically excluded clock groups constraint
TIMING-57 Warning Unsupported configuration with PHASESHIFT_MODE and digital deskew

Other Timing Methodology DRCs

Other TIMING and XDC checks identify constraints that can incur higher run time, override
existing constraints, or are highly sensitive to netlist names change. The corresponding
information is useful for debugging constraints conflicts. You must pay particular attention to the
TIMING-28 check (Auto-derived clock referenced by a timing constraint), because the auto-
derived clock names can change when modifying the design source code and resynthesizing. In
this case, previously defined constraints will not work anymore or will apply to the wrong timing
paths.

Assessing the Maximum Frequency of the Design

You can define and assess the maximum frequency (FMAX) with a design that runs on a given
architecture and speed grade by iteratively increasing the target clock frequency and re-running
both synthesis and implementation until small setup slack violations (WNS < 0) are reported by
timing analysis on the fully routed design. Xilinx recommends using the Default or
PerformanceOptimized synthesis directives along with the Explore implementation directives and
strategy to get the best achievable FMAX. In some cases, alternate strategies can show higher
FMAX depending on the size of the design and the nature of the critical logic paths. For the
implementation results with small setup violations, the maximum frequency is computed as
follows:

• FMAX (MHz) = max(1000/(Ti - WNSi))

Where:

• Ti is the target clock period (ns) used during the implementation run "i"

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 214
 Chapter 6: Design Closure

• WNSi is the worst negative slack (ns) of the target clock used during the implementation run
"i"

Additional important considerations:

• Using overly tight clock periods can lead to automatic effort reduction in the Vivado
Implementation tools to avoid high compilation time due to unrealistic target and large timing
violations. Use reasonably tight clock constraints instead.
• For designs with multiple clocks, you must proportionally decrease all synchronous clock
periods until one of them starts failing timing after implementation (preferably the fastest
clock or the clock with the most timing paths).

Note: The FMAX value is not explicitly provided in the report_timing or report_timing_summary
report.

For a given design implementation, the maximum operating frequency on hardware across
temperature and voltage ranges supported by the target device speed grade is defined by
1000/(T - WNS), with WNS positive or negative. When operating under nominal temperature
and voltage conditions, typically in a lab environment, it is usually possible to operate the design
at a slightly higher frequency.

Note: To increase the maximum frequency of the design, you can leverage the techniques described in this
chapter or use Intelligent Design Runs.

Related Information

Using Intelligent Design Runs

Baselining the Design

Baselining is a process in which you create the simplest timing constraints and initially ignore I/O
timing. After all clocks are completely constrained, all paths with start and endpoints within the
design are automatically constrained. This provides an easy mechanism to identify internal device
timing challenges, even while the design is evolving. Because the design might also have clock
domain crossings, baseline constraints must also include the relationship among the specified
clocks, including generated clocks.

When baselining the design, you must meet timing after each implementation step by analyzing
and resolving timing challenges throughout the flow. First, you create simple and valid
constraints to give a realistic picture of timing in the Vivado® implementation tools. Then, while
iterating through different implementation steps, you solve timing violations before moving onto
the next step. The following figure shows the baselining process.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 215
 Chapter 6: Design Closure

Figure 111: Baselining the Design

Post Synthesis Checkpoint

· Use the Timing Constraints

wizard
Define Baseline Constraints · Skip I/O timing constraints
· Validate with
report_methodology

· Resolve setup violations

opt_design + (WNS)
report_timing_summary · Validate with
report_methodology

· Resolve setup violations

place_design (WNS)
Optional phys_opt_design · Reduce large hold violations
report_timing_summary (WHS)
that are over -0.500 ns

route_design · Resolve all timing violations

Optional phys_opt_design · Verify methodology and DRC
report_timing_summary checks
are clean or properly waived

Baseline Process Complete

X20037-021821

After baselining is complete, you can:

• Eliminate smaller timing violations

• Achieve full constraint coverage
• Individually baseline new modules before adding the modules to the top-level design

RECOMMENDED: Xilinx recommends that you create the baseline constraints very early in the design
process, and plan any major change to the design HDL against these baseline constraints.

Defining Baseline Constraints

To create the simplest set of constraints, use a valid post-synthesis Vivado checkpoint without
user timing constraints. With the checkpoint open, use the Timing Constraints wizard to define
the constraints. The wizard guides you through the process of creating constraints in a structured
manner.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 216
 Chapter 6: Design Closure

Not all constraints need to be defined at this stage. The Vivado tools ignore I/O timing by default
if there are no constraints. Therefore, you do not need to define I/O timing constraints at this
point. Instead, define the I/O timing constraints later in the flow after the baselining process is
complete.

TIP: When using the Timing Constraints wizard, deselect the suggested I/O timing constraints.

To get an accurate picture of internal timing in the device, define the following constraints:

• All clock constraints

• Clock domain crossings (CDC) constraints
CDC paths between synchronous clocks are safely timed by default, but you must use safe
CDC circuitry and specify timing exceptions between asynchronous clocks.

After creating the constraints, identify the paths that cannot meet timing. Rewrite the
corresponding RTL or relax the clock period.

IMPORTANT! All Xilinx IP and partner IP are delivered with specific XDC constraints that comply with the
Xilinx constraints methodology. The IP constraints are automatically included during synthesis and
implementation. You must keep the IP constraints intact when creating the baselining constraints.

If you do not use the Timing Constraints wizard to define the constraints, the following sections
cover the steps you must take to define the baseline constraints manually.

Identifying Which Clocks Must Be Created

Begin by loading the post synthesized netlist or checkpoint into the Vivado IDE. In the Tcl
Console, use the reset_timing command to ensure that all timing constraints are removed.

Use the report_clock_networks Tcl command to create a list of all the primary clocks that
must be defined in the design. The resulting list of clock networks shows which clock constraints
should be created. Use the Timing Constraints Editor to specify the appropriate parameters for
each clock.

Verifying That No Clocks Are Missing

After the clock network report shows that all clock networks are constrained, you can begin
verifying the accuracy of the generated clocks. Because the Vivado tools automatically propagate
clock constraints through clock-modifying blocks, it is important to review the constraints that
were generated. Use report_clocks to show which clocks were created with a
create_clock constraint and which clocks were generated.

Note: MMCMs, PLLs, and clock buffers are clock-modifying blocks. For UltraScale™ devices, GTs are also
clock-modifying blocks.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 217
 Chapter 6: Design Closure

The report_clocks results show that all clocks are propagated. The difference between the
primary clocks (created with create_clock) and the generated clocks is displayed in the
attributes field:

• Clocks that are propagated (P) only are primary clocks.

• Clocks that are derived from other clocks are shown as both propagated (P) and generated (G).
• Clocks that are generated by a clock-modifying block are shown as auto-derived (A).
• Other attributes indicate that an auto-derived clock was renamed (R), a generated clock has an
inverted waveform (I) relative to the incoming master clock, or a primary clock is virtual (V).

You can also create generated clocks using the create_generated_clock constraint. For
more information, see the Vivado Design Suite User Guide: Using Constraints (UG903).

Figure 112: Clock Report Shows the Clocks Generated from Primary Clocks

TIP: To verify that there are no unconstrained endpoints in the design, see the Check Timing report
(no_clock category). The report is available from within the Report Timing Summary or by using the
check_timing Tcl command.

Constraining Clock Domain Crossings

Upon verification of the clocking constraints, you must identify asynchronous and over-
constrained clock domain crossing paths.

Note: This section does not explain how to properly cross clock region boundaries. Instead, it explains how
to identify which crossings exist and how to constrain them.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 218
 Chapter 6: Design Closure

Reviewing Clock Relationships

You can view the relationship between clocks using the report_clock_interaction Tcl
command. The report shows a matrix of source clocks and destination clocks. The color in each
cell indicates the type of interaction between clocks, including any existing constraints between
them. The following figure shows a sample clock interaction report.

Figure 113: Sample Clock Interaction Report

The following table explains the meaning of each color in this report.

Table 8: report_clock_interaction Colors

Color Label Meaning What Next

Black No path No interaction among these clock domains. Primarily for information unless
you expected these clock domains
to be interacting.
Green Timed There is interaction among these clock domains, Primarily for information unless
and the paths are getting timed. you do not expect any interaction
among the clock domains.
Cyan Partial False Some of the paths for the interacting domains are Ensure that the timing exceptions
Path not being timed due to user exceptions. are really desired.
Red Timed (unsafe) There is interaction among these clock domains, Check whether these clocks are
and the paths are being timed. However, the supposed to be declared as
clocks appear to be independent (and hence, asynchronous, or whether they are
asynchronous). supposed to be sharing a common
primary source.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 219
 Chapter 6: Design Closure

Table 8: report_clock_interaction Colors (cont'd)

Color Label Meaning What Next

Orange Partial False There is interaction among these clock domains. Check why some paths are not
Path (unsafe) The clocks appear to be independent (and hence, covered by timing exceptions.
asynchronous). However, only some of the paths
are not timed due to exceptions.
Blue User Ignored There is interaction among these clock domains, Confirm that these clocks are
Paths and the paths are not being timed due to clock supposed to be asynchronous.
groups or false path timing exceptions. Also, check that the corresponding
HDL code is written correctly to
ensure proper synchronization and
reliable data transfer across clock
domains.
Light blue Max Delay There is interaction among these clock domains, Confirm that the clocks are
Datapath Only and the paths are getting timed through: asynchronous and that the
set_max_delay -datapath_only. specified delay is correct.

Before the creation of any false paths or clock group constraints, the only colors that appear in
the matrix are black, red, and green. Because all clocks are timed by default, the process of
decoupling asynchronous clocks takes on a high degree of significance. Failure to decouple
asynchronous clocks often results in a highly over-constrained design.

Identifying Clock Pairs without Common Primary Clocks

The clock interaction report indicates whether or not each pair of interacting clocks has a
common primary clock source. Clock pairs that do not share a common primary clock are
frequently asynchronous to each other. Therefore, it is helpful to identify these pairs by sorting
the columns in the report using the Common Primary Clock field. The report does not determine
whether clock-domain crossing paths are or are not designed properly.

Use the report_cdc Tcl command for a comprehensive analysis of clock domain crossing
circuitry between asynchronous clocks. For more information on the report_cdc command,
see this link in the Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906).
Also, see report_cdc in the Vivado Design Suite Tcl Command Reference Guide (UG835).

Identifying Tight Timing Requirements

For each clock pair, the clock interaction report also shows setup requirement of the worst path.
Sort the columns by Path Req (WNS) to view a list of the tightest requirements in the design.
Review these requirements to ensure that no invalid tight requirements exist.

The Vivado tools identify the path requirements by expanding each clock out to 1000 cycles,
then determining where the closest, non-coincident edge alignment occurs. When 1000 cycles
are not sufficient to determine the tightest requirement, the report shows Not Expanded, in
which case you must treat the two clocks as asynchronous.

For example, consider a timing path that crosses from a 250 MHz clock to a 200 MHz clock:

• The positive edges of the 200 MHz clock are {0, 5, 10, 15, 20}.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 220
 Chapter 6: Design Closure

• The positive edges of the 250 MHz clock are {0, 4, 8, 12, 16, 20}.

The tightest requirement for this pair of clocks occurs when the following is true:

• The 250 MHz clock has a rising edge at 4 ns.

• The next rising edge of the 200 MHz clock is at 5 ns.

This results in all paths timed from the 250 MHz clock domain into the 200 MHz clock domain
being timed at 1 ns.

Note: The simultaneous edge at 20 ns is not the tightest requirement in this example, because the capture
edge cannot be the same as the launch edge.

Because this is a fairly tight timing requirement, you must take additional steps. Depending on
the design, one of the following constraints might be the correct way to handle these crossings:

• set_clock_groups / set_false_path / set_max_delay -datapath_only

Use one of these constraints when treating the clock pair as asynchronous. Use the
report_cdc Tcl command to validate that the clock domain crossing circuitry is safe.
• set_multicycle_path
Use this constraint when relaxing the timing requirement, assuming proper clock circuitry
controls the launch and capture clock edges accordingly.

If nothing is done, the design might exhibit timing violations that cross these two domains. In
addition, all of the best optimization, placement and routing might be dedicated to these paths
instead of given to the real critical paths in the design. It is important to identify these types of
paths before any timing-driven implementation step.

Figure 114: Clock Domain Crossing from 250 MHz to 200 MHz

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 221
 Chapter 6: Design Closure

Constraining Both Primary and Generated Clocks at the Same Time

Before any timing exceptions are created, it is helpful to go back to report_clock_networks
to identify which primary clocks exist in the design. If all primary clocks are asynchronous to each
other, you can use a single constraint to decouple the primary clocks from each other and to
decouple their generated clocks from each other. Using the primary clocks in
report_clock_networks as a guide, you can decouple each clock group and associated
clocks as shown in the following figure.

Figure 115: Report Clock Networks

### Decouple asynchronous clocks

set_clock_groups -asynchronous \
-group [get_clocks sysClk -include_generated_clocks] \
-group [get_clocks gt0_txusrclk_i -include_generated_clocks] \
-group [get_clocks gt2_txusrclk_i -include_generated_clocks] \
-group [get_clocks gt4_txusrclk_i -include_generated_clocks] \
-group [get_clocks gt6_txusrclk_i -include_generated_clocks]

Limiting I/O Constraints and Timing Exceptions

Most timing violations are on internal paths. I/O constraints are not needed during the first
baselining iterations, especially for I/O timing paths in which the launching or capturing register
is located inside the I/O bank. You can add the I/O timing constraints after the design and other
constraints are stable and the timing is nearly closed.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 222
 Chapter 6: Design Closure

TIP: You can use the config_timing_analysis -ignore_io_paths yes Tcl command to
ignore timing on all I/O paths during implementation and in reports that use timing information. You must
manually enter this command before or immediately after opening a design in memory.

Based on recommendations of the RTL designer, timing exceptions must be limited and must not
be used to hide real timing problems. Prior to this point, the false path or clock groups between
clocks must be reviewed and finalized.

IP constraints must be entirely kept. When IP timing constraints are missing, known false paths
might be reported as timing violations.

Evaluating Design WNS After Each Step

You must evaluate the design WNS after each synthesis and implementation step. If you are
using the Tcl command line flow, you can easily incorporate report_timing_summary after
each implementation step in your build script. If you are using the Vivado IDE, you can use simple
tcl.post scripts to run report_timing_summary after each step. In both cases, when a
significant degradation in WNS is noted, you must analyze the checkpoint immediately preceding
that step.

In addition to evaluating the timing for the entire design after each implementation step, you can
take a more targeted approach for individual paths to evaluate the impact of each step in the
flow on the timing. For example, the estimated net delay for a timing path after the optimization
step might differ significantly from the estimated net delay for the same path after placement.
Comparing the timing of critical paths after each step is an effective method for highlighting
where the timing of a critical path diverges from closure.

Post-Synthesis and Post-Logic Optimization

Estimated net delays are close to the best possible placement for all paths. To fix violating paths
try the following:

• Change the RTL.

• Use different synthesis options.
• Add timing exceptions such as multicycle paths, if appropriate and safe for the functionality in
hardware.

Pre- and Post-Placement

After placement, the estimated net delays are close to the best possible route, except for long
and medium-to-high fanout nets, which use more pessimistic delays. In addition, congestion or
hold fixing impact are not accounted for in the net delays at this point, which can make the
timing results optimistic.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 223
 Chapter 6: Design Closure

Clock skew is accurately estimated and can be used to review imbalanced clock trees impact on
slack. You can estimate hold fixing by running min delay analysis. Large hold violations where the
WHS is -0.500 ns or greater between slices, block RAMs or DSPs will need to be fixed. Small
violations are acceptable and will likely be fixed by the router.

Note: Paths to/from dedicated blocks like the PCIe® block can have hold time estimates greater than
-0.500 ns that get automatically fixed by the router. For these cases, check report_timing_summary
after routing to verify that all corresponding hold violations are fixed.

Pre- and Post-Physical Optimization

Evaluate the need for running physical optimization to fix timing problems related to:

• Nets with high fanout (report_high_fanout_nets shows highest fanout non-clock nets)
• Nets with drivers and loads located far apart
• Digital signal processor (DSP) and block RAM with sub-optimal pipeline register usage

Pre- and Post-Route

Slack is reported with actual routed net delays except for the nets that are not completely
routed. Slack reflects the impact of hold fixing on setup and the impact of congestion.

No hold violation should remain after route, regardless of the worst setup slack (WNS) value. If
the design fails hold, further analysis is needed. This is typically due to very high congestion, in
which case the router gives up on optimizing timing. This can also occur for large hold violations
(over 4 ns) which the router does not fix by default. Large hold violations are usually due to
improper clock constraints, high clock skew or, improper I/O constraints which can already be
identified after placement or even after synthesis.

If hold is met (WHS > 0) but setup fails (WNS < 0), follow the analysis steps described in
Analyzing and Resolving Timing Violations.

Baselining and Timing Constraints Validation Procedure

The following procedure helps track your progress towards timing closure and identify potential
bottlenecks:

1. Open the synthesized design.

2. Run report_timing_summary -delay_type min_max, and record the information
shown in the following table.

Table 9: Timing Summary Report for Synthesized Design

Num Failing Num Failing

WNS TNS WHS THS
Endpoints Endpoints
Synth

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 224
 Chapter 6: Design Closure

3. Open the post-synthesis report_timing_summary text report and record the no_clock
section of check_timing.
Number of missing clock requirements in the design: ___________
4. Run report_clock_networks to identify primary clock source pins/ports in the design.
(Ignore QPLLOUTCLK and QPLLOUTREFCLK because they are pulse-width only checks.)
Number of unconstrained clocks in the design: ___________
5. Run report_clock_interaction -delay_type min_max and sort the results by
WNS path requirement.
Smallest WNS path requirement in the design: ___________
6. Sort the results of report_clock_interaction by WHS to see if there are large hold
violations (>500 ps) after synthesis.
Largest negative WHS in the design: ___________
7. Sort results of report_clock_interaction by Inter-Clock Constraints and list all the
clock pairs that show up as unsafe.
8. Upon opening the synthesized design, how many Critical Warnings exist?
Number of synthesized design Critical Warnings: ___________
9. What types of Critical Warnings exist?
Record examples of each type.
10. Run report_high_fanout_nets -timing -load_types -max_nets 25.
Number of high fanout nets not driven by FF: ___________
Number of loads on highest fanout net not driven by FF: ___________
Do any high fanout nets have negative slack? If yes, WNS = ___________
11. Implement the design. After each step, run report_timing_summary and record the
information shown in the following table.

Table 10: Timing Summary Report

Num Failing Num Failing

WNS TNS WHS THS
Endpoints Endpoints
Opt
Place
Physopt
Route

12. Run report_exceptions -ignored to identify if there are constraints that overlap in
the design. Record the results.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 225
 Chapter 6: Design Closure

Analyzing and Resolving Timing Violations

The timing driven algorithms focus on the worst violations for each clock domain. When the
worst violations are fixed, the tools typically resolve many of the less critical paths automatically
when you rerun the implementation tools. You can assist in this process by focusing on
resolutions that positively impact a high number of paths. For example, correcting suboptimal
clocking typically impacts a high number of paths so Xilinx recommends focusing on these issues
first before moving to path specific resolutions.

The Report QoR Suggestions command automatically identifies issues and orders suggestions
based on criticality. You can determine the progress made towards timing closure by running the
Report QoR Assessment command both before and after applying the suggestions. An increase in
the QoR Assessment Score and a decrease in the detailed table marked for review indicates
improvements.

The following figure shows the basic process for analyzing and resolving timing violations.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 226
 Chapter 6: Design Closure

Figure 116: Analyzing and Resolving Timing Violations

Load Design Checkpoint with Timing

Violations

Try report_qor_suggestions for automated analysis and timing

closure recommendations

Manually Identify Timing Violations Root Causes with

report_timing_summary and report_design_analysis

· Modify RTL to use parallel or efficient operator

· Add pipeline registers, and use synthesis retiming
High Cell Delay · Pipeline DSP, RAMB, and URAM paths
· Optimize SRL paths
· Remove KEEP/DONT_TOUCH/MARK_DEBUG

· Review and adjust floorplan constraints

· Optimize high fanout nets
High Route Delay · Address placer or router congestion level > 4 from log file or
reported by report_design_analysis -congestion

Reduce Clock Skew

· Use parallel buffers instead of cascaded buffers
· Use CLOCK_DELAY_GROUP
· Add timing exceptions between asynchronous clocks
High Clock Skew
or Uncertainty
Reduce Clock Uncertainty
· Optimize MMCM settings
· Divide clocks with BUFGCE_DIV

X20036-110617

Identifying Timing Violations Root Cause

For setup, you must first analyze the worst violation of each clock group. A clock group refers to
all intra, inter, and asynchronous paths captured by a given clock.

For hold, all violations must be reviewed as follows:

• Before routing, review only violations over 0.5 ns.

• After routing, start with the worst violation.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 227
 Chapter 6: Design Closure

Reviewing Timing Slack

Several factors can impact the setup and hold slacks. You can easily identify each factor by
reviewing the setup and hold slack equations when written in the following simplified form:

• Slack (setup/recovery) = setup path requirement:

- datapath delay (max)

+ clock skew

- clock uncertainty

- setup/recovery time

• Slack (hold/removal) = hold path requirement:

+ datapath delay (min)

- clock skew

- clock uncertainty

- hold/removal time

For timing analysis, clock skew is always calculated as follows:

• Clock Skew = destination clock delay - source clock delay (after the common node if any)

During the analysis of the violating timing paths, you must review the relative impact of each
variable to determine which variable contributes the most to the violation. Then you can start
analyzing the main contributor to understand what characteristic of the path influences its value
the most and try to identify a design or constraint change to reduce its impact. If a design or
constraint change is not practical, you must do the same analysis with all other contributors
starting with the worst one. The following list shows the typical contributor order from worst to
least.

For setup/recovery:

• Datapath delay: Subtract the timing path requirement from the datapath delay. If the
difference is comparable to the (negative) slack value, then either the path requirement is too
tight or the datapath delay is too large.

• Datapath delay + setup/recovery time: Subtract the timing path requirement from the
datapath delay plus the setup/recovery time. If the difference is comparable to the (negative)
slack value, then either the path requirement is too tight or the setup/recovery time is larger
than usual and noticeably contributes to the violation.

• Clock skew: If the clock skew and the slack have similar negative values and the skew
absolute value is over a few 100 ps, then the skew is a major contributor and you must review
the clock topology.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 228
 Chapter 6: Design Closure

• Clock uncertainty: If the clock uncertainty is over 100 ps, then you must review the clock
topology and jitter numbers to understand why the uncertainty is so high.

For hold/removal:

• Clock skew: If the clock skew is over 300 ps, you must review the clock topology.

• Clock uncertainty: If the clock uncertainty is over 200 ps, then you must review the clock
topology and jitter numbers to understand why the uncertainty is so high.

• Hold/removal time: If the hold/removal time is over a few 100 ps, you can review the
primitive data sheet to validate that this is expected.

• Hold path requirement: The requirement is usually zero. If not, you must verify that your
timing constraints are correct.

Assuming all timing constraints are accurate and reasonable, the most common contributors to
timing violations are usually the datapath delay for setup/recovery timing paths, and skew for
hold/removal timing paths. At the early stage of a design cycle, you can fix most timing problems
by analyzing these two contributors. However, after improving and refining design and
constraints, the remaining violations are caused by a combination of factors, and you must
review all factors in parallel to identify which to improve.

See this link for more information on timing analysis concepts, and see this link for more
information on timing reports (report_timing_summary/report_timing) in the Vivado
Design Suite User Guide: Design Analysis and Closure Techniques (UG906).

Using the Design Analysis Report

When timing closure is difficult to achieve or when you are trying to improve the overall
performance of your application, you must review the main characteristics of your design after
running synthesis and after any step of the implementation flow. The QoR analysis usually
requires that you look at several global and local characteristics at the same time to determine
what is suboptimal in the design and the constraints, or which logic structure is not suitable for
the target device architecture and implementation tools. The report_design_analysis
command gathers logical, timing, and physical characteristics in a few tables to simplify the QoR
root cause analysis.

Note: The report_design_analysis command does not report on the completeness and correctness
of timing constraints.

TIP: Run the Design Analysis Report in the Vivado IDE for improved visualization, automatic filtering, and
convenient cross-probing.

The following sections only cover timing path characteristics analysis. The Design Analysis report
also provides useful information about congestion and design complexity.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 229
 Chapter 6: Design Closure

Related Information

Checking That Your Design is Properly Constrained

Analyze Path Characteristics

To report the 50 worst setup timing paths, you can use the Report Design Analysis dialog box in
the Vivado IDE, or you can use the following command:

report_design_analysis -max_paths 50 -setup -name design_analysis_postRoute

The following figure shows an example of the Setup Path Characteristics table generated by this
command. To see additional columns in the window, scroll horizontally.

Figure 117: Report Design Analysis Timing Path Characteristics Post-Route

Following are tips for working with this table:

• Toggle between numbers and % by clicking the % (Show Percentage) button. This is
particularly helpful to review proportion of cell delay and net delay.
• By default, columns with only null or empty values are hidden. Click the Hide Unused button
to turn off filtering and show all columns, or right-click the table header to select which
columns to show or hide.

From this table, you can isolate which characteristics are introducing the timing violation for each
path:

• High logic delay percentage (Logic Delay)

○ Are there many levels of logic? (LOGIC_LEVELS)

○ Are there any constraints or attributes that prevent logic optimization? (DONT_TOUCH,
MARK_DEBUG)
○ Does the path include a cell with high logic delay such as block RAM or DSP? (Logical Path,
Start Point Pin Primitive, End Point Pin Primitive)
○ Is the path requirement too tight for the current path topology? (Requirement)

• High net delay percentage (Net Delay)

○ Are there any high fanout nets in the path? (High Fanout, Cumulative Fanout)

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 230
 Chapter 6: Design Closure

○ Are the cells assigned to several Pblocks that can be placed far apart? (Pblocks)

○ Are the cells placed far apart? (Bounding Box Size, Clock Region Distance)

○ For SSI technology devices, are there nets crossing SLR boundaries? (SLR Crossings)

○ Are one or several net delay values a lot higher than expected while the placement seems
correct? Select the path and visualize its placement and routing in the Device window.
○ Is there a missing pipeline register in a block RAM or DSP cell? (Comb DSP, MREG, PREG,
DOA_REG, DOB_REG)
• High skew (<-0.5 ns for setup and >0.5 ns for hold) (Clock Skew)
○ Is it a clock domain crossing path? (Start Point Clock, End Point Clock)

○ Are the clocks synchronous or asynchronous? (Clock Relationship)

○ Is the path crossing I/O columns? (IO Crossings)

TIP: For visualizing the details of the timing paths in the Vivado IDE, select the path in the table, and
go to the Properties tab.

Review the Logic Level Distribution

The report_design_analysis command also generates a Logic Level Distribution table for
the worst 1000 paths (default) that you can use to identify the presence of longer paths in the
design. The longest paths are usually optimized first by the placer to meet timing, which will
potentially degrade the placement quality of shorter paths. You must always try to eliminate the
longer paths to improve the overall timing QoR. For this reason, Xilinx recommends reviewing the
longest paths before placement.

The following figure shows an example of the Logic Level Distribution for a design where the
worst 5000 paths include difficult paths with 17 logic levels while the clock period is 7.5 ns. Run
the following command to obtain this report:

report_design_analysis -logic_level_distribution -logic_level_dist_paths

5000 -name design_analysis_prePlace

Figure 118: Report Design Analysis Timing Path Characteristics Pre-Place

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 231
 Chapter 6: Design Closure

For logic levels above 10, you can use the -min_level and -max_level options to provide
more distribution information for paths between the min and max level you identify. For
example:
report_design_analysis -logic_level_distribution -min_level 16 -max_level 20
-logic_level_dist_paths 5000 -name design_analysis_1

Run the following command to generate the timing report of the longest paths:
report_timing -name longPaths -of_objects [get_timing_paths -setup -to [get_clocks
cpuClk_5] -max_paths 5000 -filter {LOGIC_LEVELS>=16 && LOGIC_LEVELS<=20}]

Based on what you find, you can improve the netlist by changing the RTL or using different
synthesis options, or you can modify the timing and physical constraints.

Datapath Delay and Logic Levels

In general, the number of LUTs and other primitives in the path is most important factor in
contributing to the delay. Because LUT delays are reported differently in different devices,
separate cell delay and route delay ranges must be considered.

If the path delay is dominated by:

• Cell delay is >25% in 7 series devices and >50% in UltraScale devices.

Can the path be modified to be shorter or to use faster logic cells? See Reducing Logic Delay.
• Route delay is >75% in 7 series devices and >50% in UltraScale devices.
Was this path impacted by hold fixing? You can determine this by running
report_design_analysis -show_all and examining the Hold Detour column. Use the
corresponding analysis technique.
○ Yes - Is the impacted net part of a CDC path?
- Yes - Is the CDC path missing a constraint?
- No - Do the startpoint and endpoint of that hold-fixed path use a balanced clock tree?
Look at the skew value.
○ No - See the following information on congestion.

Was this path impacted by congestion? Look at each individual net delay, the fanout and
observe the routing in the Device view with routing details enabled (post-route analysis only).
You can also turn on the congestion metrics to see if the path is located in or near a congested
area. Use the following analysis steps for a quick assessment or review Reducing Net Delay
Caused by Congestion for a comprehensive analysis.
○ Yes - For the nets with the highest delay value, is the fanout low (<10)?
- Yes - If the routing seems optimal (straight line) but driver and load are far apart, the
sub-optimal placement is related to congestion. Review Addressing Congestion to
identify the best resolution technique.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 232
 Chapter 6: Design Closure

- No - Try to use physical logic optimization to duplicate the driver of the net. Once
duplicated, each driver can automatically be placed closer to its loads, which will reduce
the overall datapath delay. Review Optimizing High Fanout Nets for more details and to
learn about alternate techniques.
○ No - The design is spread out too much. Try one of the following techniques to improve the
placement:
- Reducing Control Sets
- Tuning the Compilation Flow
- Considering Floorplan

Clock Skew and Uncertainty

Xilinx devices use various types of routing resources to support most common clocking schemes
and requirements such as high fanout clocks, short propagation delays, and extremely low skew.
Clock skew affects any register-to-register path with either a combinational logic or interconnect
between them.

RECOMMENDED: Run a design analysis report (report_design_analysis) to generate a timing

report, which includes information on clock skew data. Verify that the clock nets do not contain excessive
clock skew.

Clock skew in high performance clock domains (+300 MHz) can impact performance. In general,
the clock skew should be no more than 500 ps. For example, 500 ps represents 15% of a 300
MHz clock period, which is equivalent to the timing budget of 1 or 2 logic levels. In cross domain
clock paths the skew can be higher, because the clocks use different resources and the common
node is located further up the clock trees. SDC-based tools time all clocks together unless
constraints specify that they should not be (for example, set_clock_groups,
set_false_path, or set_max_delay -datapath_only).

If the clock uncertainty is over 100 ps, then you must review the clock topology and jitter
numbers to understand why the uncertainty is so high.

Related Information

Reducing Clock Skew

Reducing Clock Uncertainty

Reducing Logic Delay

Vivado implementation focuses on the most critical paths first, which often makes less difficult
paths become critical after placement or after routing. Xilinx recommends identifying and
improving the longest paths after synthesis or after opt_design, because it will have the
biggest impact on timing and power QoR and will usually dramatically reduce the number of
place and route iterations to reach timing closure.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 233
 Chapter 6: Design Closure

Before placement, timing analysis uses estimated delays that correspond to ideal placement and
typical clock skew. By using report_timing, report_timing_summary, or
report_design_analysis, you can quickly identify the paths with too many logic levels or
with high cell delays, because they usually fail timing or barely meet timing before placement.
Use the methodology proposed in Identifying Timing Violations Root Cause to find the long
paths which need to be improved before implementing the design.

Related Information

Identifying Timing Violations Root Cause

Optimizing Regular Fabric Paths

Regular fabric paths are paths between fabric registers or shift registers that traverse a mix of
resources, such as LUTs. The report_design_analysis Timing Path Characteristics table
provides the best logic path topology summary, where the following issues can be identified:

• Several small LUTs are cascaded

Mapping to LUTs is impacted by hierarchy, the presence of KEEP_HIERARCHY,
DONT_TOUCH, or MARK_DEBUG attributes, or intermediate signals with some fanout (10
and higher). Run the opt_design -remap option or use the AddRemap or
ExploreWithRemap directives to collapse smaller LUTs and reduce the number of logic levels.
If opt_design is unable to optimize the longest paths due to a net fanout greater than one
between the small LUTs, you can force the optimization by setting the LUT_REMAP property
on the LUTs.
• Single CARRY cell is present in the path
CARRY primitives are most beneficial for timing QoR when cascaded. CARRY cells are more
difficult to place than LUTs, and forcing synthesis to use LUTs rather than a single CARRY
allows for better LUTs structuring and more flexible placement in many cases. Try the
FewerCarryChains synthesis directive or the PerfThresholdCarry strategy (Project Mode only)
to eliminate most single CARRY cells. Alternatively, use the CARRY_REMAP property to
instruct opt_design to remap the tagged CARRY cells to LUTs.
Note: This optimization technique is automatically applied by the report_qor_suggestions Tcl
command.

• Path ends at shift register (SRL)

Pull the first register out of the shift register by using the SRL_STYLE attribute in RTL. For
details, see this link in the Vivado Design Suite User Guide: Synthesis (UG901). Alternatively, you
can use the SRL_STAGES_TO_REG_INPUT property applied prior to opt_design to
implement the same optimization. For details, see this link in the Vivado Design Suite User
Guide: Implementation (UG904).
Note: This optimization technique is automatically applied by the report_qor_suggestions Tcl
command.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 234
 Chapter 6: Design Closure

• Path ends at a fabric register (FD) clock enable or synchronous set/reset

If the path ending at the data pin (D) has more margin and fewer logic levels, use the
EXTRACT_ENABLE or EXTRACT_RESET attribute and set it to "no" on the signal in RTL.
Alternatively, you can instruct opt_design to perform the same optimization by setting the
CONTROL_SET_REMAP property on the registers to optimize.
Note: This optimization technique is automatically applied by the report_qor_suggestions Tcl
command.

TIP: To cross-probe from a post-synthesis path to the corresponding RTL view and source code, see this
link in the Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906).

Related Information

Pushing the Logic from the Control Pin to the Data Pin

Optimizing Paths with Dedicated Blocks and Macro Primitives

Paths from/to/between dedicated blocks and macro primitives (e.g., DSP, block RAM, or
UltraRAM) need special attention because these primitives usually have the following timing
characteristics:

• Higher setup/hold/clock-to-output timing arc values for some pins. For example, a block RAM
has a clock-to-output delay around 1.5 ns without the optional output register and 0.4 ns with
the optional output register. Review the data sheet of your target device series for complete
details.
• Higher routing delays than regular FD/LUT connections.
• Higher clock skew variation than regular FD-FD paths.

Also, their availability and site locations are restricted compared to CLB slices, which usually
makes their placement more challenging and often incurs some QoR penalty.

For these reasons, Xilinx recommends the following:

• Pipeline paths from and to dedicated blocks and macro primitives as much as possible.
• Restructure the combinational logic connected to these cells to reduce the logic levels by at
least 1 or 2 cells if latency incurred by pipelining is a concern.
• Meet setup timing by at least 500 ps on these paths before placement.
• Replicate cones of logic connected to too many dedicated blocks or macro primitives if they
need to be placed far apart.
• When the design has tight timing requirements to, within, or from a DSP block, run
opt_design -dsp_register_opt to move registers to a more timing optimal position.
Note: Because timing is approximate during opt_design, you might also need to run
phys_opt_design -dsp_register_opt to correct movements where timing was not accurately
represented at the pre-placement stage.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 235
 Chapter 6: Design Closure

Reducing Net Delay Caused by Physical Constraints

All designs come with a minimum set of physical constraints, especially for I/O location, and
sometimes for clocking and logic placement. While I/O location cannot be modified when the
design is ready for timing closure, physical constraints such as Pblocks and LOC must be
analyzed. Use the report_design_analysis Timing Path Characteristics table to identify the
presence of several Pblocks constraints on each critical path.

In the Vivado IDE Properties window, you can select the path in the Timing Path Characteristic
table to review which Pblocks are constraining cells in the path. Consider removing one or
several Pblock constraints if the constraints force logic spreading.

Reducing Net Delay Caused by Congestion

Device congestion can potentially lead to difficult timing closure if the critical paths are placed
inside or next to a congested area or if the device utilization is high and the placed design is
hardly routable. In many cases, congestion will significantly increase the router runtime. If a path
shows routed delays that are longer than expected, analyze the congestion of the design and
identify the best congestion alleviation technique.

Congestion Area and Level Definition

Xilinx device routing architecture comprises interconnect resources of various lengths in each
direction: North, South, East, and West. A congested area is reported as the smallest square that
covers adjacent interconnect tiles (INT_XnYm) or CLB tiles (CLE_M_XnYm) where interconnect
resource utilization in a specific direction is close to or over 100%. The congestion level is the
positive integer which corresponds to the side length of the square. The following figure shows
the relative size of congestion areas on a Xilinx device versus clock regions.

Figure 119: Congestion Levels and Areas in the Device View

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 236
 Chapter 6: Design Closure

Congestion Level Ranges

When analyzing congestion, the level reported by the tools can be categorized as shown in the
following table.

Note: Congestion levels of 5 or higher often impact QoR and always lead to longer router runtime.

Table 11: Congestion Level Ranges

Level Area Congestion QoR Impact

1, 2 2x2, 4x4 None None
3, 4 8x8, 16x16 Mild Possible QoR degradation
5 32x32 Moderate Likely QoR degradation
6 64x64 High Difficulty routing
7, 8 128x128, 256x256 Impossible Likely unroutable

Interconnect Congestion Level in the Device Window

The Interconnect Congestion Level metric highlights the largest contiguous area in which routing
resources are overused. By default, this metric is based on estimation, which is similar to the
congestion level after initial routing. Actual routing can also be displayed if routing exists. After
placement or after routing, you can display this congestion metric by right-clicking in the Device
window and selecting Metric → Interconnect Congestion Level.

The Interconnect Congestion Level metric provides a quick visual overview of any congestion
hotspots in the device. The following figure shows a placed design with several congested areas.
This metric is based on the current interconnect demand and availability with a threshold of 0.9
(that is, 90% routing usage). The range is 0.1 to 0.9.

You can visualize congestion based on:

• Direction: North, South, East, West, Vertical, Horizontal

• Type: Short, Long, Global
• Style: Estimated, Routed, Mixed

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 237
 Chapter 6: Design Closure

Figure 120: Example of Interconnect Congestion Level in the Device Window

Use the Routing Congestion per CLB, which is based on estimation and not actual routing. After
placement or after routing, you can display this congestion metric by right-clicking in the Device
window and selecting Metric → Vertical and Horizontal Routing Congestion per CLB. This
provides a quick visual overview of any congestion hotspots in the device. The following figure
shows a placed design with several congested areas due to high utilization and netlist complexity.

Note: Use this method for 7 series and UltraScale devices only.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 238
 Chapter 6: Design Closure

Figure 121: Example of Congestion per CLB in the Device Window

Congestion in the Placer Log

The placer estimates congestion throughout the placement phases and spreads the logic in
congested areas. This helps reducing the interconnect utilization to improve routability, and also
the estimated versus routed delays correlation. However, when the congestion cannot be
reduced due to high utilization or other reasons, the placer does not print congestion details but
issues the following warning:
WARNING: [Place 46-14] The placer has determined that this design is highly congested
and may have difficulty routing. Run report_design_analysis -congestion for a
detailed report.

In that case the QoR is very likely impacted and it is prudent to address the issues causing the
congestion before continuing on to the router. As stated in the message, use the
report_design_analysis command to report the actual congestion levels, as well as
identify their location and the logic placed in the same area.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 239
 Chapter 6: Design Closure

Congestion in the Router Log

The router issues additional messages depending on the congestion level and the difficulty to
route certain resources. The router also prints several intermediate timing summaries. The first
one comes after routing all the clocks and usually shows WNS/TNS/WHS/TNS numbers similar
to post-place timing analysis. The next router intermediate timing summary is reported after
initial routing. If the timing has degraded significantly, the timing QoR has been impacted by hold
fixing and/or congestion.

When congestion level is 4 or higher, the router prints an initial estimated congestion table which
gives more details on the nature of the congestion:

• Global Congestion is similar to how the placer congestion is estimated and is based on all
types of interconnects.
• Long Congestion only considers long interconnect utilization for a given direction.
• Short Congestion considers all other interconnect utilization for a given direction.

Any congestion area greater than 32x32 (level 5) will likely impact QoR and routability
(highlighted in yellow in the table below). Congestion on Long interconnects increases usage of
Short interconnects which results in longer routed delays. Congestion on Short interconnects
usually induce longer runtimes and if their tile % is more than 5%, it will also likely cause QoR
degradation (highlighted in red in the table below).

Figure 122: Initial Estimated Congestion Table

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 240
 Chapter 6: Design Closure

During Global Iterations, the router first tries to find a legal solution with no overlap and also
meet timing for both setup and hold, with higher priority for hold fixing. When the router does
not converge during a global iteration, it stops optimizing timing until a valid routed solution has
been found, as shown on the example below:
Phase 4.1 Global Iteration 0
Number of Nodes with overlaps = 1157522
Number of Nodes with overlaps = 131697
Number of Nodes with overlaps = 28118
Number of Nodes with overlaps = 10971
Number of Nodes with overlaps = 7324
WARNING: [Route 35-447] Congestion is preventing the router from routing all nets.
The router will prioritize the successful completion of routing all nets over timing
optimizations.

After a valid routed solution has been found, timing optimizations are re-enabled.

The route also flags CLB routing congestion and provides the name of the top most congested
CLBs. An Info message is issued and the congested CLBs and nets are written to the text file
listed in the message body. You can examine the text file for the list of CLB tiles and congested
nets that are involved in the CLB pin-feed congestion, and use the congestion alleviation
techniques listed in the Addressing Congestion section to resolve the CLB congestion before
routing the design.
INFO: [Route 35-443] CLB routing congestion detected. Several CLBs have high routing
utilization, which can impact timing closure. Congested CLBs and Nets are dumped in:
iter_200_CongestedCLBsAndNets.txt

TIP: Localized CLB routing congestion can lead to routing failures even when the reported congestion
levels for Global, Long, or Short congestion are within the acceptable range (less than 5). Look for the
message above and in generated text files for localized congestion hotspots.

Finally, when the router cannot find a legally routed solution, several Critical Warning messages,
as shown below, indicate the number of nets that are not fully routed and the number of
interconnect resources with overlaps.
CRITICAL WARNING: [Route 35-162] 44084 signals failed to route due to routing
congestion. Please run report_route_status to get a full summary of the design's
routing.
...
CRITICAL WARNING: [Route 35-2] Design is not legally routed. There are 91566 node
overlaps.

TIP: During routing, nets are spread around the congested areas, which usually reduces the final
congestion level reported in the log file when the design is successfully routed.

Report Design Analysis Congestion Report

To help you identify congestion, the Report Design Analysis command allows you to generate a
congestion report that shows the congested areas of the device and the name of design modules
present in these areas. The congestion tables in the report show the congested area seen by the
placer and router algorithms. The following figure shows an example of the congestion table.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 241
 Chapter 6: Design Closure

Figure 123: Congestion Table

The Placed Maximum, Initial Estimated Router Congestion, and Router Maximum congestion
tables provide information on the most congested areas in the North, South, East, and West
direction. When you select a window in the table, the corresponding congested area is
highlighted in the Device window.

The tables show the congestion at different stages of the design flow:

• Placed Maximum: Shows congestion based on the location of the cells and a model of routing.

• Initial Estimated Router Congestion: Shows congestion after a quick router iteration. This is
the most useful stage to analyze congestion because it gives an accurate picture of congestion
due to placement.

• Router Maximum: Shows congestion after the router has worked extensively to reduce
congestion.

The Congestion percentages in the Congestion Table show the routing utilization in the
congestion window. The top three hierarchical cells located in the congested window are listed
and can be selected and cross-probed to the Device window or Schematic window. The cell
utilization percentage in the congestion window is also shown.

With the hierarchical cells present in the congested area identified, you can use the congestion
alleviating techniques discussed later in this guide to try reducing the overall design congestion.

For more information on generating and analyzing the Report Design Analysis Congestion report,
see this link in the Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906).

Report Design Analysis Complexity Report

The Complexity Report shows the Rent Exponent, Average Fanout, and distribution per type of
leaf cells for the top-level design and/or for hierarchical cells. The Rent exponent is the
relationship between the number of ports and the number of cells of a netlist partition when
recursively partitioning the design with a min-cut algorithm. It is computed with similar
algorithms as the ones used by the placer during global placement. Therefore, it can provide a
good indication of the challenges seen by the placer, especially when the hierarchy of the design
matches well the physical partitions found during global placement.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 242
 Chapter 6: Design Closure

A design with higher Rent exponent corresponds to a design where the groups of highly
connected logic also have strong connectivity with other groups. This usually translates into a
higher utilization of global routing resources and an increased routing complexity. The Rent
exponent provided in this report is computed on the unplaced and unrouted netlist. After
placement, the Rent exponent of the same design can differ as it is based on physical partitions
instead of logical partitions.

Report Design Analysis runs in Complexity Mode when you do either of the following:

• Check the Complexity option in the Report Design Analysis dialog box Options tab.
• Execute the report_design_analysis Tcl command with the -complexity option.

The following figure shows the Complexity Report.

Figure 124: Complexity Report

The following table shows the typical ranges for the Rent Exponent.

Table 12: Rent Exponent Ranges

Range Meaning
0.0 to 0.65 This range is low to normal.
0.65 to 0.85 This range is high, especially when the total number of instances is above 15,000.
Above 0.85 This range is very high, indicating that the design might fail during implementation if
the number of instances is also high.

The following table shows the typical ranges for the Average Fanout.

Table 13: Average Fanout Ranges

Range Meaning
Below 4 This range is normal.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 243
 Chapter 6: Design Closure

Table 13: Average Fanout Ranges (cont'd)

Range Meaning
4 to 5 This range is high, indicating that placing the design without congestion might be
difficult.
When using SSI technology devices, if the total number of instances is above 100,000, it
might be difficult for the placer to find a solution that fits in 1 SLR or is spread over 2
SLRs.
Above 5 This range is very high, indicating that the design might fail during implementation.

You must treat high Rent exponents and high Average Fanouts for larger modules with higher
importance. Smaller modules, especially under 15,000 total instances, can have high Rent
exponent and high Average Fanout and still be easy to place and route successfully. Therefore,
you must review the Total Instances column along with the Rent exponent and Average Fanout.

TIP: Top-level modules do not necessarily have high complexity metrics even though some of the lower-
level modules have high Rent exponents and high Average Fanouts. Use the -hierarchical_depth
option to refine the analysis to include the lower-level modules.

For more information on generating and analyzing the Report Design Analysis Complexity report
see this link in the Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906).

Reducing Clock Skew

To meet requirements such as high fanout clocks, short propagation delays, and low clock skew,
Xilinx devices use dedicated routing resources to support the most common clocking schemes.
Clock skew can severely reduce timing budget on high frequency clocks. Clock skew can also add
excessive stress on implementation tools to meet both setup and hold when the device
utilization is high.

The clock skew is typically less than 300 ps for intra-clock timing paths and less than 500 ps for
timing paths between balanced synchronous clocks. When crossing resource columns, clock
skew shows more variation, which is reflected in the timing slack and optimized by the
implementation tools. For timing paths between unbalanced clock trees or with no common
node, clock skew can be several nanoseconds, making timing closure almost impossible.

To reduce clock skew:

1. Review all clock relationships to ensure that only synchronous clock paths are timed and
optimized.
2. Review the clock tree topologies and placement of timing paths impacted by higher clock
skew than expected, as described in the following sections.
3. Identify the possible clock skew reduction techniques, as described in the following sections.

Related Information

Defining Clock Groups and CDC Constraints

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 244
 Chapter 6: Design Closure

Using Intra-Clock Timing Paths

Timing paths with the same source and destination clocks that are driven by the same clock
buffer typically exhibit very low skew. This is because the common node is located on the
dedicated clock network, close to the leaf clock pins, as shown in the following figure.

Figure 125: Typical Synchronous Clocking Topology with Common Node Located on
Green Net

When analyzing the clock path in the timing report, the delays before and after the common
node are not provided separately because the common node only exists in the physical database
of the design and not in the logical view. For this reason, you can see the common node in the
Device window of the Vivado IDE when the Routing Resources are turned on but not in the
Schematic window. The timing report only provides a summary of skew calculation with source
clock delay, destination clock delay, and credit from clock pessimism removal (CPR) up to the
common node.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 245
 Chapter 6: Design Closure

Limiting Synchronous Clock Domain Crossing Paths

Timing paths between synchronous clocks driven by separate clock buffers exhibit higher skew,
because the common node is located before the clock buffers. That is, the common node is
farther from the leaf clock pins, resulting in higher pessimism in the timing analysis. The clock
skew is even worse for timing paths between unbalanced clock trees due the delay difference
between the source and destination clock paths. Although positive skew helps with meeting
setup time, it hurts hold time closure, and vice versa.

In the following figure, three clocks have several intra and inter clock paths. The common node of
the two clocks driven by the MMCM is located at the output of the MMCM (red markers). The
common node of the paths between the MMCM input clock and MMCM output clocks is located
on the net before the MMCM (blue marker). For the paths between the MMCM input clock and
MMCM output clocks, the clock skew can be especially high depending on the clkin_buf
BUFGCE location and the MMCM compensation mode.

Figure 126: Synchronous CDC Paths with Common Nodes on Input and Output of a
MMCM

Xilinx recommends limiting the number of synchronous clock domain crossing paths even when
clock skew is acceptable. Also, when skew is abnormally high and cannot be reduced, Xilinx
recommends treating these paths as asynchronous by implementing asynchronous clock domain
crossing circuitry and adding timing exceptions.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 246
 Chapter 6: Design Closure

Adding Timing Exceptions between Asynchronous Clocks

Timing paths in which the source and destination clocks originate from different primary clocks
or have no common node, no common phase, or no common period must be treated as
asynchronous clocks. In this case, the skew can be extremely large, making it impossible to close
timing.

You must review all timing paths between asynchronous clocks to ensure the following:

• Proper asynchronous clock domain crossing circuitry (report_cdc)

• Timing exception definitions that ignore timing analysis (set_clock_groups,
set_false_path) or ignore skew (set_max_delay -datapath_only)

You can use the Clock Interaction Report (report_clock_interaction) to help identify
clocks that are asynchronous and are missing proper timing exceptions.

Figure 127: Asynchronous CDC Paths with Proper CDC Circuitry and No Common Node

Related Information

Defining Clock Groups and CDC Constraints

Applying Common Techniques for Reducing Clock Skew

TIP: Given the flexibility of the UltraScale device clocking architecture, the report_methodology
command contains checks to aid you in creating an optimal clocking topology.

The following techniques cover the most common scenarios:

• Avoid timing paths between cascaded clock buffers by eliminating unnecessary buffers or
connecting them in parallel as shown in the following figure.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 247
 Chapter 6: Design Closure

Figure 128: Synchronous Clocking Topology with Cascaded BUFG Reconnected in

Parallel

• Combine parallel clock buffers into a single clock buffer and connect any clock buffer clock
enable logic to the corresponding sequential cell enable pins, as shown on figure below. If
some of the clocks are divided by the buffer's built-in divider, implement the equivalent
division with clock enable logic and apply multicycle path timing exceptions as needed. When
both rising and falling clock edges are used by the downstream logic or when power is an
important factor, this technique might not be applicable.

Figure 129: Synchronous Clocking Topology with Parallel Clock Buffer Recombined
into a Single Buffer

• Remove LUTs or any combinatorial logic in clock paths as they make clock delays and clock
skew unpredictable during placement, resulting in lower quality of results. Also, a portion of
the clock path is routed with general interconnect resources which are more sensitive to noise
than global clocking resources. Combinatorial logic usually comes from sub-optimal clock
gating conversion and can usually be moved to clock enable logic, either connected to the
clock buffer or to the sequential cells.
In the following figure, the first BUFG (clk1_buf) is used in LUT3 to create a gated clock
condition.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 248
 Chapter 6: Design Closure

Figure 130: Skew Due to Local Routing on Clock Network

IMPORTANT! The 7 series and UltraScale device clocking architectures differ. You must follow the
clocking guidelines for your targeted architecture and verify that your design complies.

Related Information

Clocking Guidelines

Applying Techniques for Improving Skew in 7 Series Devices

Although the 7 series and UltraScale architectures differ in terms of clock architectures, some
general clock considerations apply to both families:

• Do not use the CLOCK_DEDICATED_ROUTE=FALSE constraint in a production 7 series

design. Use CLOCK_DEDICATED_ROUTE=FALSE only as a temporary workaround to a clock
failure only to produce an implemented design in order to view the clocking topology for
debugging. Clock paths routed with fabric interconnect can have high clock skew and be
impacted by switching noise, leading to poor performance or non-functional designs. In the
following figure, the right side has a dedicated clock route, while on the left side, the
dedicated route is disabled for clock.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 249
 Chapter 6: Design Closure

Figure 131: Comparison of Fabric Clock Route versus Dedicated Clock Route

• Do not allow regional clock buffers (BUFR/BUFIO/BUFH) to drive logic in several clock
regions as the skew between the clock tree branches in each region will be very high. Remove
inappropriate LOC or Pblock constraints to resolve this situation.

Improving Skew in UltraScale and UltraScale+ Devices

• Avoid using an MMCM or PLL to perform simple division of a BUFG_GT clock. BUFG_GT cells
have the ability to divide down the input clock. The following figure shows how to save an
MMCM resource and implement balanced clock trees for two clocks originating from a
GTHE3_CHANNEL cell.

Figure 132: Implementing Balanced Clock Trees using UltraScale BUFG_GTs

• Use the CLOCK_DELAY_GROUP on the driver net of critical synchronous clocks to force
CLOCK_ROOT and route matching during placement and routing. The buffers of the clocks
must be driven by the same cell for this constraint to be honored.
Note: This optimization technique is automatically applied by the report_qor_suggestions Tcl
command.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 250
 Chapter 6: Design Closure

• If a timing path is having difficulty meeting timing and the skew is larger than expected, it is
possible that the timing path is crossing an SLR or an I/O column. If this is the case, physical
constraints such as Pblocks may be used to force the source and destination into a single SLR
or to prevent the crossing of an I/O column.
• When working with high speed synchronous clock domain crossing timing paths, constraining
the location of the clock modifying blocks, such as the MMCM/PLL, to the center of the clock
loads can aid in meeting timing. The decreased delay on the clock networks will result in less
timing pessimism on the clock domain crossing paths.
• Verify that clock nets with CLOCK_DEDICATED_ROUTE=FALSE constraint are routed with
global clocking resources. Use ANY_CMT_COLUMN instead of FALSE to ensure the clock
nets with routing waivers are routed with dedicated clocking resources only. If the clock net is
routed with fabric interconnect, identify the design change or clocking placement constraint
needed to resolve this situation and make the implementation tools use global clocking
resources instead. Clock paths routed with fabric interconnect can have high clock skew or be
impacted by switching noise, leading to poor performance or non-functional designs.

Related Information

Synchronous CDC
Clock Constraints

Reducing Clock Delay in UltraScale and UltraScale+ Devices

In UltraScale and UltraScale+™ global clock routing, the clock net is first routed from a global
clock buffer via the horizontal and vertical routing track to a central location called the clock
root. From the clock root, the clock net spans out to drive clock rows in each clock region via the
vertical distribution track. On each row, there are programmable delays in the clock network on
BUFCE_ROW route-through sites that perform a coarse-grained deskew as the clock spans
farther from the clock root.

The following figure shows a clock path from the global clock buffer (BUFG) to the clock root.
The clock routing switches from routing to the vertical distribution track, through the
BUFCE_ROW in each clock region row that drives the horizontal distribution tracks, and then to
the leaf level. The source is shown in green and the destination in red.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 251
 Chapter 6: Design Closure

Figure 133: Clock Path from BUFG to the Leaf Level via BUFCE_ROW

The row programmable tap delay is the largest near the clock root. This delay decreases by one
tap for one clock region as the clock reaches farther away from the root in the vertical direction,
eventually decreasing to zero.

The following figure shows the topology of the programmable row tap values decreasing from
the root. Higher tap values mean higher delays and higher crossing SLR clock skew, because the
higher tap values add additional uncertainty for timing due to the minimum/maximum delay
variation introduced by the manufacturing process variation. This makes it more difficult to meet
timing near the root where programmable tap delay values are higher. Farther from the root in
the vertical direction, there is less uncertainty, and it is generally easier to fix hold violations on
crossing SLR buses. For SLR crossing buses that are farther from the root in the horizontal
direction, the clock row delays increase. This additional delay introduces more minimum/
maximum delay variation and reduces the performance of SLR crossings.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 252
 Chapter 6: Design Closure

Figure 134: Row Programmable Tap Delay Settings Across an UltraScale+ SSI
Technology Device

For UltraScale+ SSI technology devices, you can improve SLR crossing speed using either of the
following methods:

• Move the clock root close to the SLR crossings in the horizontal direction
• Limit the maximum row programmable tap delay value to reduce the uncertainty

Note: Timing paths farther from the root in the vertical direction might become slightly slower due to
increased delay from hold fixing route detours. However, using these methods results in an overall
performance gain.

You can review the row programmable tap delay settings that the Vivado tool chose for each
global clock in your design in the Device Cell Placement Summary for Global Clock sections in
the Clock Utilization Report. Following is an example that shows the row programmable tap delay
settings for the g13 global clock in the HORIZONTAL PROG DELAY column, which is highlighted
in yellow.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 253
 Chapter 6: Design Closure

Figure 135: Global Clock Row Programmable Tap Delay Settings in the Clock
Utilization Report

For UltraScale+ SSI technology devices, the placer limits the maximum row programmable tap
delay value to reduce minimum/maximum delay variation and reduce SLR crossing clock skew
near the clock root, while also ensuring that clock regions on either side of SLR crossings have an
increasing or decreasing tap delay value to balance the clock skew on SLR crossing paths farther
from the root. The MAX_PROG_DELAY property value of the clock net can be queried to find
the maximum row programmable tap delay value used by the placer.

You can also limit the row programmable tap value using the USER_MAX_PROG_DELAY
property. Following is an example. To set the USER_MAX_PROG_DELAY property, the value
must be applied to the net segment directly driven by the global clock buffer. If the
USER_MAX_PROG_DELAY property is not set, the placer can use the maximum possible tap
setting of 7.

set_property USER_MAX_PROG_DELAY <0-7> [get_nets -of [get_pins BUFG/O]]

Following are tips when using the USER_MAX_PROG_DELAY property:

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 254
 Chapter 6: Design Closure

• The recommended USER_MAX_PROG_DELAY tap value is 3 or 4 for clocks that span the
majority of UltraScale+ SSI technology devices. When clock roots are near GT, PCIe®, or
CMAC blocks that are off-center in the device, SLR crossing performance on the opposite
device side is heavily impacted, because the common node for the launch and capture clock is
farther away from the SLR crossing.
• For clock groups using the CLOCK_DELAY_GROUP for clock network matching, ensure that
all clocks within the clock group use the same USER_MAX_PROG_DELAY value.

Reducing Clock Uncertainty

Clock uncertainty is the amount of uncertainty relative to an ideal clock. Uncertainty can come
from user-specified external clock uncertainty (set_clock_uncertainty), system jitter, or
duty cycle distortion. Clock-modifying blocks such as the MMCM and PLL also contribute to
clock uncertainty in the form of Discrete Jitter, and Phase Error if multiple related clocks are
used.

The Clocking Wizard provides accurate uncertainty data for the specified device and can
generate various MMCM clocking configurations for comparing different clock topologies. To
achieve optimal results for the target architecture, Xilinx recommends regenerating clock
generation logic using the Clocking Wizard rather than using legacy clock generation logic from
prior architectures.

Using MMCM Settings to Reduce Clock Uncertainty

Note: The report_qor_suggestions Tcl command flags this issue.

When configuring an MMCM for frequency synthesis, Xilinx recommends configuring the
MMCM to achieve the lowest output jitter on the clocks. Optimize the MMCM settings to run at
the highest possible voltage-controlled oscillator (VCO) frequency that meets the allowed
operating range for the device. The following equations show the relationship between VCO
frequency, M (multiplier), D (divider), and O (output divider) settings to both the input and output
clock frequencies:

F VCO = F CLKIN × M
D
F OUT = F CLKIN × M
D ×O

TIP: You can increase the VCO frequency by increasing M, lowering D, or both and compensating for the
change in frequency by increasing O. Increases in VCO frequency negatively affects the power dissipation
from the MMCM or PLL. You can also make small increases in the VCO frequency when you switch from
multiple MMCM clock outputs using BUFGs to one MMCM clock output using BUFGCE_DIVs, which
allows more clocks to use the fractional divider. When selecting between MMCM and PLL, MMCMs are
preferred because they are able to operate at a higher VCO frequency, have improved granularity for
selecting M and D values, and have fractional dividers (CLKOUT0).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 255
 Chapter 6: Design Closure

Different architectures have different VCO frequency maximums. Therefore, Xilinx recommends
regenerating clocking components to be optimal for your target architecture. Xilinx recommends
using the Clocking Wizard to automatically calculate M and D values along with the VCO
frequency to properly configure an MMCM for the target device.

TIP: When using the Clocking Wizard from the IP catalog, make sure that Jitter Optimization Setting is set
to the Minimize Output Jitter, which provides the higher VCO frequency. In addition, performing marginal
changes to the desired output clock frequency can allow for an even higher VCO frequency to further
reduce clock uncertainty.

The following MMCM frequency synthesis example uses an input clock of 62.5 MHz to generate
an output clock of approximately 40 MHz. There are two solutions, but the MMCM_2 with a
higher VCO frequency generates less clock uncertainty due to reduced jitter and phase error.

Table 14: MMCM Frequency Synthesis Example

MMCM_1 MMCM_2
Input clock 62.5 MHz 62.5 MHz
Output clock 40.0 MHz 39.991 MHz
CLKFBOUT_MULT_F(M) 16 22.875
DIVCLK_DIVIDE(D) 1 1
VCO Frequency 1000.000 MHz 1429.688
CLKOUT0_DIVIDE_F(O) 25 35.750
Jitter (ps) 167.542 128.632
Phase Error (ps) 384.432 123.641

Using BUFGCE_DIV to Reduce Clock Uncertainty

TIP: The report_qor_suggestions Tcl command flags this issue.

In UltraScale devices, BUFGCE_DIV cells can be used to reduce clock uncertainty on

synchronous clock domain crossings by eliminating MMCM Phase Error. For example, consider a
path between a 300 MHz and 150 MHz clock domains, where both clocks are generated by the
same MMCM.

In this case, the clock uncertainty includes 120 ps of Phase Error for both Setup and Hold
analysis. Instead of generating the 150 MHz clock with the MMCM, a BUFGCE_DIV can be
connected to the 300 MHz MMCM output and divide the clock by 2. For optimal results, the 300
MHz clock needs to also use a BUFGCE_DIV with BUFGCE_DIVIDE set to 1 to match the 150
MHz clock delay accurately, as shown in the following figure.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 256
 Chapter 6: Design Closure

Figure 136: Improving the Clock Topology for an UltraScale Synchronous CDC Timing
Path

With the new topology:

• For setup analysis, clock uncertainty does not include the MMCM phase error and is reduced
by 120 ps.
• For hold analysis, there is no more clock uncertainty (only for same edge hold analysis).
• The common node moves closer to the buffers, which saves some clock pessimism.

By applying the CLOCK_DELAY_GROUP constraint on the two clock nets, the clock paths will
have matched routing.

Note: The report_qor_suggestions Tcl command provides these constraints.

The following tables compare the clock uncertainty for setup and hold analysis of an UltraScale
synchronous CDC timing path.

Table 15: Comparison of Clock Uncertainty for Setup Analysis of an UltraScale

Synchronous CDC Timing Path

Setup Analysis MMCM Generated 150 MHz Clock BUFGCE_DIV 150 MHz Clock
Total System Jitter (TSJ) 0.071 ns 0.071 ns
Discrete Jitter (DJ) 0.115 ns 0.115 ns
Phase Error (PE) 0.120 ns 0.000 ns
Clock Uncertainty 0.188 ns 0.068 ns

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 257
 Chapter 6: Design Closure

Table 16: Comparison of Clock Uncertainty for Hold Analysis of an UltraScale

Synchronous CDC Timing Path

Hold Analysis MMCM Generated 150 MHz Clock BUFGCE_DIV 150 MHz Clock
Total System Jitter (TSJ) 0.071 ns 0.000 ns
Discrete Jitter (DJ) 0.115 ns 0.000 ns
Phase Error (PE) 0.120 ns 0.000 ns
Clock Uncertainty 0.188 ns 0.000 ns

Related Information

Synchronous CDC

Applying Common Timing Closure Techniques

The following techniques can help with design closure on challenging designs. Before attempting
these techniques, ensure that the design is properly constrained and that you identify the main
issue that affects the top violating paths.

RECOMMENDED: Xilinx recommends running the report_qor_suggestions Tcl command to

identify and apply many of these techniques automatically. For more information, see this link in the
Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906).

Improving the Netlist with Block-Level Synthesis Strategies

Although most designs can meet timing requirements with the default Vivado synthesis settings,
larger and more complex designs usually require a mix of synthesis strategies for different
hierarchies to close timing.

For example, one module might require the use of MUXF* resources to implement a timing
critical function, but the rest of the design might benefit from implementation of logic in LUTs
rather than MUXF* to reduce congestion. In this case, set the PERFORMANCE_OPTIMIZED
strategy for the timing-critical module, and synthesize the rest of the design using the
Flow_AlternateRoutability strategy to reduce congestion.

Related Information

Block-Level Synthesis Strategy

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 258
 Chapter 6: Design Closure

Improving Logic Levels

Throughout the design cycle, you must verify that the logic level distribution fits the clock
frequency goals for the target Xilinx device family and device speed grade. Although a limited
number of paths with a high number of logic levels do not always introduce a timing closure
challenge, you can improve the timing QoR by optimizing the longest paths in the design with the
Vivado synthesis retiming option.

Using the retiming option globally is usually runtime intensive and can negatively impact power.
Therefore, Xilinx recommends that you identify a specific hierarchy with violations on paths with
a high number of logic levels after synthesis or with optimal placement. When the paths in the
fanin or fanout of the longest paths have fewer logic levels and are contained within a small or
medium hierarchical module, you can use the BLOCK_SYNTH.RETIMING block-level synthesis
strategy.

The following figure shows a critical paths with five LUTs, constrained by a 600 MHz clock. The
REG2 destination flop drives a timing path with a single LUT that is included one hierarchy up
from REG2.

Figure 137: Schematic Showing Critical Path with Five Logic Levels

In addition to using the Schematic window in the Vivado IDE, you can use the
report_design_analysis -logic_level_distribution command to review the
distribution of logic levels for specific paths. This allows you to determine how many paths need
to be rebalanced to improve the timing QoR.

You can use the retiming_forward and retiming_backward attributes available in Vivado
synthesis to control the optimization on a specific register or a path. Using these attributes
applies retiming optimization on a specific set of paths rather than on the top module or
submodules, which reduces the area overhead. You can apply these attributes in the RTL or in the
XDC file. For more information, including usage and restrictions, see the Vivado Design Suite User
Guide: Synthesis (UG901).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 259
 Chapter 6: Design Closure

The following figure shows 58 paths with five logic levels within the inst1/inst2 hierarchy
constrained with the 600 MHz clock and 32 paths with only one logic level.

Figure 138: Logic Level Distribution with Default Synthesis Optimization

Vivado synthesis can rebalance the logic levels by moving the registers in the low logic level
paths into the high logic level paths. In this example, you can add the following constraint to the
synthesis XDC file to perform retiming on the inst1/inst2 hierarchy:

set_property BLOCK_SYNTH.RETIMING 1 [get_cells inst1/inst2]

After rerunning synthesis with the same global settings and the updated XDC file, you can run
regular timing analysis on the inst1/inst2 timing paths or rerun the
report_design_analysis command to verify that the longest paths have fewer logic levels,
as shown in the following figure. The critical path is now REG0 → 3 LUTs → REG2 (backward
retimed), and the path from REG2 to REG4 has three logic levels.

Figure 139: Logic Level Distribution with Retiming Enabled for Synthesis Optimization

Reducing Control Sets

Note: This optimization technique is automatically applied by the report_qor_suggestions Tcl
command.

Often not much consideration is given to control signals such as resets or clock enables. Many
designers start HDL coding with "if reset" statements without deciding whether the reset is
needed or not. While all registers support resets and clock enables, their use can significantly
affect the end implementation in terms of performance, utilization, and power.

The first factor to consider is the number of control sets. A control set is the group of clock,
enable, and set/reset signals used by a sequential cell. For example, two cells connected to the
same clock have different control sets if only one cell has a reset or if only one cell has a clock
enable. Constant or unused enable and set/reset register pins also contribute to forming control
sets.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 260
 Chapter 6: Design Closure

The second factor to consider is the targeted architecture. The number of control sets that can
be packed together depends on the architecture:

• A 7 series device slice (or half-CLB) comprises eight registers, which all share one clock, one
set/reset, and one clock enable. Only one control set can be used per group of eight registers.
• An UltraScale device half-CLB comprises two groups of four registers, which share one clock
and one set/reset. In addition, each group of four registers has one clock enable and can
ignore the set/reset. A constant set/reset signal is not routed and can be ignored. A constant
enable signal is treated like a dynamic enable signal and needs to be routed. Under optimal
conditions, up to two control sets can be used per group of eight registers.

CLB packing restrictions caused by control sets force the placer to move some registers,
including their input LUT. In some cases, the registers are moved to less optimal locations. The
additional distance can negatively impact not only utilization but also placement QoR and power
consumption, due to logic spreading (longer net delays) and higher interconnect resources
utilization. This is mainly of concern in designs with many low fanout control signals, such as
clock enables that feed single registers.

Despite the higher UltraScale device CLB control set capacity, typical designs show a control set
utilization similar to 7 series designs. Therefore, Xilinx recommendations are the same for both
architectures.

Follow Control Set Guidelines

The following table provides a guideline for the recommended number of control sets, depending
on the target device size, for both 7 series and UltraScale devices.

Table 17: Control Set Guidelines

Guideline Percentage of Control Sets

Acceptable Less than 7.5% of the total number of control sets in the device
Reduction Between 7.5% and 15% of the total number of control sets in the device
Recommended
Reduction Required Greater than 15% of the total number of control sets in the device

These guidelines assume the following:

• Typical control set capacity: 1 per 8 CLB registers

• Total number of control sets in a device: CLB registers / 8

To determine the number of control sets in a design:

• Before placement: Use report_control_sets -verbose

• After placement: Use report_utilization (text mode only)

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 261
 Chapter 6: Design Closure

TIP: The number of unique control sets can be a problem in a small portion of the design, resulting in
longer net delays or congestion in the corresponding device area. Identifying the high local density of
unique control sets requires detailed placement analysis in the Vivado IDE Device window, which includes
highlighted control signals in different colors.

Reduce the Number of Control Sets

If the number of control sets is high, use one of the following strategies to reduce their number:

• Remove the MAX_FANOUT attributes that are set on control signals in the HDL sources or
constraint files. Replication on control signals dramatically increases the number of unique
control sets. Xilinx recommends relying on place_design to perform coarse replication and
using phys_opt_design -directive Explore for finer replication after placer. This
prevents unnecessary replication and equivalent control sets from crossing each other, which
can lead to routing congestion.
• Increase the control set threshold of Vivado synthesis (or other synthesis tool). Review the
control sets fanout distribution table in report_control_sets -verbose to determine a
more appropriate control sets threshold to use during synthesis. Note that increasing
contol_set_opt can have negative impacts on power by eliminating clock enables that can
actively reduce power. For example:
synth_design -control_set_opt_threshold 16

TIP: Use the BLOCK_SYNTH synthesis constraints to change the control sets threshold on modules
that are the most impacted by placement spreading or congestion.

• Use opt_design -control_set_merge or opt_design -

merge_equivalent_drivers to merge equivalent control sets after synthesis.
• Use the CONTROL_SET_REMAP property to map low-fanout control signals driving the
synchronous set/reset and/or CE pin of a register to the D-input. For more information, see
this link in the Vivado Design Suite User Guide: Implementation (UG904).
• Avoid low fanout asynchronous set/reset (preset/clear), because they can only be connected
to dedicated asynchronous pins and cannot be moved to the datapath by synthesis. For this
reason, the synthesis control set threshold option does not apply to asynchronous set/reset.
• Avoid using both active-High and active-Low of a control signal for different sequential cells.
• Only use clock enable and set/reset when necessary. Often data paths contain many registers
that automatically flush uninitialized values, and where set/reset or enable signals are only
needed on the first and last stages.

Related Information

Control Signals and Control Sets

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 262
 Chapter 6: Design Closure

Optimizing High Fanout Nets

High fanout nets often lead to implementation issues. Because die sizes increase with each
device family, fanout problems also increase. It is often difficult to meet timing on nets that have
many thousands of endpoints, especially if there is additional logic on the paths, or if they are
driven from non-sequential cells, such as LUTs or distributed RAMs.

Allow Register Replication

Most tools can replicate registers to reduce high fanout nets on critical paths. Alternatively, you
can apply attributes on specific registers or levels of hierarchy to specify which registers can or
cannot be replicated. For example, the presence of a LUT1 on a replicated net indicates that an
attribute or constraint is partly preventing the optimization. During synthesis, a
KEEP_HIERARCHY attribute on a hierarchical cell traversed by the optimized net or a KEEP
attribute on net segment in a different hierarchy can alter the replication optimizations. During
synthesis and implementation, a DONT_TOUCH constraint also prevents beneficial replications.

Sometimes, designers address the high fanout nets in RTL or synthesis by using a MAX_FANOUT
attribute on a specific net. This does not always result in the most optimal routing resource
usage, especially if the MAX_FANOUT attribute is set too low or is set on a net connected to
several major hierarchies. In addition, if the high fanout signal is a register control signal and is
replicated more than necessary, this can lead to a higher number of control sets and increase
design power by unnecessarily adding additional registers that may not be necessary for timing
closure

Often, a better approach to reducing fanout is to use a balanced tree for the high fanout signals.
Consider manually replicating registers based on the design hierarchy, because the cells included
in a hierarchy are often placed together.

To restructure and reduce the number of control set trees and high fanout nets, you can use the
opt_design Tcl command with one of the following options:

• -control_set_merge: This option aggressively combines the drivers of logically-equivalent

control signals to a single driver.

• -merge_equivalent_drivers: This option merges logically-equivalent signals, including

control signals, to a single driver.

Note: Try this option first, because the tools are aware of major hierarchies and Pblock constraints when
you run this option.

These options are the reverse of fanout replication and result in nets that are better suited for
module-based replication. This merge also works across multi-stage reset trees as shown in the
following figure.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 263
 Chapter 6: Design Closure

Figure 140: Control Set Merging Using opt_design -control_set_merge

RST1 RST2 RST3 RST1 RST2 RST3

1 1 1 300 1400

RST3
2 400

RST2 RST3
2 3 200

RST3
4 500

X20035-122019

After reducing the number of replicated objects, you can use the opt_design Tcl command to
perform limited replication based on the hierarchy characteristics, with the following option:

• -hier_fanout_limit <arg>: This option replicates registers according to the hierarchy

where <arg> represents the fanout limit for the replication according to the logical hierarchy.
For each hierarchical instance driven by the high fanout net, if the fanout within the hierarchy
is greater than the specified limit, the net within the hierarchy is driven by a replica of the
driver of the high fanout net. The replicated driver is placed in the same level of hierarchy as
the original driver, and replication is not limited to control set registers.

The following figure shows replication on a clock enable net with a fanout of 60000 using
opt_design -hier_fanout_limit 1000. Because each module SR_1K contains 1000
loads, the driver is replicated 59 times.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 264
 Chapter 6: Design Closure

Figure 141: Module-Based Replication on a High-Fanout Clock Enable Net

Fanout optimization is enabled by default in place_design. Replication occurs early in the

placer flow and is based on placement information. Registers that drive more than 1000 loads
and registers that drive DSPs, block RAMs, and UltraRAMs are considered for replication and are
co-located with the loads if replication occurs. You can force the replication of a register or a LUT
driving a net by adding the FORCE_MAX_FANOUT property to the net. The value of the
FORCE_MAX_FANOUT specifies the maximum physical fanout the nets should have after the
replication optimization.

You can force replication based on physical device attributes with the MAX_FANOUT_MODE
property. Supported MAX_FANOUT_MODE properties are CLOCK_REGION, SLR, MACRO. For
example, the MAX_FANOUT_MODE property with a value of CLOCK_REGION replicates the
driver based on the physical clock region, the loads placed into same clock region will be
clustered together. For more information, see this link in the Vivado Design Suite User Guide:
Implementation (UG904).

For SSI technology devices, high-fanout drivers can be replicated for each SLR and optionally
assigned to SLR-aligned Pblocks along with their loads. This technique helps reduce the impact of
the SLR crossing delay and gives more freedom to place the replicated high fanout nets
independently in each SLR.

Related Information

Replicate High Fanout Net Drivers

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 265
 Chapter 6: Design Closure

Promote High Fanout Nets to Global Routing

Note: This optimization technique is automatically applied by the report_qor_suggestions Tcl
command.

Lower performance high fanout nets can be moved onto the global routing by inserting a clock
buffer between the driver and the loads. This optimization is automatically performed in
opt_design for nets with a fanout greater than 25000 only when a limited number of clock
buffers are already used and the clock period of the logic driven by the net is above the limit
specific to the targeted device and speed grade.

You can force synth_design and opt_design to insert a clock buffer when setting the
CLOCK_BUFFER_TYPE attribute on a net in the RTL file or in the constraint file (XDC). For
example:

set_property CLOCK_BUFFER_TYPE BUFG [get_nets netName]

Using global clocking ensures optimal routing at the cost of higher net delay. For best
performance, clock buffers must drive sequential loads directly, without intermediate
combinatorial logic. In most cases, opt_design reconnects non-sequential loads in parallel to
the clock buffer. If needed, you can prevent this optimization by applying a DONT_TOUCH on
the clock buffer output net. Also, if the high fanout net is a control signal, you must identify why
some loads are not dedicated clock enable or set/reset pins.

The placer also automatically routes high fanout nets (fanout > 10000) on any global routing
tracks available after clock routing is performed. This optimization occurs towards the end of the
placer flow and is only performed if timing does not degrade. You can disable this feature using
the -no_bufg_opt option.

Related Information

Control Signals and Control Sets

Use Physical Optimization

Physical optimization (phys_opt_design) automatically replicates the high fanout net drivers
based on slack and placement information, and usually significantly improves timing. Xilinx
recommends that you drive high fanout nets with a fabric register (FD*), which is easier to
replicate and relocate during physical optimization.

In some cases, the default phys_opt_design command does not replicate all critical high
fanout nets. Use a different directive to increase the command effort: Explore, AggressiveExplore
or AggressiveFanoutOpt. Also, when a high fanout net becomes critical during routing, you can
add an iteration of phys_opt_design to force replication on specific nets before trying to
route the design again. For example:

phys_opt_design -force_replication_on_nets [get_nets [list netA netB netC]]

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 266
 Chapter 6: Design Closure

Prioritize Critical Logic Using the group_path Command

You can use the group_path command with the -weight option to give higher priority to the
path endpoints defined in a clock group. For example, to assign a higher priority to group of logic
clocked by a specific clock, use the following command:

group_path -name [get_clocks clock] -weight 2

In this example, the implementation tools give higher priority to the paths that belong to clock
group clock with a weight of 2 over other paths in the design.

Fixing Large Hold Violations Prior to Routing

For paths that have large hold violations (> 0.4 ns), it is advantageous to reduce the hold
violations prior to routing the design, making it easier for the router to fix the remaining smaller
hold violations using route detours. Reducing hold violations prior to routing can be beneficial if
hold fixing has been identified as a source of routing congestion. The phys_opt_design hold
fixing options each use different resources and have specific targets. It is important to use the
proper option depending upon the device utilization and desired impact. Prior to running
phys_opt_design for hold fixing, it is important to validate that the design has properly
constrained clocktrees for minimal skew.

The insertion of negative-edge triggered registers between sequential elements can split a timing
path into two half period paths and significantly reduce hold violations. You can insert the
negative-edge triggered registers using the -insert_negative_edge_ffs option during the
phys_opt_design implementation step. Only paths with flip-flop drivers and at most one LUT
in between the sequential elements are considered for this optimization. The setup slack on the
paths must be sufficiently positive after the optimization or else the optimization is discarded.

The following figure shows a negative-edge triggered register inserted after a flip-flop driving a
CMAC block. Before the optimization, the hold slack between the flip-flop and the driver was
-0.492 ns. After the insertion of the negative-edge triggered register (highlighted in blue), the
setup and hold slack are both positive.

Figure 142: Fixing Hold Violation with Negative Edge Register Insertion

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 267
 Chapter 6: Design Closure

You can also insert LUT1 delays onto datapaths to reduce hold violations. To insert LUT1 delays,
use one of the following options during the phys_opt_design implementation step:

• -hold_fix: Performs LUT1 insertion and only considers paths that are the largest WHS
violators with sufficient positive setup slack.

• -aggressive_hold_fix: Performs LUT1 insertion in a more aggressive manner than the

standard -hold_fix option. The -aggressive_hold_fix optimization considers many
hold violating paths for LUT1 insertion and can be used to significantly reduce design THS at
the expense of LUT utilization.

Note: The phys_opt_design -directive ExploreWithAggressiveHoldFix directive runs

the Explore directive along with the -aggressive_hold_fix as a single optimization.

The following figure shows a LUT1 delay inserted after a flip-flop driving an ILKN block. Before
the optimization, the path from the flip-flop to the ILKN is the WHS path in the design with
-0.277 ns hold slack. After the insertion of the LUT1 delay (highlighted in blue), the hold slack is
positive and the setup slack remains positive.

Figure 143: Fixing Hold Violation with LUT1 Delay Insertion

Addressing Congestion
Congestion can be caused by a variety of factors and is a complex problem that does not always
have a straightforward solution. The report_design_analysis congestion report helps you
identify the congested regions and the top modules that are contained within the congestion
window. Various techniques exist to optimize the modules in the congested region. The
report_qor_suggestions can automate the resolution of many of the items that cause
congestion.

TIP: Before you try to address congestion with the techniques discussed in the following sections, make
sure that you have clean constraints and you followed the clocking guidelines recommended by Xilinx.
Excessive hold time failures (or negative hold slack) and clock uncertainties require the router to detour,
which can lead to congestion. Avoid overlapping Pblocks, which can also cause congestion.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 268
 Chapter 6: Design Closure

Lower Device Utilization

When several fabric resource utilization percentages are high (on average > 75%), placement
becomes more challenging if the netlist complexity is also high (high top-level connectivity, high
Rent exponent, high average fanout). High performance designs also come with additional
placement challenges. In such situations, revisit the design features and consider removing non-
essential modules until only one or two fabric resource utilization percentages are high. If logic
reduction is not possible, review the other congestion alleviation techniques presented in this
chapter.

TIP: Review resource utilization after opt_design to get more accurate numbers, once unused logic has
been trimmed instead of after synthesis.

Balance SLR Utilization for SSI Devices

When targeting SSI technology devices it is important to analyze the utilization per SLR region.
Overall utilization might be low, but high utilization in one SLR might lead to a congestion.

In the following figure, the overall utilization for the design is low. However, the utilization in
SLR2 is high and the logic requires more routing resources than logic in the other SLRs. The logic
in this area is a wide bus MUX that saturates the routing resources.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 269
 Chapter 6: Design Closure

Figure 144: Utilization Analysis per SLR Region

To balance utilization, try the following:

• Use different placer directives for spreading the design.

• Use floorplanning constraints, such as Pblocks to keep some modules out of the highly utilized
and congested SLR.

Use Alternate Placer and Router Directives

Because placement typically has the greatest impact on overall design performance, applying
different placer directives is one of the first techniques that should be tried to reduce congestion.
Consider running the alternate placer directives without any existing Pblock constraints in order
to give more freedom to the placer to spread the logic as needed.

Several placer directives exist that can help alleviate congestion by spreading logic throughout
the device to avoid congested regions. The SpreadLogic placer directives are:

• AltSpreadLogic_high

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 270
 Chapter 6: Design Closure

• AltSpreadLogic_medium
• AltSpreadLogic_low
• SSI_SpreadLogic_high
• SSI_SpreadLogic_low

When congestion is detected on SLR crossing, consider using:

• SSI_BalanceSLLs placer directive which helps with partitioning the design across SLRs while
attempting to balance SLLs between SLRs.
• SSI_SpreadSLLs placer directive which allocates extra area for regions of higher connectivity
when partitioning across SLRs.

Other placer directives or implementation strategies might also help with alleviating congestions
and should also be tried after the placer directives mentioned above.

To compare congestion for different placer directives either run the Design Analysis Congestion
report after place_design, or examine the initial estimated congestion in the router log file.

Routing has less impact on congestion than placer directives. However, in some cases it is useful
to attempt different routing directives. The following directive ensures that the router works
harder to access more routing and relieve congestion in the interconnect tiles:

• AlternateCLBRouting

Note: The AlternateCLBRouting routing directive is most effective when there is short congestion or both
short and long congestion. This directive only applies to UltraScale devices.

For more information, see this link in the Vivado Design Suite User Guide: Implementation (UG904).

Related Information

Congestion Level Ranges

Turn Off Cross-Boundary Optimization

Prohibiting cross-boundary optimization in synthesis prevents additional logic getting pulled into
a module. This reduces the complexity of the modules but can also lead to higher overall
utilization. This can be done globally with the -flatten_hierarchy none option in
synth_design. This same technique can be applied on specific modules with the
KEEP_HIERARCHY attribute in RTL.

Reduce MUXF Mapping

TIP: This optimization technique is automatically applied by the report_qor_suggestions Tcl

command.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 271
 Chapter 6: Design Closure

Using MUXF* primitives helps critical paths with many logic levels or a tight clock requirement
while also reducing power. MUXF* includes MUXF7, MUXF8, and MUXF9, which are dedicated
multiplexer resources located within the CLB. These resources are grouped with up to eight LUTs
during placement. This grouping forces high CLB input utilization with higher routing demand
and limits placement flexibility when the netlist connectivity is complex, leading to potential
higher routing congestion and timing degradation.

In addition, the opt_design command provides an optional MUX optimization phase to remap
MUXF* structures to LUT3 primitives to improve routability. You can use the -muxf_remap
option to remap all of the MUXF* cells. Alternatively, set the MUXF_REMAP property to TRUE
on a select number of cells in the congested region to limit the scope of the MUX remapping.
Any MUXF* cells with the MUXF_REMAP property set to TRUE automatically trigger the MUX
optimization phase during opt_design and are remapped to LUT3s.

Note: Disabling these resources can result in increased power. Use this method only when needed to
achieve timing closure.

The following figure shows a 16-1 MUX before and after the MUXF* optimization.

Figure 145: Netlist Before and After MUX Optimization

To further optimize the netlist after performing MUX optimization, use the -remap option with
the -muxf_remap option. This combines the LUT3 primitives that are generated by the MUXF*
optimization with connected logic if possible.

You can determine whether timing closure is impacted by routing congestion by reviewing the
Router Initial Estimated Congestion table in the log files or in the Design Analysis report
(report_design_analysis -congestion) after place or route is complete.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 272
 Chapter 6: Design Closure

In the following figure, the Design Analysis report shows that 7% of the device is impacted by
Short congestion level 5 (32x32 CLBs) in the South direction while 26% MUXF are utilized in the
corresponding congested area.

Figure 146: South Short Congestion in the report_design_analysis Congestion Table

In the Vivado IDE, you can select a row in the table of the Design Analysis congestion report to
highlight the corresponding congested area in the Device window. The following figure shows
that the congestion overlaps with a higher MUXF density area. The MUXF cells are highlighted in
magenta using the following command in the Vivado IDE Tcl Console:

highlight_objects -color magenta [get_cells -hier -filter REF_NAME=~MUXF*]

MUXF* includes MUXF7/MUXF8/MUXF9, which are dedicated multiplexer resources located

within the CLB. These resources are grouped with up to 8 LUTs during placement, forcing high
CLB input utilization with higher routing demand and limiting placement flexibility. The estimated
congestion per CLB is displayed using the Vivado IDE metrics.

Figure 147: MUXF Congestion Highlighted in the Vivado IDE Device Window

When high MUXF* utilization overlaps with areas of higher congestion, Xilinx recommends
reducing the number of MUXF* by mapping their corresponding functionality to LUTs, which
have higher placement and routing flexibility. You can use the following command in the XDC
synthesis constraints to modify the netlist:

set_property BLOCK_SYNTH.MUXF_MAPPING 0 [get_cells inst_name4]

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 273
 Chapter 6: Design Closure

After rerunning synthesis, place, and route, the updated congestion table in the Design Analysis
report now shows that the South Short congestion is lower (level 4), which typically improves the
timing quality of results.

Figure 148: Initial Router Congestion Table after Reducing MUXF Usage on a Module

Disable LUT Combining

Note: This optimization technique is automatically applied by the report_qor_suggestions Tcl
command.

LUT combining reduces logic utilization by combining LUT pairs with shared inputs into single
dual-output LUTs that use both O5 and O6 outputs. However, LUT combining can potentially
increase congestion because it tends to increase the input/output connectivity for the slices. If
LUT combining is high in the congested area (> 40%), you can try using a synthesis strategy that
eliminates LUT combining to help alleviate congestion. The Flow_AlternateRoutability
synthesis strategy and directive instructs the synthesis tool to not generate any additional LUT
combining.

Note: If you are using Synplify Pro for synthesis, you can use the Enable Advanced LUT Combining option
in the Implementation Options under the Device tab. This option is on by default. If you are modifying the
Synplify Pro project file (*prj), the following is specified: set_option -enable_prepacking 1.

You can use the following command to select cells with LUT combining enabled in your design:

select_objects [get_cells -hier -filter {SOFT_HLUTNM != "" || HLUTNM != ""}]

The following figure shows the horizontal congestion of a design with and without LUT
combining. The cells with LUT combining are highlighted in purple.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 274
 Chapter 6: Design Closure

Figure 149: Effect of LUT Combining on Horizontal Congestion

Horizontal Congestion with LUT Combining Horizontal Congestion

without LUT Combining
X18040-120519

To disable LUT combining on a module that overlaps with areas of higher congestion, use the
following Tcl command:
reset_property SOFT_HLUTNM [get_cells -hierarchical -filter {NAME =~ <module name> &&
SOFT_HLUTNM != ""}]

Limit High-Fanout Nets in Congested Areas

Note: This optimization technique is automatically applied by the report_qor_suggestions Tcl
command.

High fanout nets that have tight timing constraints require tightly clustered placement to meet
timing. This can cause localized congestion as shown in the following figure. High fanout nets can
also contribute to congestion by consuming routing resources that are no longer available for
other nets in the congestion window.

To analyze the impact of high fanout non-global nets on routability in the congestion window you
can:

• Select the leaf cells of the top hierarchical modules in the congestion window.
• Use the find command (Edit → Find) to select all of the nets of the selected cell objects (filter
out Global Clocks, Power, and Ground nets).
• Sort the nets in decreasing Flat Pin Count order.
• Select the top fan-out nets to show them in relation to the congestion window.

This can quickly help you identify high-fanout nets which potentially contribute to congestion.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 275
 Chapter 6: Design Closure

Figure 150: High-Fanout Nets in Congestion Window

For high fanout nets with tight timing constraints in the congestion window, replicating the
driver will help relaxing the placement constraints and alleviate congestion.

High fanout nets (fanout > 5000) with sufficient positive timing slack can be routed on global
clock resources instead of fabric resources. The placer automatically routes high fanout nets with
fanout > 1000 on global routing resources if those resources are available towards the end of the
placer step. This optimization only occurs if it does not degrade timing.

You can also set the property CLOCK_BUFFER_TYPE=BUFG on the net and let synthesis or logic
optimization automatically insert the buffer prior to the placer step. Review the newly inserted
buffer placement along with its driver and loads placement after place_design to verify that it
is optimal. If it is not optimal, use the CLOCK_REGION constraint (UltraScale devices only) or
LOC constraint (7 series devices only) on the clock buffer to control its placement.

Use Cell Bloating

You can use cell bloating to insert whitespace (increased cell spacing) during the place_design
step. This leads to a lower density of cells in a given area of the die, which can reduce congestion
by increasing available routing. This technique is particularly effective in small, congested areas
of relatively high-performance logic.

To use cell bloating, apply the CELL_BLOAT_FACTOR property to hierarchical cells and set the
value to LOW, MEDIUM, or HIGH. When working with smaller modules of several hundred cells,
HIGH is the recommended setting.

CAUTION! If the device already uses too many routing resources, cell bloating is not recommended. In
addition, using cell bloating on larger cells might force placed cells to be too far apart.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 276
 Chapter 6: Design Closure

Tuning the Compilation Flow

The default compilation flow provides a quick way to obtain a baseline of the design and start
analyzing the design if timing is not met. After initial implementation, tuning the compilation flow
might be required to achieve timing closure.

Using Strategies and Directives

You can use strategies and directives to find the optimal solution for your design. Strategies are
applied globally to a project implementation run. Directives can be set individually for each step
of the implementation flow in both Project and Non-Project Modes.

ML Strategies

Machine learning (ML) strategies allow you to quickly obtain an optimized strategy for your
design. If you are running multiple implementation strategies to generate implementation results,
you can use ML strategies instead to help you predict which strategies are most likely to
generate a good result.

RECOMMENDED: Xilinx recommends performing three implementation runs with different strategy
suggestions to identify and address errors in the prediction.

You can generate strategy suggestion objects on a routed design by running the
report_qor_suggestions command. Prior to running this command, you must run the
implementation flow as follows:

• In Project Mode, use the Default or PerformanceExplore strategy.

• In Non-Project Mode, use the following Tcl commands:
○ opt_design: Set the -directive option to Default or Explore.

○ place_design, phys_opt_design, and route_design: Set the -directive option

to Default or Explore. The option must match across all three Tcl commands.

After generating ML strategy suggestions, you must write the suggestions using
write_qor_suggestions -strategy_dir <directory>. This writes one RQS file per
strategy. To activate strategy objects, an RQS file with the strategy suggestion must be read
using read_qor_suggestions prior to running opt_design, and the directives for all
commands must be set to RQS (for example, opt_design -directive RQS).

Xilinx recommends the following when using ML strategies:

• For best results, resolve all methodology checks, and make sure the design has a QoR
assessment score of three or higher. To verify, run report_qor_assessment after
synth_design or opt_design.
• To further enhance performance, combine ML strategy suggestions with other QoR
suggestions in the same RQS file.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 277
 Chapter 6: Design Closure

Note: ML strategy suggestions are combined automatically when QoR suggestions are written. To
disable this feature, use write_qor_suggestions -of_objects
[get_qor_suggestions ...], and filter only the desired suggestions.

For more information, see this link in the Vivado Design Suite User Guide: Design Analysis and
Closure Techniques (UG906).

Predefined Strategies

Xilinx provides a set of predefined strategies that are tuned to be effective solutions for the
majority of designs.

Note: Xilinx does not recommend running the SSI technology strategies for a non-SSI technology device.

Custom Strategies

If timing cannot be met with the predefined strategies, you can manually explore a custom
combination of directives. Because placement typically has a large impact on overall design
performance, it can be beneficial to try various placer directives with only the I/O location
constraints and with no other placement constraints. By reviewing both WNS and TNS of each
placer run (these values can be found in the placer log), you can select two or three directives
that provide the best timing results as a basis for the downstream implementation flow.

TIP: For a list of directives and a short description of their functions, enter the implementation command
followed by the -help option (for example, place_design -help ). For information on strategies, see
this link in the Vivado Design Suite User Guide: Implementation (UG904).

For each of these checkpoints, several directives for phys_opt_design and route_design
can be tried and again only the runs with the best estimated or final WNS/TNS should be kept. In
Non-Project Mode, you must explicitly describe the flow with a Tcl script and save the best
checkpoints. In Project Mode, you can create individual implementation runs for each placer
directive, and launch the runs up to the placement step. You would continue implementation for
the runs that have the best results after the placer step (as determined by the Tcl-post script).

Physical constraints (Pblocks and DSP and RAM macro constraints) can prevent the placer from
finding the most optimal solution. Xilinx therefore recommends that you run the placer directives
without any Pblock constraints. The following Tcl command can be used to delete any Pblocks
before placement with directives commences:

delete_pblock [get_pblocks *]

Running place_design -directive <directive> and analyzing placement of the best

results can also provide a template for floorplanning the design or reusing the placement of block
RAM macros or DSP macros, which can stabilize the flow from run to run.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 278
 Chapter 6: Design Closure

Using Optimization Iterations

Sometimes it is advantageous to iterate through a command multiple times to obtain the best
results. For example, it might be helpful to first run phys_opt_design with the
force_replication_on_nets option to optimize some critical nets that appear to have an
impact on WNS during route.

Next, run phys_opt_design with any of the directives to improve the overall WNS of the
design.

In Non-Project Mode, use the following commands:

phys_opt_design -force_replication_on_nets [get_nets -hier *phy_reset*]

phys_opt_design -directive <directive name>

In Project Mode, the same results can be achieved by running the first phys_opt_design
command as part of a Tcl-pre script for a phys_opt_design run step which will run using the -
directive option.

Overconstraining the Design

When the design fails timing by a small amount after route, it is usually due to a small timing
margin after placement. It is possible to increase the timing budget for the router by tightening
the timing requirements during placement and physical optimization. To accomplish this, Xilinx
recommends using the set_clock_uncertainty constraint for the following reasons:

• It does not modify the clock relationships (clock waveforms remain unchanged).
• It is additive to the tool-computed clock uncertainty (jitter, phase error).
• It is specific to the clock domain or clock crossing specified by the -from and -to options.
• It can easily be reset by applying a null value to override the previous clock uncertainty
constraint.

In any case, Xilinx recommends that you:

• Overconstrain only the clocks or clock crossing that cannot meet setup timing.
• Use the -setup option to tighten the setup requirement only.
Note: If you do not specify this option, both setup and hold requirements are tightened.

• Reset the extra uncertainty before running the router step.

Overconstraining Example

A design misses timing by -0.2 ns on paths with the clk1 clock domain and on paths from clk2
to clk3 by -0.3 ns before and after route.

1. Load netlist design and apply the normal constraints.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 279
 Chapter 6: Design Closure

2. Apply the additional clock uncertainty to overconstrain certain clocks.

a. The value should be at least the amount of violation.
b. The constraint should be applied only to setup paths.
set_clock_uncertainty -from clk0 -to clk1 0.3 -setup
set_clock_uncertainty -from clk2 -to clk3 0.4 -setup

3. Run the flow up to the router step. It is best if the pre-route timing is met.
4. Remove the extra uncertainty.
set_clock_uncertainty -from clk0 -to clk1 0 -setup
set_clock_uncertainty -from clk2 -to clk3 0 -setup

5. Run the router.

After running the router, you can review the timing results to evaluate the benefits of
overconstraining. If timing was met after placement but still fails by some amount after route,
you can increase the amount of uncertainty and try again.

WARNING! Do not overconstrain beyond 0.5 ns. Overconstraining the design can result in increased
power due to the additional logic replication introduced by the implementation tools as well as increased
compile time.

TIP: An alternative to overconstraining the design is to change the relative priority of each path group. By
default, each clock and user-defined path group is analyzed independently with the same priority during
implementation. You can set a higher priority for any clock-based path group using the group_path -
weight 2 -name <ClockName> options. The priority of user-defined path groups cannot be
changed.

Considering Floorplan
Floorplanning allows you to guide the tools, either through high-level hierarchy layout, or
through detail placement. This can provide improved QoR and more predictable results. You can
achieve the greatest improvements by fixing the worst problems or the most common problems.
For example, if there are outlier paths that have significantly worse slack, or high levels of logic,
fix those paths first by grouping them in a same region of the device through a Pblock. Limit
floorplanning only to portions of design that need additional user intervention, rather than
floorplanning the entire design.

Floorplanning logic that is connected to the I/O to the vicinity of the I/O can sometimes yield
good results in terms of predictability from one compilation to the next. In general, it is best to
keep the size of the Pblocks to a clock region. This provides the most flexibility for the placer.
Avoid overlapping Pblocks, as these shared areas can potentially become more congested.
Where there is a high number of connecting signals between two Pblocks consider merging them
into a single Pblock. Minimize the number of nets that cross Pblocks.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 280
 Chapter 6: Design Closure

TIP: When upgrading to a newer version of the Vivado Design Suite, first try compiling without Pblocks or
with minimal Pblocks (i.e., only SLR level Pblocks) to see if there are any timing closure challenges. Pblocks
that previously helped to improve the QoR might prevent place and route from finding the best possible
implementation in the newer version of the tools.

For SSI technology devices, you can also consider using SLR Pblocks or soft floorplanning
constraints (USER_SLR_ASSIGNMENT).

Related Information

SSI Technology Considerations

Grouping Critical Logic

Grouping critical logic to avoid crossing SLR or I/O columns can help improve the critical path of
a design. The following figure shows two examples of a large FIFO implemented with 29
FIFO36E2 primitives. The critical path is from the WRRSTBUSY pin of every FIFO36E2 in the
group through 5 LUTs to the WREN pin of every FIFO36E2 in the group.

• On the left, the example shows that the placer was unable to find the most optimal placement
of the path, because block RAM utilization was high. FIFO36E2 primitives are marked in red.
• On the right, the example shows that the placer was able to meet timing, because the
FIFO36E2 blocks were grouped in a rectangle that avoided the configuration column crossing.
FIFO36E2 primitives are marked in green.

Figure 151: Locations Avoiding the Configuration Column

Locations Not Avoiding the Configuration Column Preassigned Locations Avoiding the Configuration Column
X18041-120219

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 281
 Chapter 6: Design Closure

Reusing Placement Results

It is fairly easy to reuse the placement of block RAM macros and DSP macros. Reusing this
placement helps to reduce the variability in results from one netlist revision to the next. These
primitives generally have stable names. The placement is usually easy to maintain. Some
placement directives result in better block RAM and DSP macro placement than others. You can
try applying this improved macro placement from one placer run to others using different placer
directives to improve QoR. Following is a simple Tcl script that saves block RAM placement into
an XDC file for UltraScale and UltraScale+ device designs.

set_property IS_LOC_FIXED 1 \
[get_cells -hier -filter {PRIMITIVE_TYPE =~ BLOCKRAM.*.*}]
write_xdc bram_loc.xdc -exclude_timing

You can edit the bram_loc.xdc file to only keep block RAM location constraints and apply it
for your consecutive runs.

IMPORTANT! Do not reuse the placement of general slice logic. Do not reuse the placement for sections
of the design that are likely to change. Use the Incremental Compile flow if you make small changes to the
design and want to re-use prior placement to achieve more predictable results and faster compile time.

Using Incremental Implementation

You can use incremental implementation to reduce implementation compile time and produce
more predictable results. Xilinx recommends making incremental implementation part of your
standard timing closure strategies. For more information, see this link in the Vivado Design Suite
User Guide: Implementation (UG904) and this link in the Vivado Design Suite User Guide: Design
Analysis and Closure Techniques (UG906).

This section covers recommendations for automatic incremental implementation, including both
high and low reuse modes.

Choose a High Quality Reference Checkpoint

Because the incremental implementation flow depends on reuse, the most important input to the
flow is the reference checkpoint. When you use automatic incremental implementation in Project
Mode, the Vivado tools manage the updating of the reference checkpoint. This ensures that
reuse is high and timing is almost closed.

In all other use cases of the incremental implementation flow, you have control over the selection
of the reference checkpoint. Following are guidelines to help improve your selection of the
reference checkpoint:

• Use a reference checkpoint that meets timing or is close to meeting timing. If the reference
checkpoint is close to meeting timing, it might be beneficial to improve timing as follows
before running the incremental implementation flow.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 282
 Chapter 6: Design Closure

Note: For automatic incremental implementation, the checkpoint is rejected unless WNS is less than
-0.250 ns.

○ Run route_design -tns_cleanup to optimize paths that are not the worst case path.

○ Run the post-route phys_opt_design command to improve timing failures. Although

this command might increase run time, these optimizations are replayed quickly in the
incremental implementation run.
○ Use the report_qor_suggestions command to generate suggestions to improve the
design. New suggestions applied in the incremental implementation flow must be
incremental implementation-friendly. Suggestions already applied in the reference
checkpoint do not need to be incremental implementation-friendly. For suggestions that
are not incremental implementation friendly, consider applying the suggestions and
updating the checkpoint using the default flow.
• Select the checkpoint with the lowest congestion, which more readily accommodates changes
than congested checkpoints.
• Maximize matching between reference and incremental checkpoints.
Note: For automatic incremental implementation, the checkpoint is rejected unless cell matching is at
least 94% and net matching is at least 90%.

○ Use incremental synthesis to reduce changes introduced into the netlist due to RTL
changes. Enable incremental synthesis early in the design closure cycle rather than waiting
until you are ready to use incremental implementation.
○ Ensure that synth_design and opt_design options match for the reference checkpoint
and the incremental implementation runs.
○ Match tool versions. Although this is not a requirement, thresholds change and new
optimizations are added, which can lead to reduced matching.
○ Avoid using opt_design AddRemap and ExploreWithRemap directives unless these
are the only directives that close timing. These directives have reduced naming consistency
when changes are introduced to the codebase.
• Use report_qor_assessment to determine whether the design is ready for the
incremental implementation flow to be run and whether it is preferable to switch from the
default flow.

TIP: To adjust the incremental implementation thresholds, run config_implementation -help for
information. To identify differences between the reference and the incremental checkpoints, run
report_incremental_reuse.

Select Incremental Implementation Directives for High Reuse Mode

You can adjust the incremental implementation flow behavior using directives. The tools follow
these directives when the incremental implementation algorithms are used on the
implementation run. When flow reverts to the default algorithms, the tools follow the directives
specified with the place_design, phys_opt_design, and route_design commands.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 283
 Chapter 6: Design Closure

Following are the directives available for use with the incremental implementation flow:

• RuntimeOptimized: Targets the WNS from the reference checkpoint. This helps maintain
consistency with the reference checkpoint and improves placer and router run time by at least
2x. If the reference checkpoint does not close timing, this directive does not attempt to close
timing. This directive is the default.

• TimingClosure: Targets WNS = 0.000 ns. Use this directive when the reference run is very
close to meeting timing, and you are willing to trade off consistency in results and run time
with more effort to try to meet timing. This mode can improve WNS by up to 250 ps on
difficult designs. Use this directive with QoR Suggestions for the best chance at closing timing.
There is usually a run time hit with this directive.

• Quick: This option is intended for designs that easily meet timing with greater than 99%
reuse. Typically, this option is used for ASIC emulation and prototype designs with minor
changes that do not impact timing.

Following is an example command for Project Mode:

set_property -name INCREMENTAL_CHECKPOINT.MORE_OPTIONS -value {-directive

TimingClosure} -object [get_runs <runName>]

Following is an example command for Non-Project Mode:

read_checkpoint -incremental -directive TimingClosure <reference>.dcp

Note: The RuntimeOptimized directive replaces the Default mapping directive, and the
TimingClosure directive replaces the Explore mapping directive from previous Vivado Design Suite
releases.

Reduce QoR Variability for Low Reuse Mode

In low reuse mode, you can reuse particular cells (for example, a hierarchical cell in the design) or
cell types (for example, DSPs or block RAMs). This can be effective when both of the following
are true:

• Some design runs are showing that a design can meet timing but many runs do not.
• It is early in the design flow or significant changes are still being made.

Reusing hierarchical cells is effective when placement of a particular cell is influencing the WNS
significantly. Reusing DSPs, block RAMs, or both is useful in designs that have a relatively high
density of these blocks.

To reuse particular cell or cell types:

• Analyze the reference runs, including checking failing checkpoints to identify the difference
between good and bad runs.
○ Identify runs that have a good WNS and low congestion levels.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 284
 Chapter 6: Design Closure

○ Use floorplanning to define SLR placement.

• After determining the area to target, compare a set of runs using low reuse mode against a
baseline set of runs using the default flow to evaluate effectiveness.
○ Use different place_design directives to generate multiple results for comparison.

Note: In low reuse mode, incremental implementation directives are ignored, and target WNS is always
0.000 ns.

To reuse only block memory placement, use the following Tcl script:

read_checkpoint -incremental routed.dcp \

-reuse_objects [all_rams] -fix_objects [all_rams]

To reuse only DSP placement, use the following Tcl script:

read_checkpoint -incremental routed.dcp \

-reuse_objects [all_dsps] -fix_objects [all_dsps]

To reuse both Block Memory and DSP placement, use the following Tcl script:

read_checkpoint -incremental routed.dcp \

-reuse_objects [all_rams] -reuse_objects [all_dsps] -fix_objects
[current_design]

To reuse hierarchy in a particular hierarchical cell and all hierarchies below the cell, use the
following Tcl script:

read_checkpoint -incremental routed.dcp \

-only_reuse [get_cells <cell_name>] -fix_objects [get_cells <cell_name>]

RECOMMENDED: When reusing a hierarchical module, Xilinx recommends using out-of-context

synthesis or incremental synthesis with a PRESERVE_BOUNDARY constraint to ensure cell matching is
100%.

Avoid Floorplanning and Overconstraining

When using the incremental implementation flow, avoid the following:

• Do not floorplan incremental implementation runs.

Pblock placement is overridden by reference checkpoint placement.
• Do not overconstrain the placer.
Overconstraining the design in the incremental implementation run can severely impact reuse,
because the tools try to meet a target WNS that is artificially altered.

Related Information

Overconstraining the Design

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 285
 Chapter 6: Design Closure

XPIO-PL Interface Techniques for Timing

Boundary logic interface flip-flops exist in hardware between the XPIO-programmable logic (PL)
interface, which you can use to improve timing. Dedicated blocks in the XPIO such as the XPHY
Logic, I/O Logic, and clock-modifying blocks have boundary logic interface flip-flops. You can
apply boundary logic interface (BLI) constraints to flip-flops in your design to automatically take
advantage of this hardware feature during design placement. In this example, the data paths to
and from the I/O Logic cells ODDRE1 and IDDRE1 in the XPIO are taking advantage of the BLI
FFs.

set_property BLI TRUE [get_cells {oddr_D1_BLI_reg oddr_D2_BLI_reg}]

set_property BLI TRUE [get_cells {iddr_Q1_BLI_reg iddr_Q2_BLI_reg}]]

The following figure shows the resulting placement and connectivity from setting the BLI
property to TRUE.

Figure 152: Placement of XPIO-PL Interface BLI Flip-Flops for ODDRE1 and IDDRE1

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 286
 Chapter 6: Design Closure

SSI Technology Considerations

Stacked silicon interconnect (SSI) technology devices consist of multiple super logic regions
(SLRs), joined by an interposer. The interposer connections are called super long lines (SLLs).
There is some delay penalty when crossing from one SLR to another. To minimize the impact of
the SLL delay on your design, floorplan the design so that SLR crossings are not part of the
critical path. Minimizing SLR crossings through floorplanning by keeping a challenging module
within one SLR only can also improve timing and routability of the design targeting SSI
technology devices.

Using Hard SLR Floorplan Constraints

For high-performance designs, sufficient pipelining between the major hierarchies is required to
ease global placement and SLR partitioning. When a design is challenging, SLR crossing points
can change from run to run. In addition to defining SLR Pblocks, you can create additional
Pblocks that are aligned to clock regions and located along the SLR boundary to constrain the
crossing flip-flops. The following example shows an UltraScale ku115 SSI device with the
following Pblocks:

• 2 SLR Pblocks: SLR0 and SLR1

• 2 SLR-crossing Pblocks: SLR0_top_row and SLR1_bottom_row

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 287
 Chapter 6: Design Closure

Figure 153: SLR-Crossing Pblock Example

Pblocks
dedicated to
SLR crossing
flip-flops

X18184-110716

IMPORTANT! Xilinx recommends using CLOCKREGION ranges instead of LAGUNA ranges for SLR-
crossing Pblocks.

TIP: You can define SLR Pblocks by specifying a complete SLR. For example, resize_pblock
pblock_SLR0 -add SLR0.

For more information, see this link in Vivado Design Suite User Guide: Design Analysis and Closure
Techniques (UG906).

VIDEO: For information on using floorplanning techniques to address design performance issues, see the
Vivado Design Suite QuickTake Video: Design Analysis and Floorplanning.

Using Soft SLR Floorplan Constraints

For large designs, logic for most of the major blocks fits in one SLR as expected and closes timing
after a few design iterations. However, small portions of the logic, especially the connectivity
across major blocks and across SLRs, is subject to QoR variation depending on the overall design
placement. In such cases, the placer and physical optimization algorithms need additional
flexibility to replicate or move some of the logic to a different SLR to address placement
challenges and close timing.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 288
 Chapter 6: Design Closure

You can use the USER_SLR_ASSIGNMENT property to floorplan the design by assigning large
design blocks to SLRs. Set this property to a string value, which is applied to hierarchical cells and
ignored on leaf cells. The value you set for this property influences the logic partitioning as
follows:

• SLR name: When a hierarchical cell is assigned the name of an SLR (SLR0, SLR1, SLR2, etc.),
the placer attempts to place the entire cell within the specified SLR.

• String value: When a hierarchical cell is assigned an arbitrary string value, the placer chooses
the SLR. This prevents cells from being partitioned into multiple SLRs.

Note: If multiple cells have the same USER_SLR_ASSIGNMENT value, the placer attempts to group the
cells in the same SLR.

The USER_SLR_ASSIGNMENT property is a soft constraint during SLR partitioning while the
Pblock is always a hard constraint during SLR partitioning and global placement. Unlike Pblocks,
the USER_SLR_ASSIGNMENT can be ignored by the placer to find a valid SLR partitioning of the
design. Both USER_SLR_ASSIGNMENT and Pblocks allow the detailed placer and physical
optimization to make fine-tuned adjustments to leaf cell placement near the SLR boundaries to
improve timing. These adjustments include moving pipeline registers across SLR boundaries if the
moves improve timing. These register moves are not permitted across Pblock boundaries.

In the following example, a design contains three timing-critical hierarchical blocks with cell
names IP1, IP2, and IP3 and targets a two-SLR device. To split the three blocks so that IP1 and
IP2 are kept together in SLR1 while IP3 is placed in SLR0, the following XDC constraints are
applied:

set_property USER_SLR_ASSIGNMENT SLR1 [get_cells {IP1 IP2}]

set_property USER_SLR_ASSIGNMENT SLR0 [get_cells IP3]

The following figure shows the resulting placement. To improve performance, you can
incorporate extra pipeline stages to traverse distances within the device. This is particularly
helpful along expected SLR crossings, between IP2 and IP3 in this example. During detail
placement and phys_opt_design, the pipeline registers from IP2 and IP3 can automatically
move across SLR boundaries if this improves timing.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 289
 Chapter 6: Design Closure

Figure 154: Placement Example for the USER_SLR_ASSIGNMENT Property

SLR1

IP1

Add pipeline
IP2 registers for
placement
flexibility

SLR0 IP3

X21199-121919

For cases in which you cannot set USER_SLR_ASSIGNMENT or the placer splits challenging
paths across SLRs, you can use the USER_CROSSING_SLR property to direct where SLR
crossings should or should not occur. Typically, you apply this property to nets or leaf pins where
you want pins to be placed in the same SLR as the net driver, or where you want the SLR crossing
for the case of a register chain. Set this property to a Boolean value, which is applied to nets and
pins to constrain individual SLR crossings:

• TRUE: Indicates that the target net object should cross an SLR or the target pin object should
be connected across an SLR. You can only apply the TRUE value to register-to-register
connections with a single fanout in between.

Note: You cannot use the TRUE value for random logic. This option is useful for ensuring a chain of
registers always crosses a SLR boundary on a specific register when trying multiple implementation
strategies.

• FALSE: Indicates that the target net object should not cross an SLR or the target pin object
should not be connected across an SLR. You can apply the FALSE value to any net or pin.

Note: Pins must not be inside macro primitives, because these pins are internal and cannot be constrained.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 290
 Chapter 6: Design Closure

In the following example, a pipeline register chain crosses an SLR twice, resulting in an
unintentional, inefficient zigzag path.

Note: In the next two figures, each dot represents a register stage.

Figure 155: Suboptimal SLR Crossings Before Setting the USER_CROSSING_SLR

Property

SLR
Boundary
net_A net_B

X21198-121919

To achieve the optimal placement in which only net_B crosses the SLR, the following XDC
constraints are applied:

set_property USER_CROSSING_SLR FALSE [get_pins -leaf -of [get_nets net_A]]

set_property USER_CROSSING_SLR TRUE [get_pins -leaf -of [get_nets net_B]]

The resulting placement contains just a single SLR crossing on net_B as shown in the following
figure.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 291
 Chapter 6: Design Closure

Figure 156: Optimal SLR Crossings After Setting the USER_CROSSING_SLR Property

net_A

net_B

X21197-121919

Using SLR Crossing Registers

When targeting UltraScale+ SSI technology devices, you can map a register-to-register SLR
crossing to a Laguna TX_REG driving a Laguna RX_REG directly. This type of connection is only
possible in the UltraScale+ device family, where the Vivado router can fix hold time violations by
setting local programmable clock delays. Using the TX_REG to RX_REG SLR crossing topology for
pipeline register crossings offers the following performance advantages:

• The placement of SLR crossings spreads vertically, reducing routing congestion near SLR
boundaries.
• Locating registers in Laguna sites improves delay estimation accuracy, resulting in higher
timing QoR.
• SLR-crossing performance becomes faster and more consistent.

Note: When targeting UltraScale SSI technology devices, you can only use a Laguna TX_REG or RX_REG on
a SLR crossing net, and you cannot use both at the same time. Performance advantages are similar to the
ones listed above.

You can set the USER_SLL_REG property on registers that you expect to be placed at an SLR
crossing boundary on a Laguna register site. The USER_SLL_REG constraint is ignored by
place_design if the register D and Q pins are connected to a net that either does not cross an
SLR boundary or drives loads placed in multiple SLRs. For example:

set_property USER_SLL_REG TRUE [get_cells {reg_A reg_B}]

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 292
 Chapter 6: Design Closure

A reliable method of mapping registered crossings to Laguna is to apply both BEL and LOC
constraints to the registers to lock them in place. The LOC value assigns the Laguna site, and the
BEL value chooses a particular Laguna register inside the site, one of six TX_REG registers or one
of six RX_REG registers. Laguna crossing registers are a fixed distance apart, which means that
each TX_REG register is paired with an RX_REG register for a direct connection.

In the following example, a register-to-register connection is manually placed onto a TX_REG to

RX_REG connection. Pipeline register reg_A drives a single fanout with the single load of register
reg_B. For a VU9P target device, the following XDC constraints are applied so that reg_A in SLR2
drives reg_B in SLR1 using a direct TX_REG to RX_REG connection:

set_property BEL TX_REG3 [get_cells reg_A]

set_property BEL RX_REG3 [get_cells reg_B]
set_property LOC LAGUNA_X2Y480 [get_cells reg_A]
set_property LOC LAGUNA_X2Y360 [get_cells reg_B]

The BEL assignments are applied first, and the register position (0, 1, ... 5) must match between
TX_REG and RX_REG, which is 3 for this example. Finally, the distance between paired Laguna
sites is 120 rows. The register reg_A drives from the bottom row of the SLR2 Laguna column
across to the bottom row of the SLR1 Laguna column. When creating LAGUNA BEL and LOC
constraints, try grouping registers with same clock, clock enable and reset signals to avoid control
set compatibility issues.

Using Auto-Pipelining for SLR Crossings

Whether you use soft SLR floorplan constraints, hard SLR floorplan constraints, or no floorplan
constraints, the number of pipeline stages required to meet timing between major portions of the
design located in different SLRs varies based on the following:

• Target frequency
• Device floorplan
• Device speed grade

You can leverage the auto-pipelining feature to allow the placer algorithms to decide on the
number of required stages and their optimal location, which helps timing closure across SLR
boundaries. When using this feature, the Vivado placer automatically uses Laguna registers
without additional intervention.

You can enable auto-pipelining by setting AUTOPIPELINING_* attributes on buses and

handshake logic in your RTL, but make sure that the additional latency does not adversely affect
the design functionality. Alternatively, you can use the Xilinx AXI Register Slice Memory Mapped
or Streaming IP, configured in the SLR crossing.

Related Information

Auto-Pipelining Considerations

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 293
 Chapter 6: Design Closure

Using Intelligent Design Runs

To automatically address most timing closure challenges during implementation, you can use an
Intelligent Design Run (IDR). An IDR is a special type of implementation run that leverages
report_qor_suggestions, ML-based strategy predictions, and incremental compile. An IDR
can run up to six iterations of place and route, which leads to a typical compile time of 3.5 times
that of a standard run. However, using IDR can provide significant benefits by reducing the
knowledge required to close timing and by saving hours of user analysis.

RECOMMENDED: Because an IDR takes longer than a standard implementation run, Xilinx recommends
using IDRs less frequently than standard runs. For example, use an IDR after you resolve all methodology
warnings and after trying a few common implementation strategies, such as Default and Explore.

TIP: To iterate more quickly, you can extract the QoR suggestions and ML strategies from the IDR for use
in a standard implementation run. If a significant design change is made, rerun the IDR to update the
associated files.

An IDR comprises the following stages:

1. Uses report_qor_suggestions to apply optimization properties to elements in the

design in a predetermined order.
2. Uses machine learning (ML) strategies to generate tool options for opt_design,
place_design, phys_opt_design, and route_design that are optimized for the
design.
3. Uses a Last Mile Timing Closure feature to apply extensive effort on paths that are difficult to
resolve to get the final result.

To ensure success when using IDR, follow these requirements:

• The implementation must be project based. For non-project users, the easiest method is to
create a post-synthesis netlist-based project using a pre-opt_design checkpoint.
• The device must be from either an UltraScale or UltraScale+™- device-based family.
• The design must have a baseline with accurate and achievable constraints.
• All designs must comply with the recommended methodology, as reported by the
report_methodology Tcl command.
• An SLR-based floorplan might be required for SSI technology-based devices.
• Apply only automatic implementation suggestions. Text-based suggestions or suggestions
with APPLICABLE_FOR = synth_design must be applied before starting an IDR.

For more information see this link in the Vivado Design Suite User Guide: Design Analysis and
Closure Techniques (UG906).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 294
 Chapter 6: Design Closure

Power Closure
Given the importance of power, the Vivado tools support methods for obtaining an accurate
estimate for power, as well as providing some power optimization capabilities. For additional
information, see the Vivado Design Suite User Guide: Power Analysis and Optimization (UG907).

RECOMMENDED: When targeting UltraScale and UltraScale+™ devices and using the Explore directives
or Explore-based strategies, you must manually enable block RAM power optimization by running
power_opt_design or using opt_design -bram_power_opt after opt_design runs. Xilinx
recommends minimizing memory resources to reduce power. Review the bit utilization from the RAM
Utilization Report to find memory arrays with inefficient mapping. Also consider using the HDL
RAM_STYLE MIXED attribute for the most efficient mapping of arrays using a combination of block
memory and LUTRAMs.

Estimating Power Throughout the Flow

As your design flow progresses through synthesis and implementation, you must regularly
monitor and verify the power consumption to be sure that thermal dissipation remains within
budget, that the board voltage regulators remain within their current operating limits and the
design stays within any system power limits. You can then take prompt remedial actions if the
power approaches your budget too closely.

Specify a power budget to report the power margin using the XDC constraint:

set_operating_conditions -design_power_budget <value in watts>

This value is used by the report_power command. The difference between the calculated on-
chip power and the power budget is the power margin, which is displayed in red in the Vivado
IDE if the power budget is exceeded. This makes it easier to monitor power consumption
throughout the flow.

TIP: For UltraScale+ devices, you can export an XDC file from the XPE tool that contains the environment
settings, including the XPE estimate that can be used as a power budget constraint. You can override the
power budget using either XPE or the XDC. Add the XDC constraints for power margin reporting.

The accuracy of the power estimates varies depending on the design stage when the power is
estimated. To estimate power post-synthesis through implementation, run the report_power
command, or open the Power Report in the Vivado IDE.

• Post Synthesis: The netlist is mapped to the actual resources available in the target device.

• Post Placement: The netlist components are placed into the actual device resources. With this
packing information, the final logic resource count and configuration becomes available. This
accurate data can be exported to the XPE spreadsheet. This allows you to:

• Perform what-if analysis in XPE.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 295
 Chapter 6: Design Closure

• Provide the basis for accurately filling in the spreadsheet for future designs with similar
characteristics.

• Post Routing: After routing is complete all the details about routing resources used and exact
timing information for each path in the design are defined.

In addition to verifying the implemented circuit functionality under best and worst case logic and
routing delays, the simulator can also report the exact activity of internal nodes and include
glitching. Power analysis at this level provides the most accurate power estimation before you
actually measure power on your prototype board.

Using the Power Constraints Advisor

The Power Constraint Advisor reports the tool-computed switching activity on all control signals
in the design and is sorted starting with highest fanout. Review this list for Low confidence levels,
which indicate resets with high switching activity and enables with very low or zero switching
activity. Both factors contribute to erroneously optimistic power results. For more information,
see Power Constraints Advisor in the Vivado Design Suite User Guide: Power Analysis and
Optimization (UG907).

Recommended Power Constraints

Applying the correct power constraints to a design is critical to design closure. The Vivado tools
report power command reports the power margin based on the budget applied as well as
additional constraints. Following is a list of the minimum recommended constraints. For more
information, see the Vivado Design Suite User Guide: Power Analysis and Optimization (UG907).

Minimum Recommended Constraints

The following constraints ensure that the power estimation checks the power budget and uses
the worst-case maximum process for static power analysis:

set_operating_conditions -design_power_budget <Power in Watts>

set_operating_conditions -process maximum

Additional Recommended Constraints

The following constraints define the thermal solution and allow the report_power command to
estimate the junction temperature and therefore, the static power more accurately:

set_operating_conditions -ambient_temp <max Ambient requested for

application is Celsius>
set_operating_conditions -thetaja <the rise in junction temperature for
every watt dissipated, obtained from thermal simulation, C/W>

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 296
 Chapter 6: Design Closure

The Vivado tools report_power command also allows you to report power on a on a per
regulator or voltage regulator module (VRM) basis using the following constraints.

Creating a New Power Rail

create_power_rail <power rail name> -power_sources {supply1, supply2 ,..}

Adding Power Sources to an Existing Power Rail

add_to_power_rail <power rail name> -power_sources {supply1, supply2, ..}

Defining Current Budget

set_operating_conditions -supply_current_budget {<supply rail name>

<current budget in Amp>} -voltage {<supply rail name> <voltage>}

Best Practices for Accurate Power Analysis

For accurate power analysis, make sure you have accurate timing constraints, I/O constraints,
and switching activity. The report_power command indicates a confidence level, as shown in
the following figure. Target a High confidence level to ensure accurate power analysis. For more
information, see this link in the Vivado Design Suite User Guide: Power Analysis and Optimization
(UG907).

Figure 157: Power Analysis Confidence Level

Low: Medium: High:

· Unrouted design · Unrouted design · Routed design
· No power constraints · Some power constraints · Good power constraints

X25127-021621

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 297
 Chapter 6: Design Closure

Reviewing the Design Power Distribution After

Running Power Analysis
You can review the total on-chip power and thermal properties as well as details of the power at
the resource level to determine which parts of your design contribute most to the total power.
For more information, see this link in the Vivado Design Suite User Guide: Power Analysis and
Optimization (UG907).

POWER TIP: Review and validate the decoupling requirement of the completed Vivado design against the
current schematic/PCB. You can generate a .xpe file from Vivado tools report_power using the
following Tcl commands:

set_operating_conditions -process maximum

set_operating_conditions -ambient_temp <max Ambient requested for

application is Celsius>

set_operating_conditions -thetaja <the rise in junction temperature for

every watt dissipated, obtained from thermal simulation, C/W>

report_power -xpe {C:/Design_Runs/Vivado_export.xpe} -name {Any_Name}

You can then import the .xpe file into XPE. For example, the XPE Power Delivery sheet shows the
decoupling requirement based on the power estimation and power delivery option.

Further Refining Control Signal Activity After

Running Power Analysis
When SAIF-based annotation has not been used for accurate power analysis, you can fine-tune
the power analysis after doing the first level analysis. For more information, see this link in the
Vivado Design Suite User Guide: Power Analysis and Optimization (UG907).

Power Optimization
If the power estimates are outside the budget, you must follow the steps described in the
following sections to reduce power.

Analyzing Your Power Estimation and Optimization Results

Once you have generated the power estimation report using report_power, Xilinx
recommends the following:

• Examine the total power in the Summary section. Does the total power and junction
temperature fit into your thermal and power budget?

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 298
 Chapter 6: Design Closure

• If the results are substantially over budget, review the power summary distribution by block
type and by the power rails. This provides an idea of the highest power consuming blocks.
• Review the Hierarchy section. The breakdown by hierarchy provides a good idea of the
highest power consuming module. You can drill down into a specific module to determine the
functionality of the block. You can also cross-probe in the GUI to determine how specific
sections of the module have been coded, and whether there are power efficient ways to
recode it.
Note: If the design has a timing margin, conduct multiple runs to evaluate if any of the runs have a
better total power. For example, a design that has 2 ps of margin can perform similarly to a design with
15 ps, but the 2 ps design might have lower power.

Running Power Optimization

Power optimization works on the entire design or on portions of the design (when
set_power_opt is used) to minimize power consumption.

Power optimization can be run either pre-place or post-place in the design flow, but not both.
The pre-place power optimization step focuses on maximizing power saving. This can result (in
rare cases) in timing degradation. If preserving timing is the primary goal, Xilinx recommends the
post-place power optimization step. This step performs only those power optimizations that
preserve timing.

In cases where portions of the design should be preserved due to legacy (IP) or timing
considerations, use the set_power_opt command to exclude those portions (such as specific
hierarchies, clock domains, or cell types) and rerun power optimization.

Related Information

Coding Styles to Improve Power

Using the Power Optimization Report

To determine the impact of power optimizations, run the following command in the Tcl Console
to generate a power optimization report:

report_power_opt -file myopt.rep

Using the Timing Report to Determine the Impact of Power

Optimization
Power optimization works to minimize the impact on timing while maximizing power savings.
However, in certain cases, if timing degrades after power optimization, you can employ a few
techniques to offset this impact.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 299
 Chapter 6: Design Closure

Where possible, identify and apply power optimizations only on non-timing critical clock
domains or modules using the set_power_opt XDC command. If the most critical clock domain
happens to cover a large portion of the design or consumes the most power, review critical paths
to see if any cells in the critical path have the IS_CLOCK_GATED property with value TRUE,
indicating that the paths are the result of a power optimization. To improve timing at the expense
of increased power in a subsequent implementation, use the set_power_opt XDC constraint
to disable power optimization on the power-optimized cells in the critical path. Then rerun
implementation with the set_power_opt XDC constraints or Tcl commands.

The following Tcl example disables power optimization on cells in the top 100 failing paths:

set pwr_critical_cells [get_cells -of [get_timing_paths -slack_lesser_than

0 -max_paths 100] -filter {IS_CLOCK_GATED}]
set_power_opt -exclude_cells $pwr_critical_cells

Power Timing Slack

When closing a design for timing, it is more efficient and effective to simultaneously close the
design from a power perspective. This approach allows for the best run selection that satisfies
both criteria. To close both timing and power, add the report_power constraint to the script
you are running. For more information and an example script, see Answer Record 76056.

The following figure shows an example of this approach. For all 64 timing closure runs, report
power was also run, and all runs are plotted together. From the graph, 36 runs were timing clean,
and from a power perspective, the total power budget is 77W. The 64 runs were in the range of
75W to 83W, an 8W or ~10% range.

Looking at the best run from a timing perspective, run #6 had a power estimate of 79.5W, which
exceeds the total power budget. However, from the timing clean runs, run #13 yielded the lowest
power at 75W and was still timing clean. Understanding the design from both a timing and
power perspective allows you to select the best run for both, without impacting the timing result.
In this example, this approach enabled a 4W power saving.

POWER TIP: You can also improve design power by removing the DONT_TOUCH constraint to allow
upfront logic trimming, including clocking primitives.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 300
 Chapter 6: Design Closure

Figure 158: Power and Timing Slack for Different Place and Route Runs

Best Run: Lowest Power:

Power Budget Exceeded Still Timing Clean
X25400-060421

Configuration and Debug

After successfully completing the design implementation, the next step is to load the design into
the device and run it on hardware. Configuration is the process of loading application-specific
data into the internal memory of the device. Debug is required if the design does not meet
expectations on the hardware.

See the following resources for details on configuration and debug software flows and
commands:

• Vivado Design Suite User Guide: Programming and Debugging (UG908)

• Vivado Design Suite Tcl Command Reference Guide (UG835)
• 7 Series FPGAs Configuration User Guide (UG470)
• UltraScale Architecture Configuration User Guide (UG570)
• Vivado Design Suite QuickTake Video: How To Use the "write_bitstream" Command in Vivado

Configuration
You must first successfully synthesize and implement your design to create a bitstream image.
Once the bitstream has been generated and all DRCs are analyzed and corrected, you can load
bitstream onto the device using one of the following methods:

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 301
 Chapter 6: Design Closure

• Direct Programming :

The bitstream is loaded directly to the device using a cable, processor, or custom solution.

• Indirect Programming: The bitstream is loaded into an external flash memory. The flash
memory then loads the bitstream into the device.

You can use the Vivado tools to accomplish the following:

• Create the bitstream (.bit or .rbt).

• Select Tools → Edit Device to review the configuration settings for bitstream generation.
• Format the bitstream into flash programming files (.mcs).
• Program the device using either of the following methods:
○ Directly program the device.

○ Indirectly program the attached configuration flash device.

Flash devices are non-volatile devices and must be erased before programming. Unless a
full chip erase is specified, only the address range covered by the assigned MCS is erased.

IMPORTANT! The Vivado Design Suite Device Programmer can use JTAG to read the Status register
data on Xilinx devices. In case of a configuration failure, the Status register captures the specific error
conditions that can help identify the cause of a failure. In addition, the Status register allows you to
verify the Mode pin settings M[2:0] and the bus width detect. For details on the Status register, see the
Configuration User Guide for your device.

TIP: If configuration is not successful, you can use a JTAG readback/verify operation on the device to
determine whether the intended configuration data was loaded correctly into the device.

Debugging
In-system debugging allows you to debug your design in real time on your target device. This
step is needed if you encounter situations that are extremely difficult to replicate in a simulator.

For debug, you provide your design with special debugging IP that allows you to observe and
control the design. After debugging, you can remove the instrumentation or special IP to increase
performance and logic reduction.

Debugging a design is a multistep, iterative process. Like most complex problems, it is best to
break the design debugging process down into smaller parts by focusing on getting smaller
sections of the design working one at a time rather than trying to get the whole design to work
at once.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 302
 Chapter 6: Design Closure

Though the actual debugging step comes after you have successfully implemented your design,
Xilinx recommends planning how and where to debug early in the design cycle. You can run all
necessary commands to perform programming of the devices and in-system debugging of the
design from the Program and Debug section of the Flow Navigator in the Vivado IDE.

Following are the debug steps:

1. Probing: Identify the signals in your design that you want to probe and how you want to
probe them.
2. Implementing: Implement the design that includes the additional debug IP attached to the
probed nets.
3. Analyzing: Interact with the debug IP contained in the design to debug and verify functional
issues.
4. Fixing phase: Fix any bugs and repeat as necessary.

For more information, see the Vivado Design Suite User Guide: Programming and Debugging
(UG908).

Debugging the PL
Debugging the programmable logic (PL) can be necessary if you encounter situations that are
difficult to replicate in PL logic simulation. This section covers the debugging tools that allow
visibility into the PL domain.

Using ILA Cores

The Integrated Logic Analyzer (ILA) core allows you to perform in-system debugging of post-
implementation designs on a device. Use this core when you need to monitor signals in the
design. You can also use this feature to trigger on hardware events and capture data at system
speeds.

Probing the Design

The Vivado tools provide several methods to add debug probes in your design. The table below
explains the various methods, including the pros and cons of each method.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 303
 Chapter 6: Design Closure

Table 18: Debugging Flows

Debugging Flow Name Flow Steps Pros/Cons

HDL instantiation probing flow Explicitly attach signals in the HDL source • You have to add/remove debug nets
or IP-Integrator canvas to an ILA debug and IP from your design manually,
core instance. which means that you will have to
modify your HDL source.
• This method provides the option to
probe at the HDL design level.
• Allows for probing certain protocols
such as AXI or AXI4-Stream at the
interface level
• It is easy to make mistakes when
generating, instantiating, and
connecting debug cores.
Netlist insertion probing flow Use one of the following two methods to • This method is the most flexible with
identify the signal for debug: good predictability.
• Use the MARK_DEBUG attribute to • This method allows probing at
mark signals for debug in the source different design levels (HDL,
RTL code. synthesized design, system design).
• Use the MARK_DEBUG right-click menu • This method does not require HDL
option to select nets for debugging in source modification.
the synthesized design netlist.
Once the signal is marked for debug, use
the Set up Debug wizard to guide you
through the Netlist Insertion probing flow.
Tcl-based netlist insertion Use the set_property Tcl command to • This method provides fully automatic
probing flow set the MARK_DEBUG property on debug netlist insertion.
nets then use netlist insertion probing Tcl
commands to create debug cores and • You can turn debugging on or off by
connect them to debug nets. modifying the Tcl commands.
• This method does not require HDL
source modification.

Related Information

Modifying the Implemented Netlist to Replace Existing Debug Probes

Choosing Debug Nets

Xilinx makes the following recommendations for choosing debug nets:

• Probe nets at the boundaries (inputs or outputs) of a specific hierarchy. This method helps
isolate problem areas quickly. Subsequently, you can probe further in the hierarchy if needed.
• Do not probe nets in between combinatorial logic paths. If you add MARK_DEBUG on nets in
the middle of a combinatorial logic path, none of the optimizations applicable at the
implementation stage of the flow are applied, resulting in sub-par timing QoR results.
• Probe nets that are synchronous to get cycle accurate data capture.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 304
 Chapter 6: Design Closure

Retaining Names of Debug Probe Nets Using MARK_DEBUG

You can mark a signal for debug either at the RTL stage or post-synthesis. The presence of the
MARK_DEBUG attribute on the nets ensures that the nets are not replicated, retimed, removed,
or otherwise optimized. You can apply the MARK_DEBUG attribute on top level ports, nets,
hierarchical module ports and nets internal to hierarchical modules. This method is most likely to
preserve HDL signal names post synthesis. Nets marked for debugging are shown in the
Unassigned Debug Nets folder in the Debug window post synthesis.

Add the mark_debug attribute to HDL files as follows:

VHDL:

attribute mark_debug : string;

attribute keep : string;
attribute mark_debug of sine : signal is "true";

Verilog:

(* mark_debug = "true" *) wire sine;

You can also add nets for debugging in the post-synthesis netlist. These methods do not require
HDL source modification. However, there may be situations where synthesis might not have
preserved the original RTL signals due to netlist optimization involving absorption or merging of
design structures. Post-synthesis, you can add nets for debugging in any of the following ways:

• Select a net in any of the design views (such as the Netlist or Schematic window), then right-
click and select Mark Debug.
• Select a net in any of the design views, then drag and drop the net into the Unassigned Debug
Nets folder.
• Use the net selector in the Set Up Debug wizard.
• Set the MARK_DEBUG property using the Properties window or the Tcl Console.
set_property mark_debug true [get_nets -hier [list {sine[*]}]]

This applies the mark_debug property on the current, open netlist. This method is flexible,
because you can turn MARK_DEBUG on and off through the Tcl command.

ILA Core and Timing Considerations

The configuration of the ILA core has an impact in meeting the overall design timing goals. Follow
the recommendations below to minimize the impact on timing:

• Choose probe width judiciously. The bigger the probe width the greater the impact on both
resource utilization and timing.
• Choose ILA core data depth judiciously. The bigger the data depth the greater the impact on
both block RAM resource utilization and timing.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 305
 Chapter 6: Design Closure

• Ensure that the clocks chosen for the ILA cores are free-running clocks. Failure to do so could
result in an inability to communicate with the debug core when the design is loaded onto the
device.
• Ensure that the clock going to the dbg_hub is a free running clock. Failure to do so could
result in an inability to communicate with the debug core when the design is loaded onto the
device. You can use the connect_debug_port Tcl command to connect the clk pin of the
debug hub to a free-running clock.
• Close timing on the design prior to adding the debug cores. Xilinx does not recommend using
the debug cores to debug timing related issues.
• If you still notice that timing has degraded due to adding the ILA debug core and the critical
path is in the dbg_hub, perform the following steps:
1. Open the synthesized design.
2. Find the dbg_hub cell in the netlist.
3. Go to the Properties window of the dbg_hub.
4. Find property C_CLK_INPUT_FREQ_HZ.
5. Set it to frequency (in Hz) of the clock that is connected to the dbg_hub.
6. Find property C_ENABLE_CLK_DIVIDER and enable it.
7. Re-implement design.
• Make sure the clock input to the ILA core is synchronous to the signals being probed. Failure
to do so results in timing issues and communication failures with the debug core when the
design is programmed into the device.
• Make sure that the design meets timing before running it on hardware. Failure to do so results
in unreliable probed waveforms.

The following table shows the impact of using specific ILA features on design timing and
resources.

Note: This table is based on a design with one ILA and does not represent all designs.

Table 19: Impact of ILA Features on Design Timing and Resources

ILA Feature When to Use Timing Area

Capture Control/ To capture relevant data Medium to High Impact • No additional block RAMs
Storage Qualification To make efficient use of data • Slight increase in LUT/FF
capture storage (block RAM) count
Advanced Trigger When BASIC trigger conditions High Impact • No additional block RAMs
are insufficient
• Moderate increase in
To use complex triggering to LUT/FF count
focus in on problem area

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 306
 Chapter 6: Design Closure

Table 19: Impact of ILA Features on Design Timing and Resources (cont'd)

ILA Feature When to Use Timing Area

Number of To use probe in multiple Medium to High Impact • No additional block RAMs
Comparators per conditionals:
Probe Port • Slight to moderate
• 1-2 for Basic increase in LUT/FF count
Note: Maximum is 4. • 1-4 for Advanced
• +1 for Capture Control
Data Depth To capture more data samples High Impact • Additional block RAMs per
ILA core
• Slight increase in LUT/FF
count
ILA Probe Port Width To debug a large bus versus a Medium Impact • Additional block RAMs per
scalar ILA core
• Slight increase in LUT/FF
count
Number of Probes To probe many nets Low Impact • Additional block RAMs per
Ports ILA core
• Slight increase in LUT/FF
count

TIP: In the early stages of the design, there are usually many spare resources in the device that can be used
for debugging.

ILA Core Designs with High-Speed Clocks

For designs with high-speed clocks, consider the following:

• Limit the number and width of signals being debugged.

• Pipeline the input probes to the ILA (C_INPUT_PIPE_STAGES), which enables extra levels of
pipe stages.

Note: For designs with limited MMCM/BUFG availability, consider clocking the debug hub with the lowest
clock frequency in the design instead of using the clock divider inside the debug hub.

Using VIO Cores

The Virtual Input/Output (VIO) core allows you to monitor and drive internal device signals in
real time. Use this core when it is necessary to drive or monitor low speed signals, such as resets
or status signals. The VIO debug core must be instantiated in the design and can be used in both
Vivado IP integrator block design and RTL. The VIO core is available in the IP catalog for RTL-
based designs and in IP integrator.

For information on customizing the VIO core, see the Virtual Input/Output LogiCORE IP Product
Guide (PG159). For information on taking measurements with a VIO core, see this link in the
Vivado Design Suite User Guide: Programming and Debugging (UG908).

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 307
 Chapter 6: Design Closure

VIO Core Considerations

When using VIO cores, consider the following:

• Signals connected to VIO input probes must be synchronous to the clock connected to the
VIO clk port on the VIO core. Connecting signals that are not synchronous to the clk port
results in a clock domain crossing at the VIO input probe port.
• Signals driven from VIO output probes are asserted and deasserted synchronous to the clock
connected to the VIO clk port on the VIO core.
• The VIO core has a relatively low refresh rate because it is intended to replace low speed
board I/O, such as push-buttons or light-emitting diodes (LEDs). To capture high-speed signals,
consider using the ILA core.

Debugging Designs in Vivado IP Integrator

The Vivado IP integrator provides different ways to set up your design for debugging. You can
use one of the following flows to add debug cores to your IP integrator design. The flow you
choose depends on your preference and the types of nets and signals that you want to debug.

• Debug interfaces, nets, or both in the block design using the System ILA core
Use this flow to:
○ Perform hardware-software co-verification using the cross-trigger feature of a MicroBlaze™
device, Zynq®-7000 SoC, or Zynq UltraScale+ MPSoC.
○ Verify the interface-level connectivity.

• Netlist insertion flow

Use this flow to analyze I/O ports and internal nets in the post-synthesized design.

Note: You can also use a combination of both flows to debug your design.

For more information on using System ILA in your IP integrator design, see the Vivado Design
Suite User Guide: Designing IP Subsystems Using IP Integrator (UG994).

Debugging AXI Interfaces in Vivado Hardware Manager

The ILA allows you to perform in-system debugging of post-implemented designs on a Xilinx
device. Use this feature when there is a need to monitor interfaces and signals in the design.

If you changed the ILA mode to Interface, you can debug and monitor AXI transactions and read
and write events in the Waveform window shown in the following figure. The Waveform window
displays the interface slots, transactions, events, and signal groups that correspond to the
interfaces probed by the interface slots on the ILA.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 308
 Chapter 6: Design Closure

Figure 159: Waveform Window

For more information on System ILA and debugging AXI interfaces in the Vivado Hardware
Manager, see this link and this link in the Vivado Design Suite User Guide: Programming and
Debugging (UG908).

Using In-System IBERT

The In-System IBERT core provides RX margin analysis through eye scan plots on the RX data of
transceivers in UltraScale and UltraScale+ devices. The core enables configuration and tuning of
the GTH/GTY transceivers and is accessible through logic that communicates with the dynamic
reconfiguration port (DRP) of the transceivers. You can use the core to change attribute settings
as well as registers that control the values on the rxrate, rxlpmen, txdiffctrl,
txpostcursor, and txprecursor ports.

The Vivado Serial I/O Analyzer in the Hardware Manager communicates with the core through
JTAG when the design is programmed onto the device. There is only one instance of In-System
IBERT required per design. In-System IBERT can work with all GTs used in the design. However,
you must generate separate In-System IBERT cores according to the different GT types (for
example, GTH, GTY).

Creating an In-System IBERT design with an internal system clock can prevent a scan from being
performed. When creating an eye scan, the status changes from In Progress to Incomplete. Eye
scan is incomplete when the internal system clock (MGTREFCLK) is connected to the clk/
drpclk_i input port of In-System IBERT IP.

Note: If needed, consider using an external clock, which does not exhibit this behavior. Alternatively, click
any available link in the Vivado Serial I/O Analyzer. Go to the Properties window, and find the MB_RESET
reg under the LOGIC field. Set it to 1 and then toggle back to 0. Rerun the eye scan or sweep.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 309
 Chapter 6: Design Closure

For more information on this core, see the In-System IBERT LogiCORE IP Product Guide (PG246).

Running Debug-Related DRCs

The Vivado Design Suite provides debug-related DRCs, which are selected as part of the default
rule deck when report_drc is run. The DRCs check for the following:

• Block RAM resources for the device are exceeded because of the current requirements of the
debug core.
• Non-clock net is connected to the clock port on the debug core.
• Port on the debug core is unconnected.

Modifying the Implemented Netlist to Replace Existing Debug Probes

It is possible to replace debug nets connected to an ILA core in a placed and routed design
checkpoint. You can do this by using the Engineering Change Order (ECO) flow. This is an
advanced design flow used for designs that are nearing completion, where you need to swap
nets connected to an existing ILA probe port. For information on using the ECO flow to modify
nets on existing ILA cores, see this link in the Vivado Design Suite User Guide: Implementation
(UG904).

Inserting, Deleting, or Editing ILA Cores on an Implemented Netlist

If you want to add, delete, or modify ILA cores (for example, resizing probe width, changing the
data depth, etc.), Xilinx recommends that you use the Incremental Compile flow. The Incremental
Compile flow for debug cores operates on a synthesized design or checkpoint (DCP) and uses a
reference implemented checkpoint, ideally from a previous implementation run. This approach
might save you time versus a complete re-implementation of the design.

For information on using the Incremental Compile flow to insert, delete, or edit ILA cores, see
this link in the Vivado Design Suite User Guide: Programming and Debugging (UG908).

Connecting a Net to a Free External Pin Using Post-Route ECO

In some cases you might want to bring a net out to a free device pin for debug using external test
equipment. This approach can be useful if you are debugging issues that require minimal changes
to the design QoR or require measurements not possible to obtain through other means. You can
do this by using the Engineering Change Order (ECO) flow as long as the device has an unused
I/O that can be used for this purpose. For more information on using the ECO flow to modify a
routed design, see this link in the Vivado Design Suite User Guide: Implementation (UG904).

Using Remote Debugging

Xilinx provides the following ways to debug or upgrade your design remotely:

• Use the Xilinx Hardware Server product to connect to a remote computer in the lab.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 310
 Appendix A: Additional Resources and Legal Notices

Appendix A

Additional Resources and Legal

Notices

Xilinx Resources
For support resources such as Answers, Documentation, Downloads, and Forums, see Xilinx
Support.

Solution Centers
See the Xilinx Solution Centers for support on devices, tools, and intellectual property at all
stages of the design cycle. Topics include design assistance, advisories, and troubleshooting tips.

Documentation Navigator and Design Hubs

Xilinx® Documentation Navigator (DocNav) provides access to Xilinx documents, videos, and
support resources, which you can filter and search to find information. To open DocNav:

• From the Vivado® IDE, select Help → Documentation and Tutorials.

• On Windows, select Start → All Programs → Xilinx Design Tools → DocNav.
• At the Linux command prompt, enter docnav.

Xilinx Design Hubs provide links to documentation organized by design tasks and other topics,
which you can use to learn key concepts and address frequently asked questions. To access the
Design Hubs:

• In DocNav, click the Design Hubs View tab.

• On the Xilinx website, see the Design Hubs page.

Note: For more information on DocNav, see the Documentation Navigator page on the Xilinx website.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 311
 Appendix A: Additional Resources and Legal Notices

References
These documents provide supplemental material useful with this guide.

1. Vivado® Design Suite Documentation

2. UltraFast Design Methodology Quick Reference Guide (UG1231)
3. UltraFast Design Methodology Timing Closure Quick Reference Guide (UG1292)
4. UltraFast Design Methodology Checklist (XTP301)

Vivado Design Suite User and Reference Guides

1. Xilinx Power Estimator User Guide (UG440)
2. Vivado Design Suite Tcl Command Reference Guide (UG835)
3. Vivado Design Suite User Guide: Design Flows Overview (UG892)
4. Vivado Design Suite User Guide: Using the Vivado IDE (UG893)
5. Vivado Design Suite User Guide: Using Tcl Scripting (UG894)
6. Vivado Design Suite User Guide: System-Level Design Entry (UG895)
7. Vivado Design Suite User Guide: Designing with IP (UG896)
8. Vivado Design Suite User Guide: Embedded Processor Hardware Design (UG898)
9. Vivado Design Suite User Guide: I/O and Clock Planning (UG899)
10. Vivado Design Suite User Guide: Logic Simulation (UG900)
11. Vivado Design Suite User Guide: Synthesis (UG901)
12. Vivado Design Suite User Guide: Using Constraints (UG903)
13. Vivado Design Suite User Guide: Implementation (UG904)
14. Vivado Design Suite User Guide: Hierarchical Design (UG905)
15. Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906)
16. Vivado Design Suite User Guide: Power Analysis and Optimization (UG907)
17. Vivado Design Suite User Guide: Programming and Debugging (UG908)
18. Vivado Design Suite User Guide: Dynamic Function eXchange (UG909)
19. Vivado Design Suite User Guide: Getting Started (UG910)
20. Vivado Design Suite Properties Reference Guide (UG912)
21. a. Vivado Design Suite 7 Series FPGA and Zynq-7000 SoC Libraries Guide (UG953)
b. UltraScale Architecture Libraries Guide (UG974)

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 312
 Appendix A: Additional Resources and Legal Notices

22. Vivado Design Suite User Guide: Release Notes, Installation, and Licensing (UG973)
23. Vivado Design Suite User Guide: Designing IP Subsystems Using IP Integrator (UG994)
24. UltraFast Embedded Design Methodology Guide (UG1046)
25. Vivado Design Suite User Guide: Creating and Packaging Custom IP (UG1118)

Vivado Design Suite Tutorials

1. Vivado Design Suite Tutorial: Design Flows Overview (UG888)
2. Vivado Design Suite Tutorial: Logic Simulation (UG937)
3. Vivado Design Suite Tutorial: Embedded Processor Hardware Design (UG940)
4. Vivado Design Suite Tutorial: Dynamic Function eXchange (UG947)

Other Xilinx Documentation

1. UltraScale Architecture-Based FPGAs Memory IP LogiCORE IP Product Guide (PG150)
2. UltraScale Devices Gen3 Integrated Block for PCI Express LogiCORE IP Product Guide (PG156)
3. Virtual Input/Output LogiCORE IP Product Guide (PG159)
4. In-System IBERT LogiCORE IP Product Guide (PG246)
5. a. 7 Series FPGAs SelectIO Resources User Guide (UG471)
b. UltraScale Architecture SelectIO Resources User Guide (UG571)
6. a. 7 Series FPGAs Clocking Resources User Guide (UG472)
b. UltraScale Architecture Clocking Resources User Guide (UG572)
7. a. 7 Series FPGAs PCB Design Guide (UG483)
b. UltraScale Architecture PCB Design User Guide (UG583)
c. Zynq-7000 SoC PCB Design Guide (UG933)
8. a. UltraScale Architecture GTH Transceivers User Guide (UG576)
b. UltraScale Architecture GTY Transceivers User Guide (UG578)
9. 7 Series FPGAs Memory Resources User Guide (UG473)
10. 7 Series DSP48E1 Slice User Guide (UG479)
11. 7 Series FPGAs and Zynq-7000 SoC XADC Dual 12-Bit 1 MSPS Analog-to-Digital Converter User
Guide (UG480)
12. UltraScale Architecture DSP Slice User Guide (UG579)
13. Zynq-7000 SoC and 7 series Devices Memory Interface Solutions (UG586)
14. Vitis HLS User Guide (UG1399)

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 313
 Appendix A: Additional Resources and Legal Notices

15. Vitis HLS Methodology in the Vitis HLS User Guide (UG1399)
16. Simulating FPGA Power Integrity Using S-Parameter Models (WP411)
17. Extending the Thermal Solution by Utilizing Excursion Temperatures (WP517)
18. Using SPI Flash with 7 Series FPGAs (XAPP586)
19. BPI Fast Configuration and iMPACT Flash Programming with 7 Series FPGAs (XAPP587)
20. Reference System: Kintex-7 MicroBlaze System Simulation Using IP Integrator (XAPP1180)
21. UltraScale FPGA BPI Configuration and Flash Programming (XAPP1220)
22. SPI Configuration and Flash Programming in UltraScale FPGAs (XAPP1233)
23. Using Encryption to Secure a 7 Series FPGA Bitstream (XAPP1239)
24. Mechanical and Thermal Design Guidelines for Lidless Flip-Chip Packages (XAPP1301)
25. Designing Using SelectIO Interface Component Primitives (XAPP1324)
26. a. 7 Series Schematic Review Recommendations (XMP277)
b. Kintex UltraScale and Virtex UltraScale FPGAs Schematic Review Checklist (XTP344)
c. UltraScale+ FPGAs and Zynq Ultrascale+ Devices Schematic Review Checklist (XTP427)

Training Resources
1. UltraFast Design Methodology Training Course
2. Vivado Design Suite QuickTake Video: UltraFast Vivado Design Methodology
3. Vivado Design Suite QuickTake Video: Vivado Design Flows Overview
4. Vivado Design Suite QuickTake Video: Targeting Zynq Using Vivado IP Integrator
5. Vivado Design Suite QuickTake Video: Partial Reconfiguration in Vivado Design Suite
6. Vivado Design Suite QuickTake Video: Creating Different Types of Projects
7. Vivado Design Suite QuickTake Video: Managing Sources With Projects
8. Vivado Design Suite QuickTake Video: Using Vivado Design Suite with Revision Control
9. Vivado Design Suite QuickTake Video: Managing Vivado IP Version Upgrades
10. Vivado Design Suite QuickTake Video: I/O Planning Overview
11. Vivado Design Suite QuickTake Video: Configuring and Managing Reusable IP in Vivado
12. Vivado Design Suite QuickTake Video: How To Use the "write_bitstream" Command in Vivado
13. Vivado Design Suite QuickTake Video: Design Analysis and Floorplanning

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 314
 Appendix A: Additional Resources and Legal Notices

14. Vivado Design Suite QuickTake Video: Introducing the UltraFast Design Methodology
Checklist
15. Vivado Design Suite Video Tutorials

Revision History
The following table shows the revision history for this document.

Section Revision Summary

06/08/2022 Version 2022.1
Power Distribution System Updated Sysmon power supply (VCCAUX_SMON).
PCB Design Considerations Added XDC constraints description to step 7.
Checking for Feedback Structures in Registers Updated example.
Check Inferred Logic Added information on retiming_forward and
retiming_backward.

Using the CLOCK_DEDICATED_ROUTE Constraint Added information on vertically adjacent clock regions.
Assessing Post-Synthesis Quality of Results Updated table.
Methodology DRCs with Impact on Timing Closure Added TIMING-56 check description.
Methodology DRCs with Impact on Signoff Quality and Added TIMING-54 to 57 check descriptions.
Hardware Stability
Overconstraining the Design Added overconstrain warning note.

Please Read: Important Legal Notices

The information disclosed to you hereunder (the "Materials") is provided solely for the selection
and use of Xilinx products. To the maximum extent permitted by applicable law: (1) Materials are
made available "AS IS" and with all faults, Xilinx hereby DISCLAIMS ALL WARRANTIES AND
CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO
WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY
PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort, including
negligence, or under any other theory of liability) for any loss or damage of any kind or nature
related to, arising under, or in connection with, the Materials (including your use of the
Materials), including for any direct, indirect, special, incidental, or consequential loss or damage
(including loss of data, profits, goodwill, or any type of loss or damage suffered as a result of any
action brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinx
had been advised of the possibility of the same. Xilinx assumes no obligation to correct any
errors contained in the Materials or to notify you of updates to the Materials or to product
specifications. You may not reproduce, modify, distribute, or publicly display the Materials
without prior written consent. Certain products are subject to the terms and conditions of

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 315
 Appendix A: Additional Resources and Legal Notices

Xilinx's limited warranty, please refer to Xilinx's Terms of Sale which can be viewed at https://
www.xilinx.com/legal.htm#tos; IP cores may be subject to warranty and support terms contained
in a license issued to you by Xilinx. Xilinx products are not designed or intended to be fail-safe or
for use in any application requiring fail-safe performance; you assume sole risk and liability for
use of Xilinx products in such critical applications, please refer to Xilinx's Terms of Sale which can
be viewed at https://www.xilinx.com/legal.htm#tos.

AUTOMOTIVE APPLICATIONS DISCLAIMER

AUTOMOTIVE PRODUCTS (IDENTIFIED AS "XA" IN THE PART NUMBER) ARE NOT

WARRANTED FOR USE IN THE DEPLOYMENT OF AIRBAGS OR FOR USE IN APPLICATIONS
THAT AFFECT CONTROL OF A VEHICLE ("SAFETY APPLICATION") UNLESS THERE IS A
SAFETY CONCEPT OR REDUNDANCY FEATURE CONSISTENT WITH THE ISO 26262
AUTOMOTIVE SAFETY STANDARD ("SAFETY DESIGN"). CUSTOMER SHALL, PRIOR TO USING
OR DISTRIBUTING ANY SYSTEMS THAT INCORPORATE PRODUCTS, THOROUGHLY TEST
SUCH SYSTEMS FOR SAFETY PURPOSES. USE OF PRODUCTS IN A SAFETY APPLICATION
WITHOUT A SAFETY DESIGN IS FULLY AT THE RISK OF CUSTOMER, SUBJECT ONLY TO
APPLICABLE LAWS AND REGULATIONS GOVERNING LIMITATIONS ON PRODUCT
LIABILITY.

Copyright

© Copyright 2013–2022 Xilinx, Inc. Xilinx, the Xilinx logo, Alveo, Artix, Kintex, Kria, Spartan,
Versal, Vitis, Virtex, Vivado, Zynq, and other designated brands included herein are trademarks of
Xilinx in the United States and other countries. AMBA, AMBA Designer, Arm, ARM1176JZ-S,
CoreSight, Cortex, PrimeCell, Mali, and MPCore are trademarks of Arm Limited in the EU and
other countries. OpenCL and the OpenCL logo are trademarks of Apple Inc. used by permission
by Khronos. PCI, PCIe, and PCI Express are trademarks of PCI-SIG and used under license.
MATLAB and Simulink are registered trademarks of The MathWorks, Inc. All other trademarks
are the property of their respective owners.

UG949 (v2022.1) June 8, 2022 www.xilinx.com

Send Feedback
UltraFast Design Methodology Guide for Xilinx FPGAs and SoCs 316