4 interrupt conditions, 1 cpu interrupts, 2 general description – Texas Instruments TMS320TCI648x User Manual

Page 85: Interrupts, Section 4

Advertising
background image

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.

Critical error: Event indicating that a critical error state was reached. The CPU should reset the 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.

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.

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.

The sending device initiates the interrupt by using the RapidIO defined DOORBELL message. The
DOORBELL packet format is shown in

Figure 45

. 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.

Figure 45. RapidIO DOORBELL Packet for Interrupt Use

SPRUE13A – September 2006

Serial RapidIO (SRIO)

85

Submit Documentation Feedback

Advertising