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.
