© 2008 BPM Microsystems Confidential and Proprietary

Factory Preprogramming Solutions for NAND Flash Devices
Dragon Zhang Thank you for your attendance today. I’m going to speak about taking your Flash-based product into mass production and some of the challenges you might face, particularly with preprogramming NAND. © 2008 BPM Microsystems Confidential and Proprietary

What Is Factory Preprogramming?
Factory preprogramming is the writing of initial data content into a non-volatile memory device. The memory devices are usually virgin blanks straight from the semiconductor distributor. At the very least, factory preprogramming provides the “bootstrapping” necessary for the embedded system. Let’s start with a brief overview of Factory Preprogramming. It can be thought of as the initialization of a non-volatile memory device with code or data that a target system needs to “get up and running”. It solves the “Chicken and Egg” problem. For an embedded system to be able to read and write to NVM, it must execute some code – how then, is this code going to be written to the NVM. © 2008 BPM Microsystems Confidential and Proprietary

Example Preprogrammed Content
Store-and-download SnD boot loader OS, System Firmware Preloaded user content: Applications Pictures, Music, Movies GPS Maps Unique / Dynamic content: Serial Numbers Network addresses Encryption keys The content that is preprogrammed can be “just the bare necessities” such as firmware code, or it can encompass much more. Even if the target system is capable of programming additional bulk data content on its own, preprogramming bulk data may have certain performance advantages. © 2008 BPM Microsystems Confidential and Proprietary

The Hidden Added Cost Per Device
Devices per Hour (DPH) The number of successfully preprogrammed devices that a process can produce in an hour. Aka Units per Hour. Outsourced Programming Fees Additional charge to preprogram your data. Price depends on DPH and volume. $ $1.00 per device typical range. Production beat rate The speed at which preprogrammed devices can be produced will affect the cost to produce your product. Typical charge is based on 8Gb SLC in volumes from 50,000 to 1,000 Beat rate is the time between product output on a production line. Device programming can be significant bottleneck. It is not uncommon for the time to preprogram a single flash device to exceed the total time to manufacture the board, including paste, stuff, solder, inspection, and test. © 2008 BPM Microsystems Confidential and Proprietary

Factory Preprogramming Methods
Offline / In-Socket In-house Outsourced Manual Automated (Pick & Place) ISP / ICP Via Connected Target System Via Test Port (eg JTAG) Via In-circuit test (ICT) system There are two primary ways that you can choose to preprogram your nonvolatile devices. There are subtle variations to each, but these are the main two. Essentially, before the device is soldered onto the board (in isolation), or after the device is soldered onto the board. ISP = In-System Programming. Program the device using the same electronics on the board that will be controlling the device in the field. ICP = In-Circuit Programming. Program the device using externally attached electronics, such as a flying-probe, bed-of-nails, JTAG controller. © 2008 BPM Microsystems Confidential and Proprietary

Offline In-Socket Performance Advantage Isolated Device Concurrency + Gang Scalable Eliminate failures before solder process Easy to outsource. Or, handle in-house. Dedicated in-socket programmer systems can leverage the performance advantages of an electrically isolated device. Power and impedance control enhance high-speed digital signaling. Program several devices at once, independent of other sockets. Add more sockets to increase capacity at any time. Only devices achieving 100% verification with your design’s data pattern and bad block requirements will be binned as passed. Devices that don’t will never be placed in circuit. Outsource: Distributors and programming centers offer preprogramming service. No capital equipment to buy. In-house: Control quality and minimize inventory. © 2008 BPM Microsystems Confidential and Proprietary

