Setting the Target Clock Period - 2023.1 English

By default, IP are synthesized standalone, and OOC from the rest of a design.

• During synthesis of the user logic, the IP is seen as a black box.
• During implementation, the IP netlist is linked with other IP netlists and the user netlist.

Because the IP is synthesized separate from the top-level, the Vivado tools create the get_runs <ip_name>_ooc.xdc after OOC is complete to provide clock definitions for the IP, as explained in Synthesis Options for IP.

If you do not specify a target period, the IP uses a default clock period. This might result in a warning when the period used for the IP standalone differs from the period seen when synthesizing the top-level, as follows:

The warning informs you that if global synthesis had been used, the IP would be synthesized using a different clock period than was used when synthesizing the OOC IP.

IP have a variety of clock options:

• IP might have options in the customization GUI to set the target frequency/period to be used during OOC synthesis. You can use the Tcl Console to query and set the configuration option for the IP.
• IP might have a tab labeled Clocks, which lets you set the target frequency for the IP.
• IP might have the setting of the target mixed in with other settings. Typically, there is a tool tip to explain the setting.
• IP that does not provide a GUI option to customize the target clock frequency or period must rely upon other clock sources for frequency.

A clock port of an IP has a property associated with it ending with FREQ_HZ. Changing these properties results in the _ooc.xdc file for the IP to use these values when output products are generated for the IP.

Setting a Target Clock Period using Tcl Commands

To customize an IP, set unique properties on the IP object. When you use the Vivado IDE to configure an IP, the Vivado IDE issues the corresponding Tcl commands automatically. If an IP does not provide a GUI method for setting the target period for an IP in OOC synthesis, you can set it manually.

Changing an IP customization is permanent unless changed again using Tcl (or the IP customization GUI, if applicable); when you reset and regenerate the IP your changes are persistent.

The following is an example of the steps to set the target clock for the FIFO generator IP called char_fifo, which is used in the Wave Generator example design. The IP was customized to use a common clock for the read and write ports and the native interface.

1. Report the properties available for the IP using the report_property command. Type the following command in the Tcl Console:

   report_property [get_ips char_fifo]

2. From the output, you see there are five properties that end in FREQ_HZ for this IP:
   • CONFIG.core_clk.FREQ_HZ: Applicable when using a common clock (this example)
   • CONFIG.read_clk.FREQ_HZ: Applicable when using independent clocks
   • CONFIG.write_clk.FREQ_HZ: Applicable when using independent clocks
   • CONFIG.slave_aclk.FREQ_HZ: Applicable when using AXI
   • CONFIG.master_aclk.FREQ_HZ: Applicable when using AXI

   Only the first output is applicable for the native interface with a common clock. The CONFIG.core_clk.FREQ_HZ is by default set to 100000000 or 100MHz.

   If the IP was generated already, you could look at the char_fifo_ooc.xdc file and see the following line:

   create_clock -period 10 -name clk [get_ports clk]

   The period of 10 corresponds to the 100 MHz value of the CONFIG.core_clk.FREQ_HZ.

   For this example, with a desired clock frequency of 250MHZ, set as follows:

3. Type the following Tcl command in the Tcl Console:

   set_property CONFIG.core_clk.FREQ_HZ 250000000 [get_ips char_fifo]

4. After you set the property, generate the IP. This causes the OOC run (if present) to be reset and rerun.

After the run finishes, look at the char_fifo_ooc.xdc file. You see:

create_clock -period 4 -name clk [get_ports clk]

Now, the desired clock period/frequency is used when synthesizing the IP.

Determining Clocking Constraints and Interpreting Clocking Messages

Vivado can contain hierarchical constraints, top-level user constraints, and constraints that are delivered by an IP. These constraints can have dependencies which must be met to work correctly. One such constraint is clock creation.

• IP might create clocks that might be needed by other IP or the top-level design.
• IP might require a clock to exist to function correctly and not produce critical warnings.

If the necessary clock constraint is not being provided, then the IP at the top-level of the design issues a CRITICAL WARNING as described in Setting the Target Clock Period.

For more information about working with the designs with clocking requirements, see this link in the Vivado Design Suite User Guide: Using Constraints (UG903).

Tcl Command Example of an IP Clock Dependency

The following is an example of an IP constraint that is using the set_max_delay command, which has a dependency on a top-level clock, which is provided by the IP on the ref_clk port.

set_max_delay -from [get_cells data_reg] -to [get_cells synchro_stage0_reg]\ 
-datapath_only [get_property PERIOD [get_clocks -of_objects [get_ports ref_clk]]] 

The Vivado Design Suite User Guide: Using Constraints (UG903), at this link, describes how the get_ports command is converted into a get_pins command on the IP cell instance. Depending upon how the IP is connected in a design, the clock could come either from a user-supplied clock or from another IP:

• In the case of another IP supplying the clock, the clock is provided and no critical warnings are produced.
• If the clock is provided in the end-user logic, a critical warning is produced if no clock object is created (using the create_clock or create_generated_clock command).

Tcl Command Examples for Clocking

One way to find clocks in your design that are not being properly generated is to use report_clock_networks Tcl command:

report_clock_networks

This command produces a clock report for the design, including constrained and unconstrained clocks. You can use the report to determine if the clock module connected to your IP is missing a clock definition.

Other useful commands are:

• report_clocks

  This command returns a table showing all the clocks in a design, including propagated clocks, generated and auto-generated clocks, virtual clocks, and inverted clocks in the current synthesized or implemented design.

• report_compile_order

  report_compile_order -constraints

  This command shows which XDC files the design is using for synthesis and implementation and in what order they are processed. If an IP XDC that is creating a clock comes after an IP XDC that needs the clock, this clarifies the relationship.

Often you can resolve issues of a missing clock coming from an IP by adding a constraint to your top-level XDC timing constraints file. This could be the case when working with an XPS design where there are no XDC files present for some IP that could be creating a clock, such as a serial transceiver.

Examples of Critical Warnings and Warnings on Clocking

The following are examples of the warnings returned for a design that fails to find the clock constraint needed by an IP core.

CRITICAL WARNING: [Vivado 12-259] No clocks specified, please specify clocks using -clock, 
-fall_clock, -rise_clock options

[C:/Design/v_tc.xdc:1]INFO: [Vivado 12-1399] There are no top level ports directly connected 
to pins of cell 'system/v_tc', returning the pins matched for query '[get_ports s_axi_aclk]' 
of cell 'system/v_tc'.

[C:/Design/v_tc.xdc:1]Resolution: The get_ports call is being converted to a get_pins call 
as there is no direct connection to a top level port. This could be due to the insertion of 
IO Buffers between the top level terminal and cell pin. If the goal is to apply constraints 
that will migrate to top level ports it is required that IO Buffers manually be instanced.

CRITICAL WARNING: [Vivado 12-1387] No valid object(s) found for set_max_delay constraint 
with option 'from'.

[C:/Design/v_tc.xdc:1]Resolution: Check if the specified object(s) exists in the current 
design. If it does, ensure that the correct design hierarchy was specified for the object.