SPRUGR9H November 2010 – April 2015 66AK2E05 , 66AK2H06 , 66AK2H12 , 66AK2H14 , 66AK2L06 , AM5K2E02 , AM5K2E04 , SM320C6678-HIREL , TMS320C6652 , TMS320C6654 , TMS320C6655 , TMS320C6657 , TMS320C6670 , TMS320C6671 , TMS320C6672 , TMS320C6674 , TMS320C6678
Most of the time, an ARM’s memory virtualization will be different than that of the DSPs. Both ARMs and DSPs should define their own Navigator Cloud(s). This is an easy and efficient way to keep resources separated. However, most ARM-DSP applications require transferring data between them. There are at least two ways to do this: 1) either use a PKTDMA to transfer data from one cloud to another, or 2) create a common shared area to be used by both. The common shared area is the preferred approach, because PKTDMA loading may be reduced, and because configuring two clouds to communicate can sometimes be difficult.
In the common shared area approach, one or more Navigator Clouds are defined specifically for ARM-DSP data transfers. This means that memory virtualization is the same (ARM, DSP and QMSS use the same address regions whether virtual or physical), they use common descriptor memory regions, and all descriptor references point to memory and queues containing descriptors from one of the common descriptor memory regions.
In this approach, either the ARM or DSP writes data to the common shared area and the recipient is notified. This is done without the PKTDMA because no data transfer is necessary, and notification is accomplished using the QM by itself. Notification occurs with either a queue pend queue and an interrupt on the recipient core, or the recipient core polling on the receive queue.