We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 62488

Vivado Constraints - Common Use Cases of create_generated_clock command


Generated clocks are driven inside the design by special cells called Clock Modifying Blocks (for example, an MMCM), or by some user logic.

The XDC command "create_generated_clock" is used to create a generated clock object.


create_generated_clock  [-name <arg>] [-source <args>] [-edges <args>]
                        [-divide_by <arg>] [-multiply_by <arg>]
                        [-combinational] [-duty_cycle <arg>] [-invert]
                        [-edge_shift <args>] [-add] [-master_clock <arg>]
                        [-quiet] [-verbose] <objects>

This article discusses the common use cases of creating a generated clock.

For more information on create_generated_clock, please refer to (UG903).


Generated clocks are associated with a master clock from which they are derived.

The master clock can be a primary clock or another generated clock.

Please ensure you define all primary clocks first.

They are required for defining the generated clocks.

Use Case 1: Automatically Derived Clocks

For Clock Modifying Blocks (CMB) such as MMCMx, PLLx,IBUFDS_GTE2, BUFR and PHASER_x primitives, you do not need to manually create the generated clocks.

Vivado automatically creates these clocks, provided the associated master clock has already been defined.

You only need to create the primary clock that is feeding into the CMB.

The auto-generated clock names can be reported by the report_clocks command in the synthesized or implemented design so that you can use them in other commands or constraints.

It is possible to force the name of the generated clock that is automatically created by the tool.

See "Use Case 2: Renaming Auto-derived Clocks" below.

An auto-generated clock is not created if a user-defined clock (primary or generated) is also defined on the same netlist object, that is, on the same definition point (net or pin).

Vivado gives the following warning message when an existing primary or generated clock prevents auto-generated clock propagation:

Warning:[Timing 38-3] User defined clock exists on pin <pin_name> and will prevent any subsequent automatic derivation.

Automatically Derived Clock Example

The following automatically derived clock example is a clock generated by an MMCM.

XDC constraint:

create_clock -name clkin -period 10.000 [get_ports clkin]

The report_clocks command prints the following information:

Clock Period Waveform Attributes Sources

clkin 10.00000 {0.00000 5.00000} P {clkin}

cpuClk 10.00000 {0.00000 5.00000} P,G {clkip/mmcm0/CLKOUT}


Use Case 2: Renaming Auto-derived Clocks

It is possible to force the name of the generated clock that is automatically created by the tool.

The renaming process consists of calling the create_generated_clock command with a limited number of parameters.

create_generated_clock -name new_name [-source source_pin] [-master_clock master_clk] source_object

See (Xilinx Answer 57197) for more information.

A single create_generated_clock command has to specify a unique auto-derived clock to rename.

A user-defined generated clock cannot be renamed.

See (Xilinx Answer 62528) and (Xilinx Answer 62537) for common issues of renaming auto-derived clocks.

Renaming Auto-derived Clock Example

Same example in Use Case 1:

XDC constraint:

create_clock -name clkin -period 10.000 [get_ports clkin]
#renaming auto-derived clock cpuClk
create_generated_clock -name user_clk [get_pins clkip/mmcm0/CLKOUT]

Then the report_clocks command prints the following information:

Clock Period Waveform Attributes Sources

clkin 10.00000 {0.00000 5.00000} P {clkin}

user_clk 10.00000 {0.00000 5.00000} P,G {clkip/mmcm0/CLKOUT}


Use Case 3: User Defined Generated Clocks

When no automatic generation occurs, you will need to manually create clock modifications.

For example, for a clock divider logic that consists of LUTs and FFs, Vivado is not aware of the period relationship between the source clock and the divided clock. 

As a result, a user-defined generated clock is required for the divided clock.

This type of clock divider is not recommended in an FGPA. We recommend using an MMCM or a PLL to divide the clock.

Specify the master source using the -source option.
This indicates a pin or port in the design through which the master clock propagates.
It is common to use the master clock source point or the input clock pin of a generated clock source cell.

User Defined Generated Clock Example

The primary clock drives a register divider to create a divide-by-2 clock at the register output.


Two equivalent constraints are provided below:

create_clock -name clkin -period 10 [get_ports clkin]

# Option 1: master clock source is the primary clock source point with a 'divide by' value of the circuit.

create_generated_clock -name clkdiv2 -source [get_ports clkin] -divide_by 2 [get_pins REGA/Q]

# Option 2: master clock source is the REGA clock pin with a 'divide by' value of the circuit.

create_generated_clock -name clkdiv2 -source [get_pins REGA/C] -divide_by 2 [get_pins REGA/Q]

Use Case 4: Forwarded Clock through ODDR

In the Source Synchronous application, the clock is regenerated in the source device and forwarded to the destination device along with data.

A common method is to use clock forwarding via a double data-rate register.

In the following example, the ODDR instance in the source device is used to generate the forwarding clock for the Source Synchronous interface.

A user-defined generated clock needs to be created for the forwarding clock in order to be used in the set_output_delay constraint for the Source Synchronous interface.

Example of Creating Generated Clock at Clock Output Port:


create_generated_clock -name fwd_clk -multiply_by 1 -source [get_pins ODDR_inst/C] [get_ports CLKOUT]

The generated clock can then be referenced in the set_output_delay command.

For more information on set_output_delay command, please refer to (UG903).

Use Case 5: 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.

For this reason, you must review the CDC paths and add new constraints to exclude false paths due to overlapping.

The correct constraints are dictated by how and where the clocks interact in the design.

In some scenarios, user-defined generated clocks need to be created for the multiplexed clock in order to correctly constrain the CDC paths.

Multiplexed Clock Example:


If clk0 and clk1 only interact in the fanout of the multiplexer (FDM0 and FDM1), (i.e. the paths A, B and C do not exist), it is safe to apply the clock groups constraint to clk0 and clk1 directly.

set_clock_groups -logically_exclusive -group clk0 -group clk1

If clk0 and/or clk1 directly interact with the multiplexed clock (i.e. the paths A or B or C exist), then in order to keep timing for 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.

In this case, two generated clocks are created at the Multiplexer output pin and paths crossing the generated clock domains are ignored.

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
AR# 62488
Date 03/16/2018
Status Active
Type General Article
Page Bookmarked