AXI-stream interface violates AXI-stream protocol

I'm seeing peculiar behaviour when using backpressure in SoC blockset. This seems to stem from the AXI4-Stream interface not implementing the AXI protocol correctly.

According to the AXI protocol, data at C should not be sent.

The variation seems to make it impossible to apply back pressure after a single word is transfered.

https://au.mathworks.com/help/soc/ug/AXI4-stream_interface.html

https://au.mathworks.com/help/hdlcoder/ug/model-design-for-axi4-stream-interface-generation.html

I'm curious about the motitivation behind this variation to the protocol.

Given the variation, perhaps it should not be referred to as AXI4?

[Vignesh]

Hi Alexander,

As per my understanding of the AXI protocol, "ReadyIn" indicates that the slave is ready to accept input for the current clock cycle. In the image, I see that at the time of the rising edge of clock cycle where "DataIn" is changed from B to C, "ReadyIn" is high, indicating that the slave is ready to accept the data for this cycle. This might be the reason why C is sent. Feel free to correct my understanding.

[Alexander]

Thanks for your response.

According to the AXI spec: "Transfer occurs only when both the VALID and READY signals are HIGH." Unfortunately a diagram for this scenario is not provided.

Both valid and ready are only high at the clock edges labelled A, B, D and E below the diagram in my original post.

[Siraj]

Hi Alexander.

If you look at the documentation it is clearly mentioned that

"When you model the ReadyIn signal, the DUT must be able to accept one more value after de-asserting the ready signal."

"You can only send one additional packet after the ReadyOut signal drops, subsequent data packets will be dropped until the Ready signal is asserted again. This is represented by data packet D in the image."

My understanding is that this approach might have been implemented to maintain system robustness and prevent undefined states. Do let me know if I'm mistaken.

Answer 1

[Angela Cuadros Castiblanco]

Hello Alexander,

I'd like to provide some clarity on the protocol implementation within our IP core generation workflow. When mapping the design under test (DUT) ports to AXI4-Stream interfaces, we employ a "simplified streaming protocol" (https://www.mathworks.com/help/hdlcoder/ug/model-design-for-axi4-stream-interface-generation.html#mw_098fb3c4-788d-4b93-a616-647ae23569e4).

You are correct that there are variations between our simplified streaming protocol and the full AXI4-Stream protocol. The motivation behind this choice was to allow users to model with fewer signals, thereby simplifying the design process when compared to the full AXI4-Stream protocol. For an example of how to model signals using the simplified protocol, please refer to the example located just below the timing diagram that you referenced in your post.

To clarify further, the timing diagrams provided in our documentation correspond to the simplified streaming protocol, not the full AXI4-Stream protocol. We will make sure to review our documentation to ensure this distinction is clear and avoid any potential confusion.

It's important to note that the IP core includes wrapper logic in the generated HDL code that translates between the simplified protocol at the DUT boundary and the actual AXI4-Stream protocol at the IP core boundary. This ensures that while you work with a simplified set of signals in Simulink for ease of modeling, the full protocol's integrity is maintained at the IP core boundary.

We apologize for any inconvenience this may have caused. We are aware of the interest in implementing the full AXI4-Stream protocol signals and we are considering having the option to choose between the simplified protocol and the full AXI4-Stream protocol for future releases.