We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 60353

2014.1/14.7 AXI Interconnect - Long combinatorial paths between VALID and READY


Under certain combinations, a fully combinatorial path may exist between the  WVALID/WREADY or RVALID/RREADY signals, potentially causing a critical timing path. How do I resolve this?


The AXI Data Width Converter and Protocol Converter cores are building blocks that are typically inferred within an instance of the AXI Interconnect IP.

In some configurations of these converters, a write or read data pathway consists of a simple multiplexer. 

As such, the write/read data payload is not pipelined within the converter module, but is instead pipelined by adjacent modules in the Interconnect, in order to reduce register utilization and latency. 

As a result, the converter propagates the write and/or read channel handshake signals combinatorially, adding gating logic as needed. 

In some cases, this may result in a long combinatorial path delay along the handshake (valid/ready) or payload (data, wstrb) pathways through the converter, which may become the critical timing path of a system design. 

This situation can be identified by examining the pathway segments in the static timing report and looking for the instance names of the dwidth converter ("upsizer" or "downsizer") or protocol converter ("axi3_converter") in the net/cell name hierarchy.

Long combinatorial path delays between AXI modules can usually be resolved by inserting a Register Slice IP along the pathway just before (SI side) or after (MI side) the converter module. 

Often, enabling the Register Slice options in the AXI Interconnect configuration dialog will resolve the timing issue, as this will insert pipelining across all AXI channels at predetermined locations within the IP. 

As an alternative for more precise management of the problem, use the following guidelines for register slice placement and minimal configuration, depending on the type of converter found in the critical path:

Downsizer (configuration of AXI Data Width Converter core where SI width > MI width):

1. MI side: set B-channel = Light, other channels = Bypass.

2. SI side: if needed, set R-channel = Light, other channels = Bypass initially.

3. SI side: if needed, also set W-channel = Light (AW, AR and B remain Bypass).

Upsizer (configuration of AXI Data Width Converter core where SI width < MI width, and FIFO Mode = None):

1. SI side: set B-channel = Light, other channels = Bypass initially.

2. SI side: if needed, also set W-channel = Full (AW, AR and R remain Bypass). As an alternative, insert another reg-slice on the MI side and set the W-channel to Light.

AXI4-to-AXI3 (configuration of AXI Protocol Converter):

1. SI side: set W-channel = Full, other channels = Bypass.

2. MI side: if needed, set B-channel = Light, other channels = Bypass initially.

3. MI side: if needed, also set R-channel = Full (AW, AR and W remain Bypass).

If the pathway you wish to pipeline lies is inside the AXI Interconnect hierarchy, you can effectively "move" the converter outside of the block by directly instantiating the same type of converter IP, connecting it to the interface of the AXI Interconnect and configuring it the same way as the one inside the Interconnect. 

During Validation, the tools will determine that the conversion is no longer needed within the Interconnect and remove it.

You can now insert the reg-slice between the Interconnect and the instantiated converter.

AR# 60353
Date 06/19/2014
Status Active
Type General Article
  • AXI Interconnect