In-Circuit / In-System
It’s how the design engineers did it. But you’ll need more than the “DevKit”. Can you reuse your embedded code? 40+ minute programming times are common In-Circuit-Programming methods involve preprogramming the device after it has been soldered onto the board. It can be beneficial to use the board’s hardware and software to preprogram the device, though this is not always possible. Usually, a dedicated in-socket preprogramming system is going to be able to program and verify NAND flash much faster than the embedded system that uses it. Yes, that says 40 minutes. Unfortunately we hear horror stories like this at the 11th hour from people trying to use JTAG or a similarly slow serial interface to preprogram big flash. This is not to bash ICP. ICP/ISP can make a lot of sense for some applications – big NAND is not typically one of them. © 2008 BPM Microsystems Confidential and Proprietary

“This Sounds Like Production’s Problem”
What’s all of this have to do with designing flash-based products? Your NAND driver choices will have an impact on the manufacturability of your product. Your decisions on NAND control during the design phase can mean the difference between turn-key factory preprogramming and weeks of delays. It really happens! You’ve got tougher problems to solve anyway! As we will see, with NAND you can’t simply transfer your image file to production like you could with other devices… there is more to it. How the NAND device is preprogrammed is determined by how you access and control it in-circuit. And like standards, there are so many to choose from  © 2008 BPM Microsystems Confidential and Proprietary

Preprogramming Considerations - NAND Flash
Type Is it raw SLC, raw MLC, or managed? If managed, is it consumer card or SMT packaged? Standard or proprietary interface? Huge Device Densities Data Pattern file logistics (Gigabytes) Program Disturbs Data Output  Data Input, but not always an error! Bad Block Management Programming NAND flash requires some special considerations beyond that of “conventional” non-volatiles. Knowing what you are going to deal with is half the battle. First, determine what type of NAND flash your application is using. You aren’t going to be able to your data pattern! You might not even be able to burn to CD or DVD, or FTP. Will your revision control system handle these huge files? MLC NAND is the first nonvolatile memory device where you cannot program your data pattern with 100% success. BBM adds a whole new category of requirements, unique to NAND flash. We will visit this in more detail. © 2008 BPM Microsystems Confidential and Proprietary

Raw NAND Types Single-Level Cell (SLC) Fastest NAND Flash No disturbs during preprogramming Multi-Level Cell (MLC) More memory, but less speed, less intrinsic reliability 1-bit disturbs certain, 2-bit likely Preprogramming verification must tolerate a specified number of bit errors or yield will be 0% Raw NAND requires an extra algorithm plug-in for Bad Block Management There are two types of “raw” NAND. Though there is an interface controller, it only handles low-level E/P/R operations of the memory array. Higher-layer operations such as bad-block management, wear-leveling, and error-management are duties of the host system. SLC is more reliable, faster, and more costly per bit than MLC. MLC is available in much larger densities than SLC at a cheaper price per bit, but you give up speed and reliability. These reliability issues affect preprogramming. Though SLC certainly has the potential for disturb issues, it has always been assumed that these errors would not manifest during factory preprogramming with new devices. © 2008 BPM Microsystems Confidential and Proprietary

Managed NAND Types Consumer Card Surface Mount Package
CF, SD, MMC, MS Surface Mount Package “Embedded” eMMC, moviNAND, iNAND Internal controller interfaces to Raw NAND and handles all BBM. Preprogrammer merely interfaces to standardized controller. Preprogramming performance can range from much slower to slightly faster than Raw. It depends on # of die, the raw types internal to the card, the speed of the controller, and other tricks specific to the raw devices that the controller can exploit. Well-established consumer electronics driven interfaces: “My cell phone can be used a managed NAND preprogrammer” Mostly used to store bulk data. I’m not aware of any designs that actually boot from eSD/eMMC. There is usually a small NOR device lurking nearby. Socketing and Pick-and-Place equipment the main difference between Consumer and Embedded for preprogramming. More elaborate consumer card programmers called “Flash Card Copiers”. Easy to preprogram. No extra algorithms necessary! © 2008 BPM Microsystems Confidential and Proprietary

