Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

Cache Protection With the DSP/BIOS MPC Module

From Texas Instruments Wiki
Jump to: navigation, search


Generally, there are three different memory controllers on the C64x+ Megamodule:

  • Data Memory Controller (DMC) -> provides L1D memory
  • Program Memory Controller (PMC) -> provides L1P memory
  • Unified Memory Controller (UMC) -> provides L2 memory

Each of these memory controllers (i.e., DMC, PMC and UMC) implements its own memory protection checks. This means that certain attributes can be assigned to memory areas by programming the so called MPPA (Memory Protection Page Attribute) registers. An exception will be triggered if an illegal access to one of these memory areas gets detected. This functionality is supported in DSP/BIOS by the MPC module.

The MPC_ API functions of DSP/BIOS 5.x were developed based on the DM6446 memory architecture. This needs to be considered when configuring the MPC for a DM643x device via these API functions. The following description explains a procedure of how this could be accomplished.

Generally the following describes how the MPC_ API functions can be used to configure the DM643x MPC. However, the approach would be similar for any other devices that provide a MPC, but are not natively supported by these API functions.

Basic information on the memory architecture

Both the DMC and the PMC divide their memory into 2 regions, and each of these regions is divided into 16 power-of-2 sized pages. For each of these pages, certain attributes can be defined via the following MPPA registers:

  • Region 0 gets pages 0 to 15 -> MPPA registers L1DMPPA0..15 or L1PMPPA0..15
  • Region 1 gets pages 16 to 31 -> MPPA registers L1DMPPA16..31 or L1PMPPA16..31

Also, the UMC divides its memory into 2 regions and each of these regions is divided into 32 power-of-2 sized pages. For each of these pages, certain attributes can be defined via the following MPPA registers:

  • UMC UMAP0 gets pages 0 to 31 -> MPPA registers L2MPPA0..31
  • UMC UMAP1 gets pages 32 to 63 -> MPPA registers L2MPPA32..63

Note: Please refer to the "TMS320C64x+ DSP Megamodule Reference Guide [1]" for a detailed description of the MPPA registers and the attributes that can be assigned.

Configuring the MPC for a DM643x device

To generally enable the MPC, check the check-box in the following DSP/BIOS .tcf-file location:

System -> MEM - Memory Section Manager Properties -> tab "General" -> check "Enable Memory Protection Controller module"

To assign certain attributes to a particular memory region, call the following API function:

status = MPC_setBufferPA(baseAddr, size, space, perm);
Ptr baseAddr; /* base address of buffer to set permissions for */
Uns size; /* size in MAUs of buffer */
Int space; /* memory space of baseAddr */
MPC_Perm perm; /* permission attributes to set */

Note: Please also refer to the "DSP/BIOS 5.x Application Programming Interface (API) Reference Guide [2]" for additional information on the available MPC_ API functions.

Protecting the L1D and L1P Cache/RAM

Both the DM6446 and the DM643x provide the same amount of L1D and L1P Cache (32K) at the same addresses. Based on this information the following MPPA register-to-memory mapping is identical for both devices:

  • DMC Region 1 (L1D Cache/RAM):
Base address 0x00F10000, size = 32K.
MPPA page size for L1DMPPA16..31 = 32K / 16 = 2K.
  • PMC Region 1 (L1P Cache/RAM):
Base address 0x00E08000, size = 32K.
MPPA page size for L1PMPPA16..31 = 32K / 16 = 2K.

Note: The DM643x device also provides 48K L1D RAM attached to DMC Region 0. However, the MPC_ API cannot be used to protect this memory on the DM643x, since this memory doesn’t exist on the DM6446.

Since each MPPA register of these two memory controllers configures the same amount of memory (2K each) at the same address, the standard "MPC_setBufferPA" API function with the same settings as for DM6446 can also be used for the DM643x device.

Example: Protection of the (upper) 16K L1D Cache/RAM on DM643x and DM6446:

MPC_setBufferPA((Ptr)0x00F14000, 16*1024, 0, perm);

Protecting the L2 Cache/RAM

Unlike the L1D and L1P memory, the DM6446 provides 64K L2 Cache/RAM whereas the DM643x devices provide 128K of L2 Cache/RAM. Because of the different size L2 memory on these devices also the MPPA register-to-memory mapping is different for both devices:

For DM6446:

UMC UMAP0: Base address 0x00800000, size = 64K.
MPPA page size for L2MPPA0..31 = 64K / 32 = 2K.

For DM643x:

UMC UMAP0: Base address 0x00800000, size = 128K.
MPPA page size for L2MPPA0..31 = 128K / 32 = 4K.

As already mentioned above, the "MPC_setBufferPA" API function acts is implemented to run on a DM6446 device. So you need to feed this function with parameters (baseAddr and size) that correspond to the DM6446 in order to configure the same MPPA registers on the DM6437.

Example: Protection of the upper 32K L2 Cache/RAM on DM643x:

To protect the upper 32K of L2 memory on DM643x one requires the following 8 MPPA registers:
32K / 4K MPPA page size -> L2MPPA24..31 are required.
8 MPPA registers on a DM6446 device would correspond to 16K memory (8 * 2K MPPA page size).
This results in the following memory configuration via the "MPC_setBufferPA" API function (keep in mind that the Cache grows from higher addresses to lower addresses):
MPC_setBufferPA((Ptr)0x0080C000, 16*1024, 0, perm);

What to do if an exception has been triggered

For debugging the culprit of a memory access violation, refer to the "Execution Graph Details" LOG window of DSP/BIOS. The default exception handler for MPC prints out relevant information. To get information about all registers and stack contents at the time of the violation, one could set breakpoint at the NMI interrupt vector and refer to the NRP (NMI Return Pointer) for the location of the program where the exception occurred. Due to the pipeline architecture of the CPU, the actual violation could have occurred some instructions before that though. In case of other masters (e.g. HPI, VLYNQ) provoking the exception (asynchronously to the DSP program execution), the place of the exception could be different from test run to test run.

For a production system, it may be desirable to configure some custom exception handling to address the failure appropriately -- for example, log the NRP and master ID of the violation, restart or move into some fail-safe state.


An example project can be downloaded from here.