I have been trying to understand the factors in controller / SoC design such that it can execute code from either XIP flash or from a RAM. There are controllers that support an XIP flash of around 5MB and there are SoCs where there is no XIP at all, there is only external memory present. The code is executed from the external DRAM in these cases (which I can relate to how PC works).

Some conclusions observed so far include:

  1. Using a XiP is no longer efficient after a certain size/speed, considering both the cost and the actual operation.
  2. The manufacturing process affects the design too?
  3. Some hybrid solutions are also present, where the instruction bus can fetch from a XIP or an External DRAM

In summary the question would be where is the line drawn between the two solutions : execution in RAM and execution in place from flash (XIP).

  • \$\begingroup\$ It's the compiler that decided what goes where, not the device. \$\endgroup\$ Sep 1, 2016 at 12:36
  • \$\begingroup\$ Or as likely, the developer, person who configured the system or wrote the linker map, etc. The only really common situation where the chip itself "decides" would be a hardware instruction cache. \$\endgroup\$ Sep 1, 2016 at 15:44
  • \$\begingroup\$ @ScottSeidman and ChrisStratton... Yes this would depend on the configuration once a chip is provided... But my question is more as to while deciding a chip or platform for a particular system or a project that we intend to use.. \$\endgroup\$
    – nkvvj
    Sep 1, 2016 at 16:19
  • \$\begingroup\$ That's my point -- the answer to the question in your title is "never". Experts, in theory, have decided this functionality, and if that functionality isn't right for your project, you can undo it and do it like you need to. \$\endgroup\$ Sep 1, 2016 at 16:22

2 Answers 2


This is a cost/performance trade-off, with sometimes some system specific design considerations too. Small RAMs can operate at full CPU speed, with low latency (cache, for example), but flash is slower (still varying with process, but slow).

For a slow CPU clock, flash can keep up with the instruction fetch rate, and XIP makes clear sense (particularly if the flash is in the same package).

Push up the performance a bit, and maybe more tricks are needed to allow the flash to keep up (maybe costing area and power, same as the alternative of adding RAM). This is (not suprisingly) the realm of high-end MCUs, and is ever edging upwards.

Eventually, flash has no chance to keep up with the full system performance potential (but still might be OK for bootloaders, where simplicity is key).

As for selecting a device based on its memory architecture, that depends on your code/data sizes, and required workload throughput. Once memory accesses cease being single-cycle, you're in the realms of benchmarking and guesswork.

  • \$\begingroup\$ Thanks for your reply.. It makes sense now and am able to relate better.. And yes it depends finally on our product to decide which architecture to use.. While asking the question I was also wondering how a MCU supplier would provide his products to fit the various needs, how he would design his product and its variants to fit the various needs of the application.. \$\endgroup\$
    – nkvvj
    Sep 2, 2016 at 2:26
  • \$\begingroup\$ @nkvvj I tried to clean up your question a little, hope you agree with the changes \$\endgroup\$ Sep 2, 2016 at 20:09
  • \$\begingroup\$ Yep.. It looks better now!! \$\endgroup\$
    – nkvvj
    Sep 3, 2016 at 1:52

Flash is slow, slower than DRAM.

Flash benefits from being on a chip by itself due to different manufacturing processes. Not as strongly as DRAM, but if you want a lot of it the manufacturing process pushes you in this direction.

There's also the consideration of whether the chip is targeted at "embedded" markets (small single-purpose programs, never updated) or something more consumer-facing (load a multitasking operating system which then loads applications).

Once a designer has decided that a chip should have a DRAM interface, on-board Flash looks like a bad idea (waste of area, needs in-circuit programming) and usually these SoC systems will have a small, fixed, but relatively sophisticated boot ROM. I have an iMX53 here which can boot from:

  • NOR Flash
  • NAND Flash
  • OneNAND Flash (whatever this is)
  • SD/MMC
  • Parallel ATA (PATA)/Serial ATA (SATA) HDD
  • Serial ROM devices

In all cases the bootloader copies pages to DRAM then transfers control there. This makes it conceptually simpler as not all those interfaces could support XIP.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.