Each of the SI and MI on the AXI Interconnect core has its own aclk pin, so that transfers through the Interconnect can cross clock domains. The AXI Crossbar core also has its own aclk input. When the clock source driving the aclk pin of a SI or MI is different than the clock source driving the internal Crossbar, an AXI Clock Converter core is automatically instantiated along the pathway.
Clock conversion can be performed in any of the following ways.
•Synchronous clock-rate acceleration (1:N), where the MI-side clock rate is an edge-aligned integer multiple of the SI-side clock rate.
•Synchronous clock-rate reduction (N:1), where the SI-side clock rate is an edge-aligned integer multiple of the MI-side clock rate.
•Asynchronous clock rate conversion either accelerates or reduces clock rate by passing the signals of each channel through an asynchronous FIFO.
When the tools determine that the relationship between an interface and the crossbar is an integer ratio (faster or slower) within the range 1:16 to 16:1 (excluding 1:1), the tools automatically configure the Clock Converter to perform synchronous conversion; otherwise, the Clock Converter is configured in asynchronous mode.
When synchronous conversion is used, the clocks on either side must be derived from the same clock source with sufficiently small skew so that hold times are not violated by signals crossing in either direction. All clock domain crossings are resynchronized by flops within the AXI Clock Converter core. All flops that participate in resynchronization remain visible to static timing analysis tools and are covered by the period timing constraints defined for the clock signals themselves. The AXI Clock Converter core does not need to generate any multicycle timing constraints to override these resynchronization paths.
All paths that originate or end outside of the AXI Clock Converter core are neither over-constrained nor under-constrained with respect to their own clock domains.
When the AXI Clock Converter core 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 data-path-only timing constraints are generated by the core to cover all resynchronization paths.
The AXI Interconnect and the underlying Clock Converters rely on clock properties (FREQ_HZ, PHASE and CLK_DOMAIN) that are annotated on the clock nets connected to the IP. If the clocks are generated by Clock Wizard IP instantiated within the same IP Integrator Block Diagram, then this is automated. Otherwise, it may be necessary to manually specify these clock properties on the clock nets/ports.
Designs containing clock conversions should further have their clocks defined at the system level using create_clock constraints. This is also automated when clocks are generated by Clock Wizard IP within the IPI BD.. Each 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 that get resynchronized by the IP core. If you implement a design containing asynchronous clock conversions without defining your clocks at the system level, you can get warnings telling 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 your design, and they will resolve when you eventually provide the required system-level clock definitions.
Clock converters always introduce latency. Asynchronous conversion incurs more latency and uses more logic resources than synchronous conversion. Passing through a clock converter in both the SI and MI hemispheres when traversing any pathway across the AXI Interconnect core is wasteful. Select clocks to avoid passing through clock converters in both hemispheres whenever possible.
To reduce the number of clock converters in the system, it can be advantageous to cascade AXI Interconnect core instances, grouping together similarly clocked devices. For example, connecting a group of low-frequency AXI4-Lite slaves to a separate AXI Interconnect core clocked at low frequency could consolidate the clock domain crossing onto a single converter in the pathway between the cascaded AXI Interconnect core instances.
When speed-critical devices, such as a memory controller, are connected to an AXI Interconnect core, best data throughput is usually achieved by clocking the AXI Crossbar with the same clock source as the speed-critical slave.
You can also instantiate the AXI Clock Converter core directly in your design (without AXI Interconnect core) along any pathway between an AXI master and slave device operating in different clock domains. The AXI Clock Converter core operates in any AXI protocol. The AXI Clock Converter is not intended to be instantiated between two IP interfaces controlled by the same clock source. If both SI and MI clocks are found to be the same, the Clock Converter will perform the asynchronous conversion. (The Clock Converter does not support a wire-through configuration.) Any design using the run-time variable clock frequency feature of a Clock Wizard must use a Clock Converter in asynchronous mode to connect any IP that does not share the same clock source. The Clock Converter's synchronous conversion ratio is statically configured, and is therefore not suitable to handle run-time changes in clock ratios.