The RX CCIX interface are the ports through which the core receives CCIX data from the user application. The follwing defines the ports in the 256-bit receive CCIX interface.
Port | Direction | Width | Description |
---|---|---|---|
m_axis_ccix_rx_tdata | Output | 256 | The transmit data from core to CCIX application. |
m_axis_ccix_rx_tuser | Output | 45 | This set of signals contain sideband information on TLP being transferred. These signals are valid when m_axis_ccix_rx_tvalid is High. The individual signals are defined in the following table. |
m_axis_ccix_rx_tvalid | Output | 1 | The core asserts this signal whenever it presents valid data on m_axis_ccix_rx_tdata. |
ccix_rx_credit_gnt | Input | 1 |
This signal is asserted by the user application to release credits to the core. After the VC1 link becomes active, the user application first releases all the available credits to the core, and then it releases credits as available. The core receives valid data when there are credits available. Note: The core can drop valid between packets if there are no available credits. |
ccix_rx_credit_rtn | Output | 1 | The core asserts this signal to return the credits to the CCIX application when the CCIX link is going to deactivate state. |
ccix_rx_active_req | Output | 1 | This signal is asserted by the core to move out of deactive(stop) state and into active state. This signal must remain High as long the core requires the link to be in active state. |
ccix_rx_active_ack | Input | 1 | The CCIX application asserts this signal in response to the ccix_rx_active_req from the core when the application is ready to accept TLP packets |
ccix_rx_deact_hint | Input | 1 | The CCIX application asserts this signal when the application wants to go through a link reset. The core must use this signal to return the credits and move to link deactive state. |
Bit Index | Name | Width | Description |
---|---|---|---|
1:0 | is_sop[1:0] | 2 |
Signals the start of a TLP in this beat. The encoding is as follows
|
2 | is_sop0_ptr | 1 |
Indicates the position of the first byte of the first TLP starting in this beat:
|
3 | is_sop1_ptr | 1 |
Indicates the position of the first byte of the second TLP starting in this beat:
|
5:4 | is_eop[1:0] | 2 |
Signals that a TLP is ending in this beat. These outputs are set in the final beat of a TLP. The encoding are as follows:
|
7:6 | discontinue[1:0] | 2 |
This signal can be asserted by the core during a transfer if it has detected an error in the data being transferred and needs to abort the packet. The user logic nullifies the corresponding TLP on the link to avoid data corruption. The core asserts this signal in any beat of a TLP. It can either choose to terminate the packet prematurely in the cycle where the error was signaled, or continue until all bytes of the payload are delivered to the core. The discontinue signal can be asserted only when s_axis_ccix_rx_tvalid is high. |
10:8 | is_eop0_ptr[2:0] | 3 | Indicates the offset of the last Dword of the first TLP ending in this beat. This output is valid when is_eop[0] is asserted. |
13:11 | is_eop1_ptr[2:0] | 3 | Indicates the offset of the last Dword of the second TLP ending in this beat. This output is valid when is_eop[1] is asserted. |
45:14 | data_parity[31:0] | 32 |
Odd parity for the 256-bit data. Core sets bit i of this bus to the odd parity computed for byte i of s_axis_ccix_rx_tdata. On detection of a parity error, the user application can nullifies the corresponding TLP on the link and treat it as an Uncorrectable Internal Error. |