Texas TMS320C645X ユーザーズマニュアル
www.ti.com
4
Interrupt Conditions
4.1
CPU Interrupts
4.2
General Description
acklD
rsv
prio
tt
1010 destID sourcelD
Reserved
srcTID
Reserved
Doorbell Reg #
rsv
Doorbell bit
CRC
PHY
LOG
TRA
LOG
TRA
PHY
5
3
2
2
4
8
8
8
8
9
2
1
4
16
16
32
16
4
2
10
info (msb)
8
info (lsb)
8
Interrupt Conditions
This section defines the CPU interrupt capabilities and requirements of the peripheral.
The following interrupts are supported by the RIO peripheral.
•
Error Status: Event indicating that a run-time error was reached. The CPU should reset/resynchronize
the peripheral.
the peripheral.
•
Critical Error: Event indicating that a critical error state was reached. The CPU should reset the
system.
system.
•
CPU servicing: Event indicating that the CPU should service the peripheral.
The RIO peripheral is capable of generating various types of CPU interrupts. The interrupts serve two
general purposes: error indication and servicing requests.
general purposes: error indication and servicing requests.
Since RapidIO is a packet oriented interface, the peripheral must recognize and respond to inbound
signals from the serial interface. There are no GPIO or external pins used to indicate an interrupt request.
Thus, the interrupt requests are signaled either by an external RapidIO device through the packet
protocols discussed as follows, or are generated internally by the RIO peripheral.
signals from the serial interface. There are no GPIO or external pins used to indicate an interrupt request.
Thus, the interrupt requests are signaled either by an external RapidIO device through the packet
protocols discussed as follows, or are generated internally by the RIO peripheral.
CPU servicing interrupts lag behind the corresponding data, which was generally transferred from an
external processing element into local L2 memory. This transfer can use a messaging or direct I/O
protocol. When the single or multi-packet data transfer is complete, the external PE, or the peripheral
itself, must notify the local processor that the data is available for processing. To avoid erroneous data
being processed by the local CPU, the data transfer must complete through the DMA before the CPU
interrupt is serviced. This condition could occur since the data and interrupt queues are independent of
each other, and DMA transfers can stall. To avoid this condition, all data transfers from the peripheral
through the DMA use write-with-response DMA bus commands, allowing the peripheral to always be
aware that outstanding transfers have completed. Interrupts are generated only after all DMA bus
responses are received. Since all RapidIO packets are handled sequentially, and submitted on the same
DMA priority queue, the peripheral must keep track of the number of DMA requests submitted and the
number of responses received. Thus, a simple counter within the peripheral ensures that data packets
have arrived in memory before submitting an interrupt.
external processing element into local L2 memory. This transfer can use a messaging or direct I/O
protocol. When the single or multi-packet data transfer is complete, the external PE, or the peripheral
itself, must notify the local processor that the data is available for processing. To avoid erroneous data
being processed by the local CPU, the data transfer must complete through the DMA before the CPU
interrupt is serviced. This condition could occur since the data and interrupt queues are independent of
each other, and DMA transfers can stall. To avoid this condition, all data transfers from the peripheral
through the DMA use write-with-response DMA bus commands, allowing the peripheral to always be
aware that outstanding transfers have completed. Interrupts are generated only after all DMA bus
responses are received. Since all RapidIO packets are handled sequentially, and submitted on the same
DMA priority queue, the peripheral must keep track of the number of DMA requests submitted and the
number of responses received. Thus, a simple counter within the peripheral ensures that data packets
have arrived in memory before submitting an interrupt.
The sending device initiates the interrupt by using the RapidIO defined DOORBELL message. The
DOORBELL packet format is shown in
DOORBELL packet format is shown in
. The DOORBELL functionality is user-defined. This
packet type is commonly used to initiate CPU interrupts. A DOORBELL packet is not associated with a
particular data packet that was previously transferred, so the INFO field of the packet must be configured
to reflect the DOORBELL bit to be serviced for the correct TID info to be processed.
particular data packet that was previously transferred, so the INFO field of the packet must be configured
to reflect the DOORBELL bit to be serviced for the correct TID info to be processed.
Figure 42. RapidIO DOORBELL Packet for Interrupt Use
74
Serial RapidIO (SRIO)
SPRU976 – March 2006