For a GTXE2 based design:
create_clock -name recclk -period <period> [get_pins gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gtxe2_i/RXOUTCLK]
For a GTHE2 based design:
create_clock -name recclk -period <period> [get_pins gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gthe2_i/RXOUTCLK]
For a GTPE2 design
create_clock -name recclk -period <period> [get_pins gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gtpe2_i/RXOUTCLK]
The period specified depends on the line rate selected. If the recovered clock is to operate at a maximum of 153.6 MHz, the period is 6.510 ns. If the recovered clock is to operate at a maximum of 245.76 MHz, the period is 4.096 ns. If the recovered clock is to operate at a maximum of 307.2 MHz, the period is 3.255 ns. If the recovered clock is required to operate at 368.64 MHz, the period is 2.713 ns and for a 380.16 MHz recovered clock it is 2.630 ns. See the clock configuration sections in Design Considerations for the recovered clock speed for the chosen configuration. This constraint in present in the core XDC file.
In GTHE3/GTYE3/GTHE4/GTYE4-based and Versal ACAP-based designs, the recovered 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.
In addition to constraining the clock domains the core XDC file contains constraints on the signals that cross between clock domains.