Community
Participate
Working Groups
The C6472 is a 6-core C64P device. Here's the data sheet: http://www.ti.com/lit/gpn/tms320c6472 Each core has 'local' memories at the same address (various ranges between 0x00200000 - 0x00F07FFF). Additionally, each core can address each _other_ core's 'local' memory at a 'global' address space by OR'ing in the CORE id to the address in "the right place". For example, per the data sheet, each core has 'local' SL2 RAM at 0x00200000 - 0x002BFFFF. Every core can access every other core's local SL2 RAM at these 'global' ranges: * CORE 0 0x10200000 - 0x102BFFFF * CORE 1 0x11200000 - 0x112BFFFF * CORE 2 0x12200000 - 0x122BFFFF * CORE 3 0x13200000 - 0x132BFFFF * CORE 4 0x14200000 - 0x142BFFFF * CORE 5 0x15200000 - 0x152BFFFF There are use cases where users need to link code into these global address regions (e.g. for external loaders to address this memory). There's no way to use the ti.platforms.evm6472 platform to do this... the user must create their own platform. These global addresses should be added to the memory map. It's unclear whether these should be 'external' memory - implying each and every platform with a C6472 would need to do this, or whether it should be 'on chip' memory added to the catalog's memory map.
FYI, customer is ok with a fix in Jan. Perhaps we should commit this for XDC 3.21?
There is a flag that can be passed to the configuration engine to disable custom memory check. See the fix for the bug 360296. With that change, users should be able to use ti.platforms.evm6472 with any custom memory map.