Today’s 8-bit, 16-bit, and 32-bit microcontrollers (MCUs) integrate on-chip memory such as flash memory, SRAM (including cache), mask ROM, one-time-programmable (OTP) EPROM and electrically erasable PROM (EEPROM) in memory sizes ranging from a few hundred bytes to several megabytes (MB).

Fig. 1. A modern MCU (top) with 128 KB of on-chip flash memory in a tiny chip and an early Intel 8048-based MCU (bottom) with 2 KB of ultraviolet-erasable PROM (EPROM), both made by NEC Electronics.

Designers of embedded systems must make the right choices for their applications based on meeting a specific performance target or cost budget. Choosing the right memory options is one of the critical steps in the MCU selection process, as memory subsystems impact not only overall performance but also system cost. Before selecting a memory option, it’s important to understand the basics.

Memory Options: There are two main types of memory available in today’s MCUs: read-only memory (ROM) and random-access memory (RAM). ROM refers to nonvolatile memory that is used to store code or instructions, while RAM refers to volatile memory that is used primarily to store data.

ROM: Most MCU manufacturers offer mask ROM and flash memory options in product lines, with a few still offering programmable ROM (PROM) or OTP ROM.

Flash memory has emerged as the preferred ROM type for MCUs, thanks to its improved performance, programmability, endurance and reliability. Over the years, it has replaced OTP memory and is slowly overtaking mask ROM. Some MCU vendors, such as NEC Electronics, have been converting the memory in their MCUs from a mixture of memory types to “all flash,” thereby enabling designers to make program changes late in the design cycle and also thereafter via in-system programming. One of the key benefits of flash memory is its self-programming capability, which enables designers to upgrade code remotely through media such as serial interfaces, wireless connections and even the Internet.

Enlarge this picture Fig. 2. Comparison of different memory technologies.

Mask ROM does offer a few advantages over flash memory in certain cases, for example, it is less expensive to mass produce and has a lower leakage current when the chip is in standby operation. However, flash memory technology is gradually catching up in these areas.

EEPROM is a complement to flash memory, because it offers programmability (erase and write) at the byte level instead of in blocks (hundreds of bytes). However, many MCUs now offer EEPROM emulation with on-chip flash memory via hardware or software implementations, providing an economic alternative. Fig. 1 illustrates the dramatic evolution in MCU ROM technology over the three decades since the first MCU (Intel 8048) was invented in the mid-1970s.

RAM: Static RAM (SRAM) is one of the primary memory types in the RAM family. The term “static” implies that SRAM retains its content as long as the power remains supplied. The other type is dynamic RAM (DRAM), which requires the memory content to be refreshed periodically to prevent data from being lost.

SRAM is used in MCUs mainly for data access and occasionally for code execution because of the nature of high-speed access. The amount of SRAM in MCUs is usually less than in a counterpart ROM due to the relatively bigger cell size, and therefore higher cost.

With its higher density (smaller cell size) and lower cost, DRAM offers an alternative memory option for MCUs. However, the requirement for constant refreshing and its different process technology make it less compelling for integration in MCUs due to implementation complexity. DRAM is often used as an external memory option for economic memory expansion. Embedded DRAM (eDRAM), as opposed to external DRAM, has been used in some application-specific MCUs for high-throughput and high-density data processing. Fig. 2 shows a comparison of the various memory technologies used in MCUs.

Memory architecture

Enlarge this picture Fig. 3. Memory architectures in MCU implementations.

An optimal memory architecture plays a key role in MCU implementation for delivering high efficiency at affordable cost.

Most 8-bit and 16-bit MCUs, as well as lower-end 32-bit MCUs, integrate sufficient on-chip memory as a single-chip solution, while higher-end 32-bit MCUs often offer an external memory bus interface to enable off-chip memory expansion for complex applications.

Flash memory offers relatively small die size and lower costs, as well as programming flexibility and security. However, access speed can be an issue. The best existing flash memory process technology can achieve a zero-wait-state access time of around 40 MHz. It is important to match the relatively slower flash memory speed with a CPU core clock if it is higher than the flash memory access limitation. Otherwise additional wait states are required during flash memory access, which slows down CPU performance.

One of the techniques used to overcome the bottleneck of flash memory speed is to apply cache memory, a type of high-speed SRAM to temporarily store frequently accessed code and data for rapid access. Cache memory can be used for slower external memory to speed up access, as well. However, the side effect to this approach is that one may lose deterministic behavior if a cache miss occurs with timing-critical code and data access, as with automotive airbag controls, for example. In such applications, the memory architecture is implemented to allow code allocation directly in the RAM area in addition to the ROM area to enable high-speed execution without sacrificing determinism.

A second technique to improve flash memory access performance is to add banked memory between the CPU core and flash memory. It is similar to a cache in terms of buffering memory, but with a much smaller memory footprint, it usually is a multiple of the bus width, for example, 16 bytes or 32 bytes. This technique is only effective in a sequential program, and it imposes similar deterministic side effects the same as cache memory.

