Visible to Intel only — GUID: djm1703028864712
Ixiasoft
Visible to Intel only — GUID: djm1703028864712
Ixiasoft
6.3.5.1.1. Application Logic Guidelines for the AXI Streaming TX Interface in HIP Native Mode (R-Tile)
- Application logic must adhere to the requirements for the pX_app_ss_st_tx_ready and pX_app_ss_st_tx_valid signal behavior as outlined in the AXI4 Streaming Specifications.
- Transmission of a TLP must be uninterrupted when the pX_app_ss_st_tx_ready is asserted, unless there is backpressure from the IP as indicated by the deassertion of pX_app_ss_st_tx_ready.
Note: Failing to meet this guideline may cause the transmission of a TLP with an invalid LCRC.
- For the 1x16 mode, the start of a command (header) can only happen in segment 0 (S0) or segment 2 (S2) (i.e. a given command cannot start on segment 1 (S1) or segment 3 (S3)).
- For the 1x16 mode, the header for segment 2 is allowed depending on the utilization for segment 0 and segment 1. Refer to the table below for the allowed conditions. Note that the table does not include all the signals for the AXI-ST TX interface. It only shows the Header (H) and Data (D) combinations to highlight the valid cases where a command can be started on segment 2.
Table 34. TX AXI-ST HIP Native Mode Data Packing for x16 1024 Bits with 4 Segments S0 S1 S2 S3 H, D - H, D - H, D D H, D D D - H, D D D D H, D - - For Configuration Mode 1 (2x8) and Configuration Mode 2 (4x4), the header for segment 1 is allowed depending on the utilization for segment 0. Refer to the table below for the allowed conditions. Note that the table does not include all the signals for the AXI-ST TX interface. It only shows the Header (H) and Data (D) combinations to highlight the valid cases where a TLP can be started on segment 1.
Table 35. TX AXI-ST HIP Native Mode Data Packing for x8 S0 S1 H, D H, D H, D D D H, D - For a single command spanning across multiple segments, the application logic needs to send the TLP in the order of the segment indices (segment S0 → S1 → S2 → S3 → S0).
- If the length of the TLP being transmitted is greater than the segment size, the segment used to assert the pX_app_ss_st_tx_tuser_last_segment signal is dictated by the TLP length.
- The app_ss_st_tx_tkeep signal must be used to qualify the byte-wise data on each segment to indicate if the content of the associated byte is valid. The invalid bytes are allowed only during the app_axi_st_tx_tlast cycle.
- The maximum number of clock cycles allowed between the deassertion of pX_app_ss_st_tx_ready and pX_app_ss_st_tx_valid is 4 axi_st_clk cycles.
Example of the HIP Native mode packing scheme in Gen5x16 with a 1024-bit, 4-segment bus on the TX ASI-ST Interface:
1st Command with Data - Payload 16 Bytes
2nd Command with Data - Payload 32 Bytes
3rd Command with Data - Payload 64 Bytes
4th Command with Data - Payload 96 Bytes
5th Command with Data - Payload 128 Bytes
6th Command with Data - Payload 20 Bytes
Example of the HIP Native mode packing scheme in Gen5x8 with a 512-bit, 2-segment bus on the TX ASI-ST Interface:
1st Command with Data - Payload 16 Bytes
2nd Command with Data - Payload 32 Bytes
3rd Command with Data - Payload 96 Bytes
4th Command with Data - Payload 20 Bytes
AXI Streaming TX Interface ss_app_st_tx_tready Behavior in HIP Native Mode
The following timing diagram illustrates the behavior of ss_app_st_tx_tready, which is deasserted to pause the data transmission to the IP, and then reasserted. The application logic deasserts app_ss_st_tx_tvalid four clock cycles after ss_app_st_tx_tready is deasserted (from the point marked with the letter a to the point marked with the letter b). This is the maximum number of clock cycles allowed between the deassertion of ss_app_st_tx_tready and app_ss_st_tx_tvalid.
- Case 1: If there is a TLP suspended due to the deassertion of ss_app_st_tx_tready, then the maximum number of clock cycles for app_ss_st_tx_tvalid to go high after the assertion of ss_app_st_tx_tready is one (as illustrated in the following figure).
- Case 2: If there is no TLP suspended due to the deassertion of ss_app_st_tx_tready, then there is no requirement, and the application logic can reassert app_ss_st_tx_valid as soon as it has a TLP available to transmit. The application must not deassert app_ss_st_tx_valid during the packet transmission unless there is backpressure from the IP indicated by the deassertion of ss_app_st_tx_tready.
Note: Failing to meet this guideline may cause the transmission of a TLP with an invalid LCRC.