For a GTXE2 based design:
create_clock -name refclkout -period <period> [get_pins gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gtxe2_i/TXOUTCLK]
For a GTHE2 based design:
create_clock -name refclkout -period <period> [get_pins gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gthe2_i/TXOUTCLK]
For a GTPE2 based design:
create_clock -name refclkout -period <period> [get_pins gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gtpe2_i/TXOUTCLK]
The period specified in the preceding constraint depends on the reference clock that is selected. In the case of a 122.88 MHz reference the period is 8.138 ns, for a 153.6 MHz reference it is 6.510 ns, for a 245.76 MHz reference it is 4.069 ns, for a 307.2 MHz reference it is 3.255 ns, for a 368.64 MHz reference it is 2.713 ns and for a 380.16 MHz reference it is 2.630 ns.
This clock constraint is propagated through the core MMCM to constrain the core clock domain to the relevant speed. This constraint is present in the core XDC file.
In UltraScale GTHE3/GTYE3/GTHE4/GTYE4-based designs and Versal ACAP-based designs, the system clock is constrained by the reference clock constraint in the user XDC file. An example is provided in the example design XDC file provided by the core.