The UHD-SDI core must have proper timing constraints applied. In this beta release version, it is completely up to the designer to apply these constraints properly. The included example design does have a correct set of constraints applied, and these constraints can be used as a guide for implementing the correct timing constraints.
The main clocks associated with the UHD-SDI core and wrapper must have clock period constraints applied. These clocks are the RXOUTCLK and TXOUTCLK of the GTX and the clocks applied to the UHD-SDI wrapper's clk_in and drpclk_in ports, which are usually driven by the same clock. In the example design, the file named kc705_uhdsdi_demo_timing_6G.xdc or kc705_uhdsdi_demo_timing_12G.xdc has the timing constraints for these clocks.
To constrain the GTX RXOUTCLK and TXOUTCLK, use constraints like the following two clock period constraints:
create_clock -period 3.367 -name tx0_outclk -waveform {0.000 1.684} [get_pins SDI/GTX/gtxe2_i/TXOUTCLK]
create_clock -period 3.367 -name rx0_outclk -waveform {0.000 1.684} [get_pins SDI/GTX/gtxe2_i/RXOUTCLK]
In these two constraints, the UHD-SDI wrapper has an instance name of SDI. So, the hierarchy path to the GTX instance in the UHD-SDI wrapper is SDI/GTX/gtxe2_i. Replace the SDI portion of the hierarchy path with the instance name of the UHD-SDI wrapper in your application. For each UHD-SDI wrapper, create constraints for each TXOUTCLK and RXOUTCLK and give each clock a unique name such as tx0_outclk, tx1_outclk, etc.
In the example TXOUTCLK and RXOUTCLK constraints, these clocks are constrained to 297 MHz which is the correct frequency to use when supporting 12G-SDI. If the maximum line rate supported by an application is 6G-SDI or lower, these clocks should be constrained to 148.5 MHz (period of 6.734). Also apply clock period constraints to the clocks connected to the UHD-SDI wrapper's clk_in and drpclk_in ports.
A set_clock_groups -asynchronous constraint should be applied to these clocks and any other clocks in the design so that the Vivado tools do not treat the clock as being related. In the example design, there are four clocks: RXOUTCLK, TXOUTCLK, CLKOUT0 from MMCM, and a clock called mgtclk from which the clock applied to the drpclk_in and clk_in ports of the UHD-SDI wrapper is derived. The following set_clock_groups command is applied to these three clocks:
set_clock_groups -asynchronous -group tx0_outclk -group [get_clocks rx0_outclk -include_generated_clocks] -group [get_clocks mgtclk -include_generated_clocks] -group [get_clocks -of_objects [get_pins i_system_basic/system_basic_i/clk_wiz_1/inst/mmcm_adv_inst/CLKOUT0]]
The rx0_outclk includes an option for -include_generated_clocks. This is because of the constraint that is described next. Also, the mgtclk has the -include_generated_clocks option because the clock connected to the clk_in and drpclk_in ports of the UHD-SDI wrapper is a derived clock, half the frequency of mgtclk.
The UHD-SDI wrapper contains the NI-DRU used to recover data in SD-SDI mode. The NI-DRU only runs in SD-SDI mode and in that mode, the RXOUTCLK has a frequency of 148.5 MHz. In applications that support 12G-SDI, the RXOUTCLK is constrained to 297 MHz and the NI-DRU does not usually meet timing at 297 MHz. But, it does not need to because it is only active when RXOUTCLK is 148.5 MHz. An additional set of constraints can be applied to the NI-DRU so that the NI-DRU is constrained to 148.5 MHz while the rest of the RX section is constrained to 297 MHz. The following two constraints are used in the example design to accomplish this:
set_property KEEP_HIERARCHY true [get_cells SDI/GTXCTRL/NIDRU]
create_generated_clock -name nidru_clk -source [get_pins SDI/GTX/gtxe2_i/RXOUTCLK] \ -divide_by 2 [get_pins SDI/GTXCTRL/NIDRU/CLK]
A KEEP_HIERARCHY constraint is applied to the NI-DRU module so that the clock name that must be identified in the next constraint is not changed by synthesis. The get_cells portion of this constraint uses a path to the NI-DRU of SDI/GTX/NIDRU. In the example design, the UHD-SDI wrapper has an instance name of SDI. Change the SDI portion of this path to the instance name of the UHD-SDI wrapper in your application. The KEEP_HIERARCHY constraint is only applied for synthesis and does not apply for implementation so it does not interfere with any optimizations that the implementation tool may perform.
The create_generated_clock constraint creates a hierarchical clock just for the NI-DRU. This is not a physically separate clock. It is a logical clock used for timing analysis only. The NI-DRU is still driven by the RXOUTCLK of the GTX. This constraint tells the timing analyzer that the clock connected to the NI-DRU's CLK port is derived from the GTX RXOUTCLK but is half the maximum frequency. RXOUTCLK is constrained to 297 MHz, so the NI-DRU is constrained to 148.5 MHz.
The example design also applies another constraint file containing timing constraints to the design. This file is named v_smpte_uhdsdi_timing_constraints.xdc. The timing constraints in this file apply multicycle path constraints to the RX and TX EDH processors. The EDH processors only run in SD-SDI mode. Furthermore, these processors use a clock enable from the NI-DRU which is never asserted more often than once every five cycles of RXOUTCLK when RXOUTCLK it is running at 148.5 MHz. The EDH processors would normally default to the 297 MHz constraint applied to RXOUTCLK and they cannot meet that timing. So, four constraints are used to apply multicycle path constraints to the two EDH processors. There are two constraints for each processor. If the design is built without the optional RX EDH processor by setting the UHD-SDI wrapper's INCLUDE_RX_EDH_PROCESSOR parameter to "FALSE", the two multicycle path constraints for the RX EDH processor should not be used.
The multicycle path constraints for TX EDH processor are shown next. One sets the setup time and the other the hold time. The setup time is set to 10 clock cycles, and the hold time is set to 9 clock cycles. This is the appropriate amount if RXOUTCLK is constrained to 297 MHz. However, if RXOUTCLK is constrained to 148.5 MHz, the setup time should be 5 clock cycles and the hold time should be 4 clock cycles.
set_multicycle_path -setup -from [get_cells * -hier -filter {name =~ *TX/TXEDH* && \ IS_PRIMITIVE && IS_SEQUENTIAL}] 10
set_multicycle_path -hold -from [get_cells * -hier -filter {name =~ *TX/TXEDH* && \ IS_PRIMITIVE && IS_SEQUENTIAL}] 9
The multicycle path constraints for the RX EDH processor are shown next. One sets the setup time to 10 clock cycles and the other the hold time to 9 clock cycles. As with the TX EDH processor, these are the correct values to use if TXOUTCLK is constrained to 297 MHz. However, if TXOUTCLK is constrained to 148.5 MHz, the setup time should be changed to 5 clock cycles and the hold time to 4 clock cycles. These constraints should not be used if the RX EDH processor is not included in the design.
set_multicycle_path -setup -from [get_cells * -hier -filter {name =~ *RX/INCLUDE_EDH* \ && IS_PRIMITIVE && IS_SEQUENTIAL}] 10
set_multicycle_path -hold -from [get_cells * -hier -filter {name =~ *RX/INCLUDE_EDH* \ && IS_PRIMITIVE && IS_SEQUENTIAL}] 9
The multicycle path constraints use a wildcard at the beginning of the path. These constraints match any number of UHD-SDI wrappers located at any point in the hierarchy of the design. Therefore, if multiple UHD-SDI wrappers are used in a project, only one set of these constraints is required to properly constrain the EDH processors of all UHD-SDI wrappers. However, to prevent this file from being applied to other modules, it is best to set the SCOPED_TO_REF property of the v_smpte_uhdsdi_timing_constraints.xdc file to the v_smpte_uhdsdi_edh_processor module. This can be done in the Vivado Integrated Design Environment (IDE) or by executing the following command from the Vivado Tcl Console:
set_property SCOPED_TO_REF {v_smpte_uhdsdi_edh_processor} [get_files \ v_smpte_uhdsdi_timing_constraints.xdc]