TMS320C28346: Dual core memory allocation recommendations

Hi Jwalant,

Clarification on Part Number

The part number in your post title (TMS320C28346) differs from the one in your description (TMS320F28P650DK9). My response below is based on the TMS320F28P650DK, which appears to be the device you're actually using. The "9" suffix didn't match any known part — please verify if that's a specific ordering variant.

Short Answer

No, there is no inherent performance advantage to assigning all LS RAM to CPU1 and all GS RAM to CPU2. Both memory types have identical access timing. The better approach is to allocate based on architectural differences between LS and GS RAM, your per-core memory size needs, and bus availability.

Why There's No Speed Difference

Both LS RAM and GS RAM have identical cycle timing with zero wait states [1]:

So from a raw latency perspective, neither type is faster than the other.

Key Architectural Differences That Should Guide Your Allocation

1. LS RAM is architecturally associated with CPU1. LS RAM (LS0–LS7, 64 KB total) appears as CPU1's local memory. From CPU2's perspective, these same address ranges are mapped as D2/D3 RAM [1]. LS RAM can also be shared with the CLA (Control Law Accelerator) if you use it [2].

2. GS RAM has more bus bandwidth. GS RAM provides 4 buses versus LS RAM's 2 buses [1]. This means GS RAM can sustain higher concurrent access throughput — relevant if a core is doing simultaneous code fetch and data access from the same memory type.

3. GS RAM supports DMA access; LS RAM does not. If either core needs DMA transfers, those buffers must reside in GS RAM [1].

4. GS RAM is larger. 80 KB (GS) vs. 64 KB (LS), giving you more room for the core with heavier memory requirements [1].

Practical Recommendations

Rather than segregating by memory type per core, consider this approach:

• CPU1: Use LS RAM for CPU1's time-critical code/data (it's local to CPU1 by default and requires no ownership transfer). Use some GS RAM sections for larger buffers or DMA-accessible data.
• CPU2: Assign GS RAM sections to CPU2 for its code and data. GS RAM's 4-bus architecture actually makes it well-suited for CPU2's general-purpose use.
• If you use CLA on CPU1, reserve specific LS blocks for CLA program/data memory, which reduces the LS RAM available for CPU1's C28x code [2].

Critical initialization detail: CPU1 must explicitly assign memory ownership of GS RAM blocks (and flash banks) to CPU2 during boot [3]. These ownership settings persist across software resets — a known pitfall. If your bootloader assumes certain RAM blocks are owned by CPU1, but a previous application assigned them to CPU2, the bootloader will fail after a software reset [4]. Plan your ownership assignments carefully in your boot sequence.

Summary

Allocate based on these architectural properties and your per-core workload requirements — not by arbitrarily splitting memory types between cores.

Follow-up considerations: If you can share whether you're using the CLA, DMA, or have significantly different code/data sizes per core, I can refine the allocation strategy further.

Resources:

1. TMS320F28P65x Datasheet — RAM Parameters (Table 6-7, 6-8)
2. TMS320F28P55x TRM — LSx Memory and CLA Configuration
3. F28P65x Multi-Core Development Guide — Memory Ownership
4. E2E: TMS320F28P650DK Reset Issue — RAM Ownership Persistence

Best Regards,

Zackary Fleenor