The core provides a separate receive-message interface which the user
application can use to receive indications of messages received from the link. When the
receive message interface is enabled, the integrated block signals the arrival of a
message from the link by setting the cfg_msg_received_type[4:0] output to indicate the type of message (see the
following table) and pulsing the cfg_msg_received signal
for one or more cycles. The duration of assertion of cfg_msg_received is determined by
the type of message received (see Table 1). When cfg_msg_received is
active-High, the integrated block transfers any parameters associated with the message
on the bus 8 bits at a time on the bus cfg_msg_received_data. The parameters transferred on this bus in each
cycle of cfg_msg_received assertion for various message
types are listed in the Table 2 table. For Vendor-Defined Messages, the integrated block
transfers only the first Dword of any associated payload across this interface. When
larger payloads are in use, the completer request interface should be used for the
delivery of messages.
| cfg_msg_received_type[4:0] | Message Type |
|---|---|
| 0 | ERR_COR |
| 1 | ERR_NONFATAL |
| 2 | ERR_FATAL |
| 3 | Assert_INTA |
| 4 | Deassert_ INTA |
| 5 | Assert_INTB |
| 6 | Deassert_ INTB |
| 7 | Assert_INTC |
| 8 | Deassert_ INTC |
| 9 | Assert_INTD |
| 10 | Deassert_ INTD |
| 11 | PM_PME |
| 12 | PME_TO_Ack |
| 13 | PME_Turn_Off |
| 14 | PM_Active_State_Nak |
| 15 | Set_Slot_Power_Limit |
| 16 | Latency Tolerance Reporting (LTR) |
| 17 | Optimized Buffer Flush/Fill (OBFF) |
| 18 | Unlock |
| 19 | Vendor_Defined Type 0 |
| 20 | Vendor_Defined Type 1 |
| 21 | ATS Invalid Request |
| 22 | ATS Invalid Completion |
| 23 | ATS Page Request |
| 24 | ATS PRG Response |
| 25 – 31 | Reserved |
| Message Type | Number of Cycles of cfg_msg_received Assertion | Parameter Transferred on cfg_msg_received_data[7:0] |
|---|---|---|
| ERR_COR, ERR_NONFATAL, ERR_FATAL | 2 |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number |
| Assert_INTx, Deassert_INTx | 2 |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number |
| PM_PME, PME_TO_Ack, PME_Turn_off, PM_Active_State_Nak | 2 |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number |
| Set_Slot_Power_Limit | 6 |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number Cycle 3: bits [7:0] of payload Cycle 4: bits [15:8] of payload Cycle 5: bits [23:16] of payload Cycle 6: bits [31:24] of payload |
| Latency Tolerance Reporting (LTR) | 6 |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number Cycle 3: bits [7:0] of Snoop Latency Cycle 4: bits [15:8] of Snoop Latency Cycle 5: bits [7:0] of No-Snoop Latency Cycle 6: bits [15:8] of No-Snoop Latency |
| Optimized Buffer Flush/Fill (OBFF) | 3 |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number Cycle 3: OBFF Code |
| Unlock | 2 |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number |
| Vendor_Defined Type 0 | 4 cycles when no data present, 8 cycles when data present. |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number Cycle 3: Vendor ID[7:0] Cycle 4: Vendor ID[15:8] Cycle 5: bits [7:0] of payload Cycle 6: bits [15:8] of payload Cycle 7: bits [23:16] of payload Cycle 8: bits [31:24] of payload |
| Vendor_Defined Type 1 | 4 cycles when no data present, 8 cycles when data present. |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number Cycle 3: Vendor ID[7:0] Cycle 4: Vendor ID[15:8] Cycle 5: bits [7:0] of payload Cycle 6: bits [15:8] of payload Cycle 7: bits [23:16] of payload Cycle 8: bits [31:24] of payload |
| ATS Invalid Request | 2 |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number |
| ATS Invalid Completion | 2 |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number |
| ATS Page Request | 2 |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number |
| ATS PRG Response | 2 |
Cycle 1: Requester ID, Bus Number Cycle 2: Requester ID, Device/Function Number |
The following timing diagram showing the example of a
Set_Slot_Power_Limit message on the receive message interface. This
message has an associated one-Dword payload. For this message, the parameters are
transferred over six consecutive cycles. The following information appears on the
cfg_msg_received_data bus in each cycle:
- Cycle 1: Bus number of Requester ID
- Cycle 2: Device/Function Number of Requester ID
- Cycle 3: Bits [7:0] of the payload Dword
- Cycle 4: Bits [15:8] of the payload Dword
- Cycle 5: Bits [23:16] of the payload Dword
- Cycle 6: Bits [31:24] of the payload Dword
The integrated block inserts a gap of at least one clock cycle between successive pulses
on the cfg_msg_received output. There is no mechanism to apply back
pressure on the message indications delivered through the receive message interface.
When using this interface, the user logic must always be ready to receive message
indications.