Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Manufacturing/Packaging

Utilising non-volatile memory IP in SoC designs

Posted: 25 Jun 2013 ?? ?Print Version ?Bookmark and Share

Keywords:SoC? EEPROM? OEM? antifuse NVM? efuse?

In their presentation "Design of future embedded systems: towards system of systems" in May 2012, IDC authors Alain Ptrissans and associates said that the embedded systems market in 2012 was worth just over ?1 trillion. Through the period ending in 2015, the market would enjoy a compound annual growth rate of 12 per cent reaching ?1.5 trillion. These figures exclude all PCs and mobile phones. The researchers declare that emerging applications such as smart cities, health, energy, and mobility will drive market growth and expansion.

Embedded systems are small microcontroller-based components that collect data and automate simple functions. Initially built around 8bit processors such as the 8051, these systems can be found in energy management, portable medical devices, automotive electronics touch screens and a wide variety of tags and sensors. IDC is predicting 1.5 trillion intelligent tags and sensors alone in 2020. These systems today are migrating towards higher performance compute engines with the availability of low-cost 32bit CPUs and the demand for more functionality in network-attached devices.

Using an intelligent tag/sensor as a typical embedded system, the attributes of the design are (1) finite feature set, (2) very high volume, (3) security, and (4) low power. In many instances these requirements will dictate a system-on-chip (SoC) design containing a CPU core with the program code stored on-board or in external EEPROM (figure 1). The rationale for erasable memory is the need for frequent software updating during development, design retargeting or customisation from stock prior to shipment and limited bug fixes or enhancements after the product is shipped into the field. The benefits of being able to change the code an unlimited number of times are appealing. However, in many if not all instances, the code is not changed frequently enough, if at all, to warrant unlimited programmability, nor is it wise to burden development costs onto the volume product. Low cost requirement is making embedded flash and EEPROM economically undesirable.

And because "security of information is a high priority and a very strong force on the market," as IDC declares, there is increased demand to securely integrate program code on chip. While unlimited re-programmability might be seen as an advantage during software development, once the device is shipped it becomes a product's greatest vulnerability. Where software developers see flexibility, hackers see opportunity.

Figure 1: The compute core of a simple Zigbee wireless SoC that might be found in a variety of security and lighting applications being designed into smart home applications.

This discussion will make the case for an alternative solution. Integrating anti-fuse non-volatile memory (NVM) with a finite number of rewrite cycles on chip and detail the benefits to the SoC manufacturer as well as to the system OEM that incorporates the SoC into a final system design. Anti-fuse, as its name implies, stores information by creating a low-resistance path instead of an open circuit as is the case for fuses, blown by a laser or high voltage potential, or ROM, in which memory is written in the metal layers of a device during place and route.

Figure 1 illustrates the compute core of a simple Zigbee wireless SoC that might be found in a variety of security and lighting applications being designed into smart home applications. The circuit could also be found in small control elements used in power line communications applications: motors, heating and air conditioning control, etc. for the home as well as automotive infotainment and passenger comfort control. The programs in these applications are relatively small compared to the code found in smart phones: kilobytes versus megabytes in sizes. They require no virtual memory operating system but rather execute a tiny scheduler. The program code for a small Zigbee connected sensor and controller application, for example, can be implemented in 256 kbits.

Evaluating the OEM's cost benefits of embedding code storage on-chip
To make the case for embedded antifuse NVM as replacement for external serial EEPROM, a 256kb memory will be used as a reference. As of this writing the distributors' price for a commercial grade memory component runs from $0.14 to $.18 in volume. An OEM ordering large quantities can acquire these parts at 60 per cent of the distributors' price or around $0.08 to $0.10 each. However, if the OEM requires industrial or military grade components, these prices can be twice the amounts cited. Assuming these benefits are compelling, the designer must consider that he is replacing an external device with virtually unlimited rewrite cycles with an internal embedded memory having a finite number of rewrite cycles. The arguments for embedding code storage on-chip will include cost, performance, and security (figure 2).

Besides savings the cost of one component, the OEM eliminates the need to qualify primary and secondary vendors and their associated serial EEPROM components. It removes the necessity to forecast the number of these memory chips that will be needed over the life of the OEM's end product and the worry of the chip's availability from affecting the OEM's ability to ship product (and the SoC supplier to sell components to the OEM). Eliminating the component also means a reduction in manufacturing cost for the final product, for example reducing a pick-and-place operation and final test by one unit. Eliminating the total burdened cost of this single external component can result in a savings of $0.05 or more for an OEM's bill-of-materials, in addition to the actual component cost.

Figure 2: Embedding code storage on-chip with an antifuse NVM IP reduces cost, improves performance, and enhances security.

1???2?Next Page?Last Page

Article Comments - Utilising non-volatile memory IP in ...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top