There has been substantial effort in semiconductor development to find a "universal memory" that can be integrated into MCUs. A look back at MCU memory history will show how we got the memory structures we now use and the reasons for wanting a better approach.
Long, long ago, when the world wasn’t moving so fast, the first MCUs appeared. They came in several versions, in particular one with ROM and another with EPROM (there was no Flash at that time) for their program memory. The EPROM version was intended for development, while the ROM version, which required costly mask-based programming, was intended for production orders. In some series an OTP (one time programmable) ROM version was available. If you could write error-free software, or afford to throw away expensive mistakes, you could use it for development, too.
For most of us, though, the development process required frequent memory programming. Because the EPROM versions of MCUs were expensive, such MCUs as the 8031 were offered without program memory. This approach was more flexible in terms of the memory size your design could have, but the memory bus occupied I/O pins, leaving fewer available to peripherals.
In those old days of the previous millennium, EPROMs came in ceramic cases with quartz windows that allowed memory erasure by UV radiation. At first they had gold on pins and window frames, so small memory looked like a piece of jewelry. Later, in order to lower cost, gold disapeared, and the window was integrated straight into the ceramic top.
Memory chips didn't all have the same design, though, as IP licensing was not popular those days. Some designs had two memory banks, others only one. Dual-bank designs can be faster because they allow access tasks to be interleaved. Access time for EPROM at that time was in the 450ns range, so interleaving allowed a 2Mbit/s read speed. This higher speed matched the current needs of MCUs (the 8051 was introduced with a 12MHz clock but used 12 clock cycles for one machine cycle).
However, writing to these EPROMS was a challenge. Early versions needed a 25V programming power source, and writing one byte required a 50ms pulse. As a result, programming speed was about 20bps. This is slow, but for the then-popular 2716 memory it was adequate; programming the entire device took less than two minutes.
The MCU development process was not as easy as it is today. To reprogram an EPROM you first needed to erase it with UV (usually from a mercury lamp), then move it to a programmer, and finally insert it into a socket on the target board. If you found a bug, you needed to repeat the procedure to correct it and move on. There were EPROM emulators available that held the program in RAM, which could speed up the development process significantly, but only if you could spend the big money.
The EPROM is not electrically erasable and thus could not be used as storage for MCU information, so for a system to retain information when it unpowered, it used several alternate techniques. For one, the system could store data in static RAM with battery backup. Then EEPROMs appeared and were soon integrated into MCUs. However, their write speed is much lower than of RAM, so they could not be used as easily.
The next big memory development was the introduction of Flash memory and in-system programming (ISP). Flash provided faster read access than EPROM, and allowed electrical erasing. ISP was convenient for the development process because it eliminated the need for removing the memory from the target board for programming. One drawback was that Flash uses block-oriented access, which made it more complex to use than EEPROM. Still, most current MCUs integrate Flash instead of EEPROM to store parameters and variables.
The amount of internal memory in MCUs has since increased step-by-step to the point that we now can see MCUs with 2MB of Flash. However, challenges remain. Because Flash has limited write endurance (10,000 times, for example, in the NXP Cortex) and is written in sectors (4,096 bytes in NXP Cortex), its use in MCUs requires special techniques, such as changing write locations inside a sector, to increase reliability. Also, Flash write speed is not as high as its read speed. For example, with the NXP Cortex, the worst-case write from the current sector is 1.05ms, with another 105ms if the next sector must be used.
These differences in access speed and access modes for the various types of memories in MCUs have led to the quest for a unified memory -- one memory type to store nonvolatile data like code, and parameters that can also handle fast-changing temporary data. However, these requirements mean that designers need memory as fast as RAM, as easy to access as RAM, and as nonvolatile as EEPROM.
Such a memory structure was not possible until the appearance of new memory technologies. One existing technology now in production that can act as universal memory is FRAM (Ferroelectric RAM). It promises fast write speed (100x faster than Flash) and enormous endurance (10^15 cycles). Additionally, it uses 250x less energy than Flash to program a bit. FRAM is used comercially in Texas Instruments' MSP430FR family. A second-generation FRAM MCU, Wolverine, is expected to be introduced soon. Wolverine promises even lower power consumption.
However, FRAM has its drawbacks. For one, it is difficult to scale with shrinking process technology, as ferroelectric effects tend to disappear at small dimensions. Current FRAMs are fabricated in 130nm technology.
Due to limitations of FRAM, several other technologies that could become universal memories are under development. One of the more promising technologies is ReRAM (Resistive RAM), which claims to be nonvolatile, fast (access time 10ns), low-power, and scalable (below 30nm). It would be nice to have a ReRAM-equipped MCU today; however the technology is still in development.
In the meantime, how are you meeting your memory needs during development? Do you use EEPROM or emulate it in Flash? Perhaps you use FRAM to store data. What has been your experience? Are Flash, FRAM, and other memory technologies fast enough for today’s applications?
Tweet This
