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

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

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 Created 10/15/2014
Last Updated 03/04/2015
Status Active
Type General Article
  • Vivado Design Suite