Clocking - 1.0 English

SmartConnect (PG247)

Document ID
Release Date
1.0 English

By default, all interfaces on the SmartConnect operate in the same clock domain, and the clock is received on the aclk input pin of the IP. The IP can be configured to support multiple clock domains by enabling a corresponding number of additional clock pins (aclk1… aclkn). The tools automatically determine which clock domain each interface operates in by tracing the interface connections in the system and identifying the clock source used to synchronize the AXI interface in the connected master or slave device. The SmartConnect is then automatically configured to apply each of its clock inputs to each of the SIs and MIs that are synchronized by the same clock source. An error will occur if any SI or MI interface connection is synchronized by a clock source not connected to one of the clock inputs on the SmartConnect.

It is not necessary to connect the same clock source to multiple clock inputs of the AXI SmartConnect IP. It is recommended to only enable as many clock inputs as there are distinct clock sources. Then connect each clock source to just one of the enabled clock inputs. AXI SmartConnect will automatically match the clock requirements of the connected AXI IPs to the set of clock sources on the enabled clock input pins.

When information is exchanged along any AXI channel between interfaces belonging to different clock domains, clock conversion logic is automatically inserted along the pathway.

When the tools determine that the relationship between the clock domains is an integer ratio (faster or slower) within the range 1:16 to 16:1, and that the clocks are derived from the same clock source, the tools automatically configure the clock converter to perform synchronous conversion; otherwise, the clock converter is configured in asynchronous mode.

When the clock converter is configured in asynchronous mode, all clock domain crossings are performed in an underlying instance of the FIFO Generator core, which is designed to internally resynchronize its write and read clock domains, regardless of the phase or frequency relationship. In asynchronous mode, the appropriate datapath-only timing constraints are generated by the core to cover all resynchronization paths.

All designs (especially those containing clock conversions) should have all their clocks defined in a system-level XDC file using the create_clock command. These clock constraints are sometimes automatically generated when targeting a development board or when including a Clock Wizard IP in the system. Each SmartConnect IP instance that implements an asynchronous clock-domain-crossing (CDC) attempts to generate IP-level timing constraints based on the clocks defined for the design. The purpose of the IP-generated constraints is to prevent timing violations during static timing analysis for CDCs which get resynchronized by the IP core. If you implement a design containing asynchronous clock conversions without defining the clocks at the system level, you may receive warnings informing you that clocks cannot be found, and that the generated set_max_delay constraints cannot be applied. These warnings have no impact on the correct functional implementation of the design, and they will resolve when the required system-level clock definitions are provided.

Clock converters always introduce latency. Asynchronous conversion incurs more latency and uses more logic resources than synchronous conversion.

To reduce the number of clock converters in the system, you can cascade AXI SmartConnect core instances, grouping together similarly clocked devices. For example, connecting a group of low-frequency AXI4-Lite slaves to a separate AXI SmartConnect core clocked at low frequency could consolidate the clock domain crossing onto a single converter in the pathway between the cascaded AXI SmartConnect core instances.