Hello?
I'm trying to implement the Firmware with the Cortex-M3 SoC which is separately designed I-RAM and D-RAM in Keil MDK.
As you can see the above example system, AHB Interconnect have 3 slaves S0, S1 and S2. and S0 and S1 are connected with separated SRAM, especially, If it can be, I'd like to make the firmware to allocate each address region separately.
For example, the system consisted as the below.
S0 address map 0x00000000 ~ 0x0000FFFF
S1 address map 0x00010000 ~ 0x0001FFFF
It means that I'd like to run the I-Code part of firmware into I-Ram and the D-Code part of firmware into D-Ram.
In this case, My question is
1.How to start Firmware separated in I-RAM and D-RAM within Cortex-M3 design kit by using Keil MDK?
2.How to assign or calculate the S0 and S1 addresses region at the first time of initial architecture designing?
3.How to determine the I-RAM and D-RAM size ?
Both I-CODE and D-CODE bus see 0x00000000 to 0x1FFFFFFF. The only different is that:
- I-CODE bus handles instruction fetches and vector fetches
- D-CODE bus handles data and debug accesses.
While it is possible to create address decoding logic to have SRAM X visible on I-CODE in address 0x00000000 and SRAM Y visible on D-CODE in address 0x00010000, it doesn't quite work in C programming environment. In C programming environment, the compiler generates literal data inside program image, which need to be accessed as data read/write, so has to be visible from D-CODE. As a result, a program image need to be visible from both I-CODE and D-CODE buses.
The reason for separating the CODE bus into two physical bus interface is to allow chip designers to create flash access accelerators: for example, it can have flash prefetching logic for I-CODE and literal data cache connect to D-CODE, but both sides need to be merged at the flash / program memory.
To answer your question:
A program image for C programming cannot be created with the memory layout you mentioned. While Keil MDK has an option to create object files that are targeted for eXecute-Only Memory (XOM), C runtime libraries are not designed to support that.
Assume that you create a program image (that contains both instructions and data), you can find the program memory size requirements from the memory map file (generate in linking stage).
regards,
Joseph
Thank you so much letting me know that, BTW, I want to know more about you said
Joseph Yiu said:The reason for separating the CODE bus into two physical bus interface is to allow chip designers to create flash access accelerators: for example, it can have flash prefetching logic for I-CODE and literal data cache connect to D-CODE, but both sides need to be merged at the flash / program memory.
Especially, I want to know more implementing examples for separating the CODE bus into two physical interface. how to do that implementing? Does such as a multi-layer interconnection matrix help to implementing?
The only reference in public domain that I am aware of is STM32 ART (see https://eda360insider.wordpress.com/2011/09/22/ingenious-architectural-features-allow-st-micro-to-extract-maximum-performance-from-new-microcontroller-family-based-on-arm-cortex-m4-cost-less-than-6-bucks-in-1000s/ )
Their ART accelerator utilized separated I-CODE and D-CODE buses. However, in newer microcontrollers our customers trend to use instruction caches rather than flash access accelerators. With cache based design there is not much advantage of having separated I-CODE and D-CODE buses. An example of such cache is CG092 in Corelink SDK
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0569b/index.html
I believe that is part of the Cortex-M3 DesignStart.
Dear Sir,
Thank you for letting me know that. As your answer is quite a bit helping me for understanding that.
But I'm confused that from the wikipedia : https://en.wikipedia.org/wiki/CPU_cache#Separate_versus_unified , I'm not sure but as I understood it want to say that Instruction and data caches can be separated for higher performance with Harvard CPUs but they can also be combined to reduce the hardware overhead.
if I understand well, the KEIL environment can support separated instruction and data caches architecture such as above architecture diagram. am I right? then How do I firmware within separated Instruction and data caches architecture?
I found the below link for Unifying the code buses. then I believe that there is also "non-unifying a.k.a divided" the code buses information. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/BABEICHD.html
What am I supposed to do the firmware such as a this architecture?
Hi,
Having Harvard cache doesn't means that it have different memory views on the I-side and D-side. When there is a cache miss, both I-side and D-side will access to the same main memory system, so the processor still have a unified memory view despite having Harvard caches. Having Harvard cache arrangement allows instruction access to I-cache and data access to D-cache to be carried out at the same time without too much of hardware complexity. Potentially, a cached cache line in a program image could present in both I-cache and D-cache at the same time, if that cache line contains both instructions and literal data.
A processor system can have Harvard caches and unified caches at the same time. For example, a Cortex-A9 system can have Harvard level 1 cache, and unified level 2 cache.
For Cortex-M3, although we use separate I-CODE and D-CODE buses for program memory access in the CODE region, the two buses are expected to be merged before reaching to program ROM/flash and there is no need to separate the program instructions and literal data into two different images.