Performance Comparisons
Throughput based on actual times to Program and Verify the entire device, not just a page or two or some burst. Times are typical for well-performing devices. Some part numbers are slower. Potential DPH = (P+V Mb/s) / (Mb) * 3600 * #ofSockets. “Potential DPH is determined using the P+V speed, the size of the device, and the number of preprogramming sockets executing concurrently” DPH examples using single site, 4-socket programmer MLC (8448Mb “8 Gb MLC”): 45 DPH SLC (8448Mb “8 Gb SLC”): 108 DPH Managed (32769Mb “32Gb”): 8 DPH © 2008 BPM Microsystems Confidential and Proprietary

What is Bad Block Management (BBM)?
NAND ships from factory with bad blocks, and a scheme must be employed to deal with that. The system preprogramming the NAND must do it exactly the same as the target system. It’s the biggest challenge to ramping up volume preprogramming of NAND. Plan ahead at design time and it won’t be a problem at production time. We all know by now that NAND ships with bad blocks, and will develop more bad blocks during the lifetime of the system. What is important for preprogramming, is that the system preprogramming the NAND device must perform the elements of bad block management no differently than the target system that the NAND device will be soldered into. Failure to get all of the subtleties correct will result, in most cases, in a system that will not boot or properly execute its application. © 2008 BPM Microsystems Confidential and Proprietary

Raw NAND Requires 2 Algorithms
The conventional programming support flow has existed since probably the late 70’s, and remains unchanged – except for NAND. The NAND BBM algorithm is a user-selectable plug-in to the device programming algorithm. Many OEM’s require that their BBM algorithm can be configured to operate with any stock device algorithm. This allows the flexibility to utilize multiple NAND part numbers to control costs and lead-times. The hassle in all of this, is getting accurate and complete information about a particular customer’s BBM algorithm. © 2008 BPM Microsystems Confidential and Proprietary

Who specifies the BBM Algorithm?
The provider of the FFS software that you integrated? Some undocumented open-source FFS software? The FFS or driver software that you wrote yourself? The MCU/chipset vendor? The NAND Flash vendor? The hardware IP provider? Some combination of the above? The most common answer: “I don’t know.” Unlike semiconductor devices, which have clear & obtainable specifications (usually) furnished by the same company that produces the device, BBM algorithm specs can be elusive. What can be tricky about open-source software, is that various layers can contribute a portion of the whole algorithm. This can make it difficult to nail down exactly how the device needs to be preprogrammed. For example, if you are using a Qualcomm MSM chipset, then you really don’t know or need to know many of the details regarding the BBM in your system code. Qualcomm supplies libraries and tools to configure and build everything. The preprogamming system though, has to know it *exactly*. © 2008 BPM Microsystems Confidential and Proprietary

Six BBM Preprogramming Elements
Bad Block Replacement Strategy Partitioning Error Correction Codes (ECC) Spare Area Placement Free Good Block Formatting Dynamic Metadata To help with specifying BBM algorithms completely for preprogramming, I have identified six areas of interest. Each element will be presented in more detail. © 2008 BPM Microsystems Confidential and Proprietary

Skip Bad Blocks When a bad block is encountered, simply skip ahead to the next good block. No tables, no tags. Simple Suitable for preprogramming and WORM applications. Most FFS’s will require more sophistication at runtime. Good Bad SBB is the most basic and straightforward replacement strategy. It is the most prevalent method used during preprogramming. There are many designs in the field using SLC for giant ROM type applications, and SBB works well for that. For applications that will be reading AND writing to NAND, SBB is not adequate, since BB’s that appear in the field would cause the subsequent good blocks to have to shift to the right. Many FFS’s are preprogrammed with SBB, then resort to more complex BBR methods at run-time. © 2008 BPM Microsystems Confidential and Proprietary

Reserve Block Area (RBA)
A portion of the flash memory is set aside to replace bad blocks. When a bad block is encountered, redirect the data to a replacement block in the RBA, then resume. Usually requires a mapping data structure. Good Bad End of Device RBA is one example of a slightly more advanced BBR strategy over SBB. Some FFS’s require that this method is used during preprogramming. FFS’s using RBA are generally more proprietary in nature. The BBM algorithm plug-ins are not reusable and so require new preprogramming algorithm development. © 2008 BPM Microsystems Confidential and Proprietary

