Alternative techniques accelerate flash-memory-programming speeds
As flash-memory densities grow, consequent longer programming times lead to increases in manufacturing costs. To meet this challenge, manufacturing engineers are seeking new methods for quickly programming and verifying memories.
By Peter Larsen, Intel Corp -- EDN, April 1, 2004
No matter which flash-memory-programming method you use, optimization of the programming algorithm is a key consideration. It has the potential to reduce flash-programming time and, therefore, increase the manufacturing beat rate (the number of products containing flash memory that go through the manufacturing flow in a given amount of time). Algorithm coding employs a variety of methods, resulting in some algorithms that are inherently optimized and others that can greatly benefit from optimization attention.
One important optimization consideration is modifying the test flow so that only necessary operations occur. For example, because manufacturers ship memory components from the factory in a blank state, you can reduce the total programming time by eliminating erase check on new devices. Also, you can reduce software overhead by remembering that each signal transaction requires time to execute. If you frequently toggle a signal, you consume incremental system overhead with each high-to-low or low-to-high transition. To reduce system overhead, therefore, look for opportunities to reduce the number of signal transitions.
Eliminate redundant verification checks. Memory components with internal write-state machines automatically verify data written to the memory array; hence, program-verification operations initiated by the programmer are redundant. To gain performance improvements, test engineers should continually look for optimizations to reduce overall programming times. Also, look ahead at data patterns. Programming FFFF data to the flash component is unnecessary, because, in an erased flash memory, all bits are set to FFFF. To optimize programming, the algorithm should look at data to be programmed and skip FFFF patterns.
Choose the widest possible bus, because programming data to flash memory using the maximum bus width reduces programming times. For example, programming a 16-bit device using an 8-bit bus width will take twice as long as it would have taken with a 16-bit bus. Similarly, perform concurrent programming operations on stacked devices containing multiple flash-memory die, as long as doing so doesn't violate maximum power.
Many flash components incorporate the use of high voltage for fast manufacturing programming; use the high-voltage program-and-erase option if it exists. Also, software engineers should take advantage of augmented features in flash memories, such as write buffers, when they are available. Write buffers provide faster programming, thus speeding the overall programming process. Finally, connect a logic analyzer to your application and verify that the signal timing meets data-sheet specifications and also ensures that signal times aren't excessively long (Figure 1).
OBP and ATE
Many manufacturers use OBP (onboard programming) to quickly and efficiently program flash-memory components. OBP is especially useful for performing JIT (just-in-time) code updates to already-assembled products. For example, when a customer orders a cellular telephone, you can use OBP to update the flash memory with the most recent firmware on a JIT basis. Customers receive the most recent phone features, including country- and region-specific language and other information; thus, they receive the best value.
Technical tips to consider when investigating OBP include the fact that the OBP power supply must be able to supply current to all components on the pc board. Power-supply tolerances, along with address, data, and control-drive capability, must also conform to the flash memory's requirements. Ensure, too, that you minimize the inductance and capacitance introduced to the circuit by the programmer and interface.
Manufacturing engineers use ATE (automated test equipment) to perform in-circuit testing on assembled pc boards. You can obtain additional value from ATE by integrating flash-memory-programming routines into the test flow. Doing so allows you to avoid the costs of either maintaining programming equipment and dedicated floor space or of outsourcing programming functions to third-party vendors. To allow flash programming on ATE systems, design engineers must provide bed-of-nails probe access to all component pins. An optimized programming algorithm makes the difference between slow and fast programming on ATE systems. Be sure to follow these tips to ensure a fast ATE-programming algorithm.
The JTAG (Joint Test Action Group) TAP (test-access port) is another OBP method that high-density pc-board applications commonly use. By communicating serially with the pc board, JTAG provides a viable programming alternative in a manufacturing environment. Manufacturers can use JTAG to program the entire code and data image into the flash memory. JTAG communication equipment is available that employs a PC add-in card slot and connects to the IEEE 1149.1 JTAG-compliant application.
Using this equipment, you can send commands and data through the TAP to the system microprocessor and instruct it to program the flash component. The manufacturing engineer typically creates the software to program the flash memory. Programming at high speeds requires that you optimize the programming algorithm (Figure 2).
When optimizing your JTAG programming flow, you should first select JTAG programming equipment that can quickly provide the necessary programming information to the flash component. Also, minimize the scan chain associated with flash memory to be programmed. Use the quickest possible board clock speed (TCK) for faster programming times. Finally, include the write-enable signal in the TAP connections for external control.
Proprietary algorithms
Suppliers of flash-memory ICs may offer additional means of reducing the per-device programming time and cost for their products. Device-programmer companies support many of these proprietary algorithms. For example, Intel developed EFP (enhanced-factory-programming) technology to provide fast manufacturing write performance. This feature, combined with programmer hardware and software optimizations that harness it, can result in tangible time and cost savings for applications involving high-volume manufacturing lines.
More recently, Intel developed the BEFP (buffered-enhanced-factory-programming) algorithm to improve the manufacturing-programming performance for its multilevel-cell flash technology. An adaptation to the previous single-bit-per-cell EFP algorithm, BEFP addresses bottlenecks common in equipment-assisted programming. If you program Intel StrataFlash memory components, you can use BEFP to decrease programming times and improve programmed-device throughput.
The EFP and BEFP algorithms, as well as their equivalents from other manufacturers, reduce device-programmer-system overhead compared with traditional word-programming algorithms. These proprietary algorithms accomplish this objective by, for example, sending a single program command to the flash memory to program an entire block. This efficiency gain reduces the time required to send program commands for each word location. Proprietary algorithms also eliminate the programmer system requirement to send address vectors for each memory location to be programmed; instead, they require that you send only the first address location to the flash memory. The flash memory automatically increments an internal address counter for each subsequently programmed location.
EFP, BEFP, and equivalent algorithms also integrate postprogram verification operations, thereby enabling device programmers to rely on the flash memory to verify that it is properly programmed and consequently reducing overall programming times. A comparison of BEFP times for an Intel 28F128K3C device on three device programmers versus traditional write-to-buffer times reveals that BEFP improves programming times by 19 to 32% on the world's quickest programmers (Figure 3).
