The AXI Chip2Chip core allows level interrupts to be communicated through a high-priority internal channel. Interrupts can be independently communicated between AXI Masters and AXI Slaves. On detecting a value change in the interrupt inputs, the AXI Chip2Chip Master core initiates a high-priority transfer to update the interrupt outputs of the AXI Chip2Chip Slave core. Similarly, on detecting a value change in the interrupt inputs, the AXI Chip2Chip Slave core initiates a high-priority transfer to update the interrupt outputs of the AXI Chip2Chip Master core. At system level, you should ensure that the interrupt level is not changed until it reaches the other end. For example, an interrupt that is set on Slave instance may be unset only when it has reached the master instance. Interrupts may not be transferred properly if they toggle at a faster rate.
The AXI Chip2Chip Master core also generates interrupts for link error conditions. Interrupt signals are asserted by the AXI Chip2Chip Master core. For this, the error conditions detected in the AXI Chip2Chip Slave core are communicated to the Master device through a high-priority internal channel.
The following interrupt signals are supported in the AXI Chip2Chip Master core:
• Link Error Interrupt : Asserted when the AXI Chip2Chip Slave core is reset during normal operation. For more details on Link Error Interrupt, see Resets .
• Multibit Error Interrupt : When asserted, a Multibit Error interrupt indicates multiple bits are received in error in the Master or Slave AXI Chip2Chip core. For the SelectIO ™ interface, a multibit error is determined during deskew operations and indicates deskew operation failure.
• Configuration Error Interrupt : The Configuration Error Interrupt is set when a mismatch is detected between the Master and Slave AXI Chip2Chip core configurations.
After being asserted, interrupt flags can be cleared only with a reset.
• Graceful Exit in case of Link Failure : The Chip2Chip core supports completion of pending AXI Transactions, when there is a link failure between Chip2Chip master and Chip2Chip slave (when the core is generated by enabling the Enable Link Handler option).
Note: Select this feature only when there is a need to complete the pending AXI Transactions between master and slave (for example: Cable unplug between master / slave).
• Link Handler Operation for Chip2Chhip Master Core: Link handler keeps track of the AXI Transactions and performs the following actions when the link goes down:
a. "*_awready" will be gracefully pulled to low, that is, no new requests will be accepted from the AXI Master.
b. It accepts the exact number of pending data transactions and later the "*_wready" will be gracefully pulled to low.
c. Link Handler sends out the write response as "Slave Error" for the pending transactions to the AXI Master.
d. "*_arready" will be gracefully pulled to low, that is, no new requests will be accepted from the AXI Master.
e. It the generates the remaining number of pending read transactions to the AXI Master. Once there are no-more pending read transactions the " *_rvalid" will be gracefully pulled low. Here, the Read Response will be the Error Response and the Read Data will be all zeros
• Link Handler Operation for Chip2Chhip Slave Core: Link handler keeps track of the AXI Transactions and performs the following actions when the link goes down:
a. "*_awvalid" will be gracefully pulled to low, that is, no new write requests will be issued to the AXI Slave.
b. It generates the remaining number of pending write data transactions to the AXI Slave. Once there are no-more pending write transactions the "*_wvalid" will be gracefully pulled to low. The Write Data and the Strobe will be all zeros.
c. "*_arvalid" will be gracefully pulled to low, that is, no new read requests will be issued to the AXI Slave.
d. It accepts the exact number of pending data transactions and later the "*_rready" will be gracefully pulled to low, when there are no more pending requests.
For more information, see Link Handler Sequence .