Partitioning for SBB Block 0 1 1 block 2 blocks 10 blocks 6 blocks 2017 blocks 2 4 5 14 24 25 30 2047 Bootstrap Bootloader OS File System Padding Cleanmarkers Partitioning is required to prevent regions from encroaching on adjacent regions when bad blocks occur. Allows you to guarantee a fixed starting block for IPL, bootloaders, FFS mounts, etc. Designs using NAND flash will often divide the memory into various physical regions, called partitions, much like the partitions on a PC hard-drive. One thing that partitions make possible, is the ability to guarantee that a particular piece of data will reside at a predetermined physical block location, regardless of the number of bad-blocks that occur before it. You might recall from one of the previous slides that bad-blocks cause the data pattern to “scoot over” one or more blocks when using SBB. This can pose a problem for low-level software components that must easily locate the beginning of a region of data. In this hypothetical system example, the microcontroller is hardwired to begin loading and executing 1 blocks worth of code starting at block 0. This bootstrap code isn’t very sophisticated. It is hard-coded to begin loading the OS bootloader from block 1, but it does have enough intelligence to at least skip over bad blocks by inspecting each block’s bad-block marker as it loads the block. Once the bootloader begins executing it expects the compressed OS image to be located at block 5, and so on and so forth. As you can see, this design sets aside 2 blocks worth of padding in the bootloader, 10 blocks in the OS image, and 2017 in the file system. What this means is that up to 2 blocks can be bad in the bootloader partition without causing an encroachment upon the OS partition. Therefore, when preprogramming a NAND device with these requirements, if 3 or more bad blocks occurred on a particular device in blocks 1-4, then the device would have to be rejected since it would not function correctly in-circuit. It should be noted though, that the device is not defective – it could still be well within the maximum bad block spec from the semiconductor manufacturer. © 2008 BPM Microsystems Confidential and Proprietary

Partitioning for RBA Defines the User Block Area and Reserve Block Area allocations. Bad blocks don’t disrupt the physical location of data on good blocks. Block 0 1638 blocks 2 blocks 408 blocks 1637 1638 Metadata, BB Table User Block Area 2045 Reserve Block Area RBA does not suffer from the same “block shift” phenomenon as SBB, since bad blocks are redirected to a reserve block area, and then data storage resumes uninterrupted. Partitioning for RBA is generally used to simply establish the so called “User Block Area” that will be filled with the data pattern content, as well as establishing the size of the RBA. The size of the RBA defines how many bad blocks the application can handle during preprogramming, as well as in the field. This might be less than the semiconductor manufacturer’s max bad block spec, in which case the preprogrammer must reject devices that fail to meet that requirement. Some RBA schemes might also need special metadata locations defined, often for bad block mapping tables, etc. 2046 2047 © 2008 BPM Microsystems Confidential and Proprietary

Specifying Partitioning
Specify the details of your NAND partitioning to manufacturing or programming center. Or, use tools that emit partition tables and furnish the file. To summarize, partitions are used to express the physical layout requirement of data on the NAND device. This is often used to reject otherwise good devices that wouldn’t function properly in-circuit. Hopefully you can now see how critical it is to accurately specify your design’s partitioning requirements to manufacturing. Partitions are defined with 3 simple parameters each: Physical Start & Stop Block locations And the Image Size. The Image Size defines the number of required good blocks within the partition. The remaining blocks are considered Free Good Blocks that are not required to be available on the NAND device. Many development tools, such as Qualcomm’s, will generate a partition table file that can be loaded into the preprogrammer along with the data pattern. © 2008 BPM Microsystems Confidential and Proprietary

