Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.

Performance Considerations

Several performance aspects can be considered when using the NAND driver. Depending on your priorities, you will need to configure and use the NAND driver in a proper way so that your specific goals are met. The different performance metrics include the write and read/speed, the RAM usage, the data safety level and the worst-case locking time.

Choosing an appropriate sector size

It is important to choose carefully the sector size for each device. Unless your device supports partial page programming, it is mandatory for the sector size to be identical to the page size or larger.

If your device supports partial page programming, it is possible for you to set a sector size smaller than the page size as long as it does not force the driver to exceed the maximum number of partial page programs. If this is not respected, the driver will fail the initialization phase and return an error code.

One of the advantages of choosing a sector size smaller than the page size is to reduce the RAM usage. The size of the buffers in the file system are based on the sector size. A large sector size implies large buffers.

For the best performance, the sector size should be in the ballpark of a typical transaction. If most of your write operations are a couple of octets, you should, if possible, choose a small sector size (typically 512 octets). On the other hand, if you want to obtain good transfer rates and you have large application buffers (with multimedia applications, for example), then the sector size should be set higher. The optimal choice will almost always be the same as the page size (512, 2048, 4096 octets).

Choosing error correction codes

Each device needs an error correction codes (ECC) module able to correct a minimal number of bits per codeword. Choosing a module that satisfies the minimum required level of error correction is often the best option if you want to avoid the extra calculation time of modules with enhanced bit error correction.

To reduce the calculation load on your CPU, it is recommended to consider using a hardware ECC module. This is especially true with parts that require more than 1 bit per codeword of error correction. These hardware ECC engines are often found in MCU and in NAND flash devices. Consult their datasheets to determine if you have access to such a feature.

If data safety is a concern, you can consider using an ECC module with better correction capacity. For most applications, the recommended level of correction is sufficient. However, using an ECC engine that can correct more bit-errors can improve long-term readability of the data, especially for cold data (that never or rarely changes). Another option is to reduce the codeword size. The same number of bit errors can be corrected, but since codewords are smaller, the bit error rate will be smaller. While those design choices will slightly improve reliability, they will also increase the overhead and hence reduce the read/write speed and increase the worst-case locking time.

Configure the translation layer

The configuration of the translation layer is complicated. Take the time needed to read carefully each description, and make sure you choose a configuration that is appropriate for your application. When, in most cases, the basic configuration will be enough, optimizing it will help you to reach your goals, whether they are about CPU usage, footprints, reliability or speed.

The translation layer configuration options are described in section 13-3-1 “Translation Layer Configuration” on page 173.

Considering another controller layer

Some MCUs have advanced peripherals that interface with NAND flash devices. If this is the case, consider using or developing a specialized controller layer implementation to take advantage of those peripherals and save some CPU time or increase performances.

  • No labels