Public Version
www.ti.com
IVA2.2 Subsystem Basic Programming Model
memory protection faults, respectively, on DMC.
–
UMC_CMPA (EVT124) and UMC_DMPA (EVT125) are generated in case of CPU and DMA
memory protection faults, respectively, on UMC.
–
PMC_CMPA (EVT126) is generated in case of a CPU memory protection fault on EMC.
The AID of the DSP appears in the DNUM control register in the CPU. DNUM is the DSP core number
register; it is used to identify which DSP subsystem accessed the shared resources. Because there is only
one C64x+:
•
GEM_DNUM[7:4] always equals 0x0.
•
GEM_DNUM[3:0] equals 0x0 because DSP is labeled as CPU0 in the single core system.
Thus, the possible requestors are:
•
C64x
•
IDMA
•
EDMA
•
Any device L3 initiator (through the IVA2.2 slave port)
The PrivID (relative to the DNUM register) equals 0. The ID of IVA DMA accesses is always 0x0, because
the IVA DMA inherits ID from DSP megamodule. All accesses on the IVA2 slave port to local memories
are seen by DSP megamodule as accesses from an external (non-DSP megamodule) initiator.
Thus, the hard-mapped memory protection IDs are:
•
AID0, used for IVA DMA
•
AID1 to AID5 (not used)
•
AIDX, used by the slave port (L3 initiators)
•
LOCAL bit, used by DSP loads, stores, and program fetches to memory attached directly to DSP
megamodule
5.4.9.2.2 Bandwidth Management
The bandwidth management scheme can be summarized as weighted-priority-driven bandwidth allocation.
Each requestor (EDMA, IDMA, CPU, etc.) is assigned a priority level on a per-transfer basis. The
programmable priority level has a single meaning throughout the system: there is a total of nine priority
levels, where priority 0 is highest and priority 8 is lowest priority. When requests for a single resource
contend, access is granted to the highest priority requestor. When contention occurs for multiple
successive cycles, a contention counter ensures that the lower priority requestor gets access to the
resource every one out of n arbitration cycles, where n is programmable through the MAXWAIT field. For
each identified requestor, a corresponding MAXWAIT field controls the maximum number of cycles that a
request can be blocked.
•
CPUARB registers: CPU priority and MAXWAIT programming model
The DSP CPU-initiated transfers consist of two components:
1. Program fetch transfers are issued by the CPU to the PMC, and the resulting L1P cache coherency
operations (such as alloc/evict) are then issued to the UMC.
2. Data load/store transfers are issued by the CPU to the DMC, and the resulting L1D cache coherency
operations (such as alloc/evict/long distance accesses) are then issued to the UMC.
Both program and data requests use the CPUARB values to define the maximum wait time (CPUARB[5:0]
MAXWAIT) and priority (CPUARB[18:16] PRI). The effect of the CPUARB values is not just local to PMC
or DMC. Priority/maxwait time applies to DMC/PMC cache transactions throughout the DSP megamodule
and controls arbitration at each relevant subblock within DSP megamodule. The priority (PRI) and
MAXWAIT field is programmed locally in the UMC, DMC, and EMC blocks, through the
IVA_UMC.
, IVA_DMC.
PRI and MAXWAIT fields,
respectively.
The default value of the CPUARB[18:16] PRI field is set so that CPU transactions are second to highest in
the system. This should be a relatively typical value used in most systems, which results in the DSP CPU
being granted highest priority most of the time, but a McBSP-type peripheral (typically programmed as the
highest priority transfer for sDMA requests) can interrupt the DSP CPU transfers on a nearly immediate
basis.
793
SWPU177N – December 2009 – Revised November 2010
IVA2.2 Subsystem
Copyright © 2009–2010, Texas Instruments Incorporated