ECC Calculated values that allow for detection and correction of bit errors in the original data. Preprogrammer must write the ECCs exactly as the target system expects. Definitively specifying an ECC algorithm: Hamming, Reed-Solomon, BCH Additional parameters, sub-pages, hybrid schemes Most embedded system designers cannot fully specify the ECC used in their NAND control system. ECCs should be pre-encoded for static data pattern content to boost DPH. Most designs simply will not function if the NAND is preprogrammed without correct ECCs. Designers simply do not know the details of how their application’s ECC algorithm works. Furthermore, they may not have access to this information. Here’s a secret: ECCs are only good for checking the integrity of the data when you don’t know what the original data is! So, why waste production time computing ECCs on the fly? ECCs are of no value when you have the entire data pattern available and can perform a 100% verification. © 2008 BPM Microsystems Confidential and Proprietary

Spare Area Placement Aka Out-Of-Band (OOB) Area How are the ECC bytes arranged? Bad Block Marker(s) Other metadata 2048 64 BB Marker FFS Metadata ECC0 ECC1 ECC2 ECC3 ECC4 ECC5 ECC6 ECC7 Main Spare . . . The spare area is an extra 3% or so of storage space at the end of every NAND page. At the very least, ECC bytes are stored here, as well as the factory bad block markers. Spare Area Placement defines the content and layout of the spare area. For many older FFSs, the spare area is used to contain pieces of information to manage erase counts, physical-logical mappings, cleanmarkers, etc. For more modern FFSs that are compatible with MLC, such as UBI, there is no additional spare area metadata, since the ECC consumes nearly all of the spare area. Example diagram is for a 2KB page size NAND. It is typical for the ECC information to be dividing into 8 subpages © 2008 BPM Microsystems Confidential and Proprietary

Free Good Block Formatting
What to fill the unused good blocks with. For every bad block on the device, one block of FGBF will be discarded. Common Examples: 0xFF / Blank Padding – Completely blank pages are not programmed, just blank checked. This is the most common FGBF. JFFS2 Cleanmarkers If a particular NAND device contains fewer bad blocks than the maximum allowed by the partition, then there will be unused good blocks after the image data. We refer to these as “Free Good Blocks.” Most applications simply leave unused good blocks completely blank. This is specified in the data pattern by simply filling in 0xFF for each potential free good block. Note that the preprogrammer must not actually program completely blank pages as this could violate ‘Partial Page Programming’ rules regarding blank pages, especially for MLC. © 2008 BPM Microsystems Confidential and Proprietary

Dynamic Metadata Additional computed data written to the device based on the individual DUT. Includes information such as: Filesystem headers, erase counts, logical-physical mappings, etc. Customized bad block tables Other unanticipated crazy stuff Some BBMs require additional information specific to a unique device, such as a bad block remap table. This must be generated by the preprogrammer and written to the device in a particular location. Sometimes the metadata content is static, but where it must be written is device-specific. In this case the device programmer must calculate “where” to write the information on a device-by-device basis. © 2008 BPM Microsystems Confidential and Proprietary

Confidentiality and IP Issues
Who owns the IP of your BBM algorithm? Many hardware and software vendors will not disclose to you the details of their BBM and/or ECC algorithm. Don’t delay your product launch while lawyers execute NDAs. It really happens! Quite often, system designers are abstracted away from the details of all or a portion of the BBM elements taking place in their design. This is very typical with commercial software and hardware or IP controllers. ECCs and SAP tend to be the biggest trouble, when they aren’t contained in the data pattern. Unfortunately it is an all too common scenario where: Design team releases product to manufacturing/EMS. Provides NVM data pattern images. Manufacturing/EMS outsources preprogramming of NVM’s. Programming center obtains devices, device algorithms, and socketing. Program’s devices & ships them. Manufacturing builds the boards. They won’t boot during test. Design team determines that NAND devices are failing ECC checks and bad blocks have been replaced incorrectly. Programming center contacts preprogrammer vendor. Determined that wrong BBM algorithm was used. Asks design team which BBM algorithm they should be using. Design team’s reply is “We use VendorX’s hardware chipset to boot from and control the NAND” Preprogramming vendor contacts VendorX regarding BBM algorithm. No response or dismissive response. Want’s to know the end customer before dealing. Programming center does not want to divulge their client’s identity to the preprogramming vendor. So they set out to obtain the spec in coordination with the product design team. Spec requires NDA between VendorX and preprogrammer vendor. Conference calls ensue, lawyers step in, weeks go by. © 2008 BPM Microsystems Confidential and Proprietary