Some real-time operating systems, such as Windows CE and embedded Linux, require an on-chip memory management unit (MMU) located between the cache (or memory) and CPU core to achieve virtual memory access. An MMU translates virtual memory addresses to physical addresses by page mapping and provides “larger” amounts of memory. Virtual memory also allows multiple processes to run within their own virtual memory spaces without increasing the actual memory footprint. Along with the real-time operating system, an MMU can also provide memory protection against accidental illegal access of memory from one process to another, ensuring system reliability. A memory protection unit (MPU) can be used as an alternative to MMU to provide simpler memory protection without involving virtual memory translation and an associated real-time operating system. An MPU allows memory partitioning into several regions, with each region having individual protection attributes. Processes allocated in physical memory regions would therefore be protected from invalid accesses.

With the addition of more complexity, cost and power consumption to MCU chips, cache and MMUs are only implemented in higher-end 32-bit MCUs where external memory for complex applications is often required.

Most MCUs today use the Harvard architecture with separate memory buses for address and data access, while a very few still use the Von Neumann architecture that uses the same memory bus for both address and data access. The Harvard architecture is more efficient than the Von Neumann architecture because it allows the CPU to access code (in ROM) and data (in RAM) in parallel but on separate buses, therefore providing higher throughput.

In addition to the memory bus, serial interfaces such as I2C or SPI could be used to interface to external memory, for example, flash memory and EEPROM, for additional data storage. Fig. 3 shows an MCU with possible memory options in a typical Harvard architecture.

Choosing options
 Sorting out various memory options for MCU offerings has never been easy. The first step for system designers is to determine their memory requirements, including size, speed, performance and power consumption, which are mainly driven by specific applications.

Estimating the right memory size is one of the keys to a successful design and in keeping system costs low. Memory capacity is often a moving target in design stages as well as in product life cycles. A code change late in the design process may require more memory, as will software upgrades for added features after a product is released.

For example, a new safety regulation standard, IEC60730, took effect in October 2007 in Europe for home appliance applications. This regulation requires MCUs in appliances to employ self-diagnosis mechanisms, including ROM/RAM integrity validation, CPU interrupt verification and other hardware checks, to detect faults. This may result in ongoing memory increases, both in ROM and RAM, by implementing self-test algorithms in addition to normal functions.

The good news is that MCU manufacturers, such as NEC Electronics, offer lineups of function-compatible and package-compatible flash MCUs with a wide range of memory capacities, giving designers a seamless migration path to accommodate increased memory footprints without changing hardware designs.

External memory (ROM or RAM) is needed when the estimated memory size exceeds on-chip memory capacity. This occurs in applications demanding high-density data storage, such as an embedded graphics user interface (GUI). Next-generation home appliances are likely going to equip a touch-screen LCD graphics panel as a human interface device.

In the case of a QVGA display with 16 bit-per-pixel resolution, 300 KB RAM would be required to allocate two image buffers for the LCD graphics controller alone, and this would most likely be on an external SRAM device. Applications using real-time operating systems such as Windows CE and embedded Linux will require external memory as well. A typical Windows CE or Linux application requires memory capacities ranging from a few to tens of megabytes for the real-time operating system kernel and application code. External flash memory ranging from 4 to 32 MB and paired with a similar amount of external DRAM is commonly practiced. In these cases, a higher speed MCU equipped with an MMU is often a must.

Meeting speed performance requires not only application knowledge, but memory architecture understanding. One must keep in mind that flash memory access speed is limited. If the CPU runs above 30–40 MHz, access to flash memory, or program execution, will slow CPU performance. Choosing a cache or cache-like memory buffer-equipped memory architecture is one option to keep the CPU running at high speed.

Another option is to choose memory architectures that allow code and data to be locked into SRAM for time-critical tasks that cannot afford to wait for flash memory access. This option is preferred in hard real-time applications, such as motor-control devices. The vector-control method has been widely used in appliance-motor drives, as it provides precise, responsive and cost-effective speed and torque control. Algorithms such as signal filters and vector controls must be processed within a predictable time to guarantee efficient and reliable motor control during fast transition operations. This real-time behavior can be better met by executing the algorithm from a higher-speed SRAM instead of cached slower-speed flash memory.

Memory types and architecture also impact power consumption. Mask ROM is the best option in terms of low power, maintaining an edge traditionally in battery-operated applications, although flash memory is closing the gap. Choosing a cache-less architecture also helps reduce power consumption.

The last, but most important, factor in choosing memory options is the combination of cost, memory type, and size. In design stages or pilot runs, flash memory provides the most flexible and cost-effective solution, as designers can upgrade code any time without incurring additional cost in hardware. At high volumes, mask ROM is the better option in terms of cost, despite an initial mask charge and relatively longer lead time.

With a thorough study of available memory options and application-specific requirements, designers should be able to determine the best-suited memory options to achieve the delicate balance between system performance and cost.

For more information, email: info@am.necel.com