Universal BBM for Preprogramming
BBR: “Skip Bad Blocks” Partitioning: One or more partitions defined. ECCs: Pre-computed in the data pattern. SAP: All Spare Area bytes in the data pattern. FGBF: All unused block formatting or padding (FFh) in the data pattern. Dynamic Metadata: None! Many commercial, open-source, and proprietary BBMs adhere to this. This is the most ideal BBM scheme to use during preprogramming. Many FFS’s adhere to this, and convert to more complex schemes on the first system boot. Preprogramming in this manner will achieve the fastest DPH with no lead-time for the BBM algorithm. Note that 3, 4, 5 are accomplished by “putting it all in the data pattern”. Therefore, you don’t need to specify how to compute the ECC, arrange the spare-area bytes, etc. Qualcomm, for instance, has gone a step further and placed the partitioning information in the data pattern. We sometimes receive support calls from programming centers that have been provided just a binary file, without any of this other information. We are asked to figure it out from the file! So, its still important to state in writing these elements. If they exist in the data pattern file, say so! © 2008 BPM Microsystems Confidential and Proprietary

De facto Image File Conventions
Flat binary file. 1:1 mapping to device’s physical blocks, Main+Spare for each page. Contains full page data, all spare area content, including ECCs, needed for board bring-up. Includes all Free Good Block Formatting, even if it’s just blank padding. To support the Universal Preprogramming BBM, the image file must contain data for the main+spare area, arranged just like the physical pages on the device. When using partitioning, ensure that the data pattern contains a block of Free Good Block Formatting for every padding block in the partition. This is normally all blank-state, except for older FFS’s like JFFS2 that rely on cleanblock markers. Again, *most* image files these days are constructed according to this convention. © 2008 BPM Microsystems Confidential and Proprietary

NAND Drivers & FFS Considerations
Open-Source Ex: Linux JFFS2, UBI Commercial off-the-shelf (COTS) Software Ex: FlashFX, TargetFFS, CMX-FFS Hardware Controller + Software Ex: MSM7201, OMAP3530, Databahn+Spectra One-off / Roll-your-own Determine during the design phase preprogramming support for your FFS. Here is a short list of some example controller, driver, and file-system solutions. There are certainly many more to choose from. There is often more involved in the BBM scheme than just the FFS, including a NAND driver and/or NAND controller hardware. Preprogramming methods and support must be considered for these other aspects. There are a handful of popular open-source flash file systems out there. So far, from what I have seen, they all support the “Universal Preprogramming BBM”. JFFS2 and UBI are the most common, with UBI being the newer, more advance system that is compatible with MLC. Generally there are tools available to create a ready-to-preprogram image file. There is an even larger list of commercial FFS products out there for you to purchase. Some adhere to the “Universal Preprogramming BBM”, some do not. Before licensing a commercial FFS, ask to see a list of list of qualified preprogramming solutions, and be sure that adequate image generation tools are furnished. It is becoming increasingly popular for handheld device chipsets and microcontrollers to have dedicated NAND controller hardware. Hardware controllers generally provide fast ECC generation on writes, and fast ECC syndrome calculations on reads, as well as other accelerators tightly coupled to the driver software and FFS. Many controllers provide some level of boot-from-NAND support. Controller hardware is then combined with open-source or proprietary FFS software supplied by the semiconductor vendor. There are also hardware IP components combined with software libraries that you can purchase and implement in your FPGA or ASIC. Nailing down BBM preprogramming specs for systems designed in this manner can be particularly challenging, as the various elements might be implemented by different companies. © 2008 BPM Microsystems Confidential and Proprietary

BBM Algorithm Plug-ins
Generally any BBM algorithm can be combined in the field with any Raw NAND device algorithm. Part number changes are no problem. But beware of “one-off” or “esoteric” BBM schemes! If it can’t be coded using the defined abstractions, the alternative is to produce a combined BBM+Device algorithm. Higher development costs Longer lead times Can’t change the part number in the field. To combine a BBM algorithm with a NAND Device Algorithm, the user simply chooses the NAND part number to program, then selects a BBM from a list. New BBM algorithms are easily developed if the spec is available and comprehensive. Why is this important? Many products outlive the life cycle of the NAND devices, forcing part number changes in a mature product. © 2008 BPM Microsystems Confidential and Proprietary

Bit Error Rate Tolerance for Raw MLC
Before MLC, disturbs were a non-issue with factory-fresh devices. Now with MLC, programming a page will corrupt some bits in another page of the same block. Normally this is a verify failure. But with MLC you’ll get 0% yield. The preprogrammer must tolerate a certain number of incorrect bits per page during verify. Specify the BERT in bits per page for your application! Preprogramming raw MLC NAND devices brings a new complexity. Prior to MLC, even though program disturbs could occur, they did not occur when the devices were new, and therefore did not pose a problem during factory preprogramming. (There is an exception with one semihouse’s SLC devices, but I won’t name names) Program disturbs occur when programming one page corrupts the bits previously programmed in a different page. With brand new MLC devices, it is simply not possible to program the device, then turn around and read back all of the bits correctly. There will be errors. So you may ask, why can’t you just use my ECC – that’s precisely what it is for? We could, and many of our competitors do, but this most certainly slows down DPH and requires that your ECC algorithm be implemented in the preprogrammer. If it can even be specified fully, this will cost you money and take time. Using a BERT method is more universal and better performing. For raw MLC, in addition to the 6 BBM elements, be sure to specify how many bits per page your application can tolerate. That way, the device programmer will reject any devices that won’t function in circuit. Most ECC’s these days operate on a sub-page, such as 8, 256-byte subpages in a 2048 byte physical page, where the ECC can correct some number of bits in a subpage. If this is the case in your design, specify the BERT per subpage, and the size of the subpages. So far, the worst that we have seen with new MLC samples, is 2-bits per page of corruption. Generally the semihouse will factory mark the block bad if its worse than that. © 2008 BPM Microsystems Confidential and Proprietary

Design Tips Fully specify BBM to production: Six preprogramming elements BERT for Raw MLC Balance yield vs. waste for bad block allowances. Deliver standard image file. If you are designing an FFS, support the use of “Skip Bad Blocks Compatible” factory preprogramming. FFS vendors can help their customers and increase their product’s adoptability by adhering to this rule! When designing the amount of padding allowed for each partition, carefully consider Yield vs. Waste . If you allocate too much extra padding, you might have to spec a larger device or reduce the product’s capacity available to your customers. By decreasing the padding you may only sacrifice a negligible amount of devices, but gain an overall manufacturing cost savings. By contrast, if you cut it too close you may find that too many devices get sent to the reject bin. Of course, most FFS will use more sophisticated flash management algorithms in the application. If your FFS product requires specialized code in the preprogrammer, its not as compatible as those that don’t. © 2008 BPM Microsystems Confidential and Proprietary

© 2008 BPM Microsystems Confidential and Proprietary

Similar presentations

Presentation on theme: "© 2008 BPM Microsystems Confidential and Proprietary"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

© 2008 BPM Microsystems Confidential and Proprietary

Similar presentations

Presentation on theme: "© 2008 BPM Microsystems Confidential and Proprietary"— Presentation transcript:

Similar presentations

About project

Feedback