嵌入式Flash（共7篇）
嵌入式Flash 篇1
1 引言
近几年来,随着人们对嵌入式设备越来越高的应用需求,32位嵌入式系统应用逐渐深入到各个应用领域。Flash存储器制造成本低廉、存储容量大、数据非易失、无机械故障,在嵌入式系统中被广泛应用,尤其以NAND Flash做为大容量数据存储。根据NAND Flash的物理结构特点设计有效管理NAND Flash的文件系统可解决嵌入式系统中的大容量存储管理问题。而对设计文件系统而言,算法设计是文件系统的核心部分。
2 闪存的物理结构
NAND闪存阵列分为一系列的区块(block),这些区块是NAND器件中最小的可擦除实体,每个区块包含一定数量的页。擦除一个区块就是把所有的位(bit)设置为“1”(而所有字节(byte)设置为FFh)。写操作就是通过编程,将已擦除的位从“1”变为“0”。读写以页为单位,页包含数据区和空闲区(OOB,out-of-band),OOB区用于纠错码(ECC)等软件开销。NAND闪存复用指令、地址和数据总线、串行地址存取数据和发指令,节省芯片引脚数,这种结构不用改变硬件设计就可支持更大容量的芯片。
对NAND的操作有页读方式:读数据区页和读OOB区,页写入、块擦除,将块全部字节编程为0xFF来回收空间。目前市场上NAND Flash可分小页闪存:主数据区512字节,OOB区16字节;大页闪存每块有64页,每页有2048字节的主数据存储区和64字节的OOB区。
3 文件系统中的算法
根据闪存的物理结构,NAND Flash上的每页都有额外的空间(OOB区)用来存储附加信息,文件系统正是利用了这部分来存储文件系统相关的内容。
3.1 基本思想
文件系统上的所有内容(比如正常文件,目录,链接,设备文件等等)都统一当作文件来处理,每个文件都有一个页面专门存放文件头,文件头保存了文件的模式、长度、文件名、父对象标示等信息。NAND Flash的基本写入单位是页,文件系统在分配存储空间的时候也是以页为单位的,不过在文件系统中被称做chunk,其大小同NAND Flash中的Page一样大,但实际上它们意义不同,Page所指的是NAND Flash Memory上的实际数据储存区,而Chunk所表示的是文件系统所配置到的逻辑数据储存区对象,chunk的大小可以和Page不同。
以512+16Byte为一个PAGE的NAND Flash芯片为例,文件系统数据的存储布局如表1所示。
在这里一共使用8个Byte用来存放文件系统相关的信息(jkffs_Tags),这8个Byte的具体使用情况按顺序见表2。
在加载过程中需要将文件系统的目录结构在内存中建立起来。扫描每一个chunk。因为chunk通过OOB数据区来存放文件的信息,所以在扫描时不需要扫描整个chunk,而只需读取00B中的内容,这样可以大大加快系统的加载速度。根据从OOB中读取出的jkffs_tags信息来判断是文件头chunk还是数据chunk。然后根据文件头chunk中的内容以及数据chunk中的objectID、chunkID等信息在内存中为每个文件建立一个对应的对象。在扫描完所有的Block后,会把Flash内的所有File、Directory、SoftLink或HardLink建立成对应的jkffs_Object,并建立jkffs_Object之间的关系,这样就在RAM中形成一种架构,文件系统在RAM中加载成功。
3.2 文件系统的寻址
系统想要存取设备上的数据时是以Logical Address(相对于该文件所产生的偏移位址)的方式到所指定的地址进行存取,若想要到物理设备上取数据,则需要再经过转换,将Logical Address转换为Physical Address,才可从物理设备上读出数据至RAM中。
如何根据文件内偏移地址确定Flash存储地址呢?通过创建节点树可实现高效的寻址。我们先看结构定义:
这是一个长度为8的指针数组。据此结构创建的节点树最底层的节点成为叶子节点,中间的就是非叶子节点。不管是叶子节点还是非叶节点,都是这个结构。当节点为非叶节点时,数组中的每个元素都指向下一层子节点;当节点为叶子节点时,该数组拆分为16个N位(位宽,TnodeWidth)长的短整数,该短整数就是文件内容在flash上的存储位置。
最底层节点即叶节点中一个Tnode的位宽决定了文件系统所能寻址的最大空间,假设为TnodeWidth=16,也就是可以表示216=65536个chunk。对于时下的大容量NAND Flash,chunk的大小为2KB,因此这种情况下所能寻址的最大Flash空间就是128MB。为了能使文件系统用于更大容量Flash上,可以通过两种手段解决这个问题。第一种手段就是这里的TnodeWidth,通过增加单个Tnode的位宽,就可以增加其所能表示的最大chunk ID;另一种手段是采用chunk组,通过将若干个chunk合成一组用同一个ID来表示,也可以增加系统所能寻址的chunk范围。
文件系统通过节点树来查找文件是非常简单和方便的。中间节点使用的Tnode每组有8个指针,所以需要3位二进制代码对其进行索引,因此树每长高一层,chunkID就会多出3位。反过来,每3位非零chunkID就代表一层非叶节点。同时。叶节点使用的Tnode每组有16个指针,所以需要4位二进制代码对其进行索引。
根据上面所述可以得到下面的方法:对将要查找的文件的chunkID按照每三位分为一组,LEVELO的用四位表示。比如要查找chunkID为0x235的文件,须先将其划分为000,000,100,011,0101。通过表3可以看出所要找的这个page应该是在第二层的节点到1层的第4节点到。层的第三节点这颗子树上,也就是O层该节点的第5个与所指向的那个chunk。
当节点树结构TNode Structure刚开始建立时,仅建立最底层Lowest-LevelTnode,当File所配置的chunk数超过16个时,则此Tree会建立一个中间节点internal Tnode,并将其第0个Pointer指向原本的Lowest-Level Tnode。当读取到的chunk数愈來愈多时,会一直新增Tnode,且节点树也会越来越高。
假定有一个大小为128KB的文件,Flash的page大小为2KB,那么就需要64个page(或者说chunk)来存储该文件。一组Tnode的size是8个指针,或者16个16位整数,所以需要64/16=4组Tnode来存储物理chunk序号。这4组Tnode就是映射树的叶节点,也就是Level0节点。由于这4组Tnode在内存中不一定连续,所以需要另外一组Tnode,将其作为指针数组使用,这个指针数组的前4个元素分别指向4组Level0节点。随着文件长度的增大,所需的叶节点越多,非叶节点也越多,树也就越长越高。
3.3 节点树底层节点动态位宽
节点树底层节点位宽决定了文件系统所能寻址的最大空间,chunk的大小为512byte,那么32M NAND Flash需要65536个chunk,也就是需要大小为16bit的index来检索chunk。则64M NAND Flash至少需要17bit的index来检索所有chunk;128M NAND Flash至少需要18bit的index来检索所有chunk。实际上,为了便于处理规定Tnode的大小tnodeSize必须为32bit的倍数,tnodeSize=(tnodeWidth*16)/8,单位为Byte。其中tnodeWidth表示位宽,因为level 0的Tnode为16个physical chunk index。由上可知tnodeWidth为physical chunk index的大小,单位为bit。要使tnodeSize为4Byte的倍数,那么64MB flash的chunk_index_bits最小取18bit。这样tnodeWidth=18就能直接寻址128MB。
为了管理目前市场上各种主流的大容量NAND Flash,考虑增大位宽,比如tnodeWidth=20,以大页NAND Flash例,这样文件系统能寻址的最大空间:220*2KB=2GB,基本上能管理目前市场上主流闪存存储器芯片。但是这样建立的节点树占用了嵌入式系统中RAM的更多的空间,对系统性能有影响,而且对设计千变万化的嵌入式系统显得不够灵活。
在系统初始化过程中先读取NAND Flash信息,用闪存的总块数(nBlocks)乘以每块含有的页数计算出闪存所含有的总页数,也就是说文件系统需要管理这些页,然后计算出节点树底层节点位宽(tnodeWidth),具体算法如下:
(1)计算出总页数x=nChunksPerBlock*nBlocks。
(2)保证x大于1的情况下,对x右移1位,同时bits加1。
(3)重复(2),直到不满足x大于1。
(4)若bits为奇数,bits加1。
流程图如图1。
Bits值即为位宽,赋值给位宽(tnodeWidth)。这种方式解决了设定固定位宽占用系统RAM多的问题,能够做到管理市场上各种主流NAND闪存存储器。
在实际系统设计过程中,如果bits过大,可考虑使用chunk数组,采用一个chunk对应多个page方式,减少tnodeWidth值而达到同样的管理NAND闪存的目的。即使用chunk数组来增大文件系统的寻址范围,即通过将若干个chunk合成一组用同一个ID来表示,也可以增加系统所能寻址的chunk范围,这时,chunk的大小Page不同,假设一个chunk对应二个Page,把两个连续的页称为d_Chunk,包含1024字节数据(小页),这时d_Chunk[0]、d_Chunk[1]分别对应相应的页。
4 结语
NAND Flash凭借速度快、容量大、价格低等很多优点,成为嵌入式系统首选存储介质,尤其广泛应用于各种工业控制领域。目前最合理的管理NAND闪存的文件系统大多采用日志结构的设计思想,如jffs、yaffs等。本文件系统是在YAFFS2的基础上开发完成的,提出并应用了动态位宽、页数组等概念,实验证明能够灵活管理主流大容量Flash存储介质。
参考文献
[1]Samsung Corp.Flash Memory K9XXG08UXM DataSheet[S],Nov.2005.
[2]胡勇其,侯紫峰.嵌入式Linux下NAND存储系统的设计与实现[J].计算机工程,2006,(2).
[3]http://www.aleph1.co.uk/.
嵌入式Flash 篇2
作者： WuYJ@263.net.cn
摘要：设计一种能够在典型嵌入式环境下应用的线性文件系统，为嵌入式系统Flash空间的管理提供一种非常有效的手段。它包装和通用文件系统类似的API接口，设计的实现独立于实时操作系统(RTOS)和具体的Flash典型，可方便移植到不同的嵌入式应用中。
在嵌入式系统中，为了便于对闪存(Flash)空间进行管理，会采用文件的形式来访问Flash。目前，可以购买到的Flash文件系统一般都是兼容DOS的文件系统(Flash File System，FFS)，这对需要一个具有复杂的目录层次，并且DDS文件兼容的系统来说是必要的;但是对大多数的嵌入式应用来说，这种文件系统太过奢侈。笔者在参与嵌入式系统项目的时候，设计了一种线性文件系统，它适用于大多数的嵌入式应用对Flash文件系统的需求。
线性文件系统设计基于三个目标：一是提供给应用程序通过文件名而不是物理地址访问系统Flash的能力;二是文件系统的设计独立于实时操作系统(RTOS)，这样可以很容易移植到不同的嵌入式应用中;三是设计统一的底层接口，适应不同的Flash类型。本文设计的线性文件系统为典型的嵌入式系统提供了所需的类文件系统能力。需要注意的是，本文件系统不支持复杂的Flash扇区擦写次数均衡算法，没有目录层次，并且和其它的文件系统不兼容。
1 线性文件系统
线性文件系统的设计思路是这样的：文件分为文件头和文件数据区两个部分，每个文件按照顺序存放在Flash中，以单向链表来链接文件。文件的起始部分是文件头，包含文件的属性、指向下一个文件头的指针、文件头和文件数据区的32位循环冗余校验和(CRC32)等。文件头用一个32位的字来表示文件属性，每位表示一种属性，如数据文件或者是可执行文件，是否已删除的文件等，具体可以根据应用的需要来定义文件的属性;文件头和文件数据区维护独立的CRC32校验，使文件系统能更精确检测文件的完整性。文件的起始地址没有特殊需求，分配给文件系统的Flash大小限制了文件的大小。另外，线性文件系统作为嵌入式系统的一个功能模块，它为应用程序提供与标准文件系统类似的API接口，如：read()、write()、open、close()、stat()和seek()等。对于同时在多片Flash的系统而言，每片Flash相当于一个目标，文件都可存储在任何一片中(当然受物理空间限制)，但不能跨片存储。
图1 Flash文件系统空间
在第一个文件创建之前，必须进行初始化，将所有分配给文件系统的`Flash空间擦除。当创建第一个文件时，起始位置从文件系统的起始地址开始，文件头指针指向下一个空文件的起始位置(链表尾部);第二个文件的位置从当前的链表尾部开始，同时文件头中的链表指针指向新的尾部。删除文件时，仅仅是简单地把文件头的标识位中的活动文件标识位置0，表示删除。这样，在经过多次删除之后，就有必要运行碎片整理模块来进行文件系统Flash空间的碎片整理。碎片整理模块还需要在文件系统Flash空间尾部留一个扇区来数据备份，以便当碎片整理被打断时(如下电或者复位)可以恢复文件系统。这个保留的扇区称空闲扇区。它必须放在文件系统空间之后，这样可以保证文件系统的所有文件在所占用的Flash空间是连续的。整个文件空间的分配如图1所示。
阴影部分是文件头，数据结构如下：
struct hdr{
unsigned short hdrsize; /*文件头字节数*/
long filsize; /*文件头版本*/
long filsize; /*文件大小*/
long flags; /*描述文件的标识*/
unsigned long filcrc; /*文件数据的CRC32的值*/
unsigned long hdrcec; /*文件的最后修改时间*/
struct hdr *next; /*指向下一个文件头的指针*/
char name[NAMESIZE]; /*文件名*/
char info[INFOSIZE]; /*文件描述信息*/
};
碎片整个记录区包含两种数据类型：碎片整理文件头信息表defraghdr和文件区扇区整理前后的CRC值备份表sectorcre。具体的地址分配从空闲扇区的起始地址减1开始，往前分配文件系统扇区数乘以4字节作为sectorcrc的空间;从sectorcrc起始地址减1开始，往前分配活动文件个数乘以64字节作为碎片整理文件头信息表。这两个结构定义如下：
struct defraghdr{
struct hdr *ohdr; /*文件头的原始位置指针*/
struct hdr *nextfile; /*指向下一个文件的指针*/
long filsize; /*文件大小*/
unsigned long crc; /*这个头的CRC32值*/
unsigned long ohdrcrc; /*原始文件头CRC32值的拷贝*/
long idx; /*碎片整理表头的索引*/
long nesn; /*新的文件尾的扇区号*/
long neso; /*新的文件尾的扇区偏移量*/
char *nda; /*新的文件起始地址*/
char fname[NAMESIZE]; /*文件名*/
};
struct sectorcrc{
unsigned long precrc; /*碎片整理前扇区数据CRC32的值*/
unsigned long postcrc; /*碎片整理后扇区数据CRC32的值*/
};
从上面介绍可知，除了文件数据之外，文件系统还需要如下4种额外的开销。
①文件头：这是每个文件必须的开销，如果文件名和信息域各24字节，那么整个文件头共76字节。
②碎片整理文件头信息表：每个活动(非删除)的文件在进行碎片整理时在这个表里创建一个表项，每个表项64字节。
③碎片整理前后的扇区CRC32值表：保存文件整理前后的CRC32值，总的字节数约为文件所占扇区数的4倍。
④空闲块：用来在碎片整理过程中备份当前整理扇区数据。它必须不小于文件系统其它所有扇区。
可以用下面方程计算系统开销的总和：
overhead=(FTOT*(HDRSIZE+64))+SPARESIZE+(SECTORCOUNT*8)
其中：
FTOT是总的文件数;
HDRSIZE是文件头字节数(目前为76字节);
SPARESIZE是空闲块的大小;
SECTORCOUNT是分配给文件系统的Flash扇区数，不包括空闲块。
图2 文件碎片整理
2 碎片整理
创建新文件需要占用文件系统空间;但是，由于Flash的底层技术不允许Flash中的任意地址空间被删除，而是按照扇区为单位删除，为此在删除一个文件的时候，暂时没有把整个文件所占的空间删除，仅仅是在文件头的标识里作一个删除标识，并保留在Flash中。这样，被删除文件积累到一定的数量时，就会占用相当大的空间。因此，需要整理文件系统Flash空间，使被删除文件占用的空间重新使用。图2显示了碎片整理过程。文件F1、F2和F5已经被删除，并且在碎片整理之后从Flash中被清除。
进行碎片整理的方法可以有多种。对于嵌入式系统来说，选择哪种方法，衡量的依据是复杂性和功能之间的平衡。下面讨论两种不同的方法：第一种方法相当简单，但是有缺陷;第二种方法功能强大得多，笔者在线性文件实现中即采用这种方法。当然，存在更加复杂的解决办法，但通常的情况是，所添加的复杂性会使整个文件系统的实现更加复杂。目标是保持文件存储的简单和线性，保证所有的文件都是以连续的空间存储在Flash中。
最简单的方法是将活动的文件备份在RAM中，删除分配给文件系统的Flash空间，然后将RAM中备份的所有文件拷贝回Flash。这种方法很简单，并且不需要分配一个扇区作为空闲区;但问题是，需要有一整块和分配给文件系统的空间一样大的RAM来完成这项工作。更糟的是，如果此时系统被复位，或者在删除扇区内容却还没有将文件拷贝回Flash的时候被断电，文件系统将会崩溃。因为RAM中的内容会随之选择，文件内容会被破坏掉。
我们在文件系统实现设计了一种碎片整理方法，可以防止在碎片整理过程中系统复位导致文件崩溃的情况。采用这种方法，不需要大块的RAM，但是需要预选先分配给碎片整理过程一个Flash扇区作为备份区。这个扇区的字节数不小于任何分配给文件系统的扇区。在整个文件系统中，这个扇区位于分配给文件系统最后一个扇区的下一个扇区。因为扇区可能比需要分配给非删除文件的备份的空间要小，所以它必须逐个扇区进行处理，而不是一下就把所有的碎片整理完。采用备份扇区的好处是，在碎片整理过程中，无论断电或者复位都不会破坏文件系统。当下次系统重新恢复时，会根据在碎片整理前记录的每个扇区碎片整理前后CRC值，来判断当前的文件碎片整理状态。如果上次文件整理没有完成，就会继续上次的整理。这种技术的一个缺陷是空闲扇区的擦写次数会较多。这样空闲扇区就可能因为达到擦写寿命而失败。达到这一点的关键依赖于使用的Flash、所分配给文件系
统的扇区数、文件删除和重建的频率。一个可行的解决办法采用电池备份的RAM来替换空闲扇区，可以增加Flash的整体寿命，但是对那些预算紧张的应用来说太过奢移。
具体的碎片整理过程是，首先建立碎片整理区。①为每个扇区建立2个CRC32表项;第一个CRC32是这个扇区在碎片整理前的CRC值;第二个CRC32值是计算出来的碎片整理后的CRC32值。这些CRC是当碎片整理过程被打断时，用来重新恢复整理用的。②创建碎片整理文件头信息表，每个活动的文件占用一个表项。③计算①和②的CRC值，并保存。①～③的数据保存在图1中的碎片整理记录区。第二步是文件重定位;遍历文件系统的每个扇区，处理重新定位后存储空间和该扇区相覆盖的文件。在每个扇区被重写之前，扇区原来的信息被保存在空闲扇区里。第三步，擦除Flash;遍历未使用的扇区，确认所有的扇区被删除。第四步，完整性检测：对新的文件进行检测，保证所有重定位的文件都是完整的。
3 应用分析
Flash的扇区有最大擦写次数。当前的Flash芯片一般支持10万～100万次的擦除。文件系统的应用各不相同，所以这里不能下结论说采用线性文件系统Flash的寿命会有多长。下面解释文件系统访问Flash的方法。这样用户可以根据应用来判断Flash的预期寿命。
我们所设计的线性文件系统并不进行扇区删除次数均衡，以延长Flash的使用寿命。如果所需要的文件系统频繁修改并需要扇区删除次数均衡，可以购买现成的Flash文件系统。扇区删除均衡算法大大增加了底层实现的复杂性，并且超出本文的讨论范围。一般来说，通过文件系统来管理Flash的需求远大于对Flash扇区擦写次数均衡的需求，特别是现在越来越多的Flash扇区都支持100万次的擦写。
如上面所提到的，文件系统本身提供给编程者的接口API与标准OS提供的接口类似。这可能误导开发者认为文件系统可以看作是一个硬盘，以任意的频率进行读写操作。事实并不是这样，线性文件系统碎片整理同制并没有进行擦写次数均衡，这意味着空闲扇区可能会是最早损坏的Flash扇区。因为在碎片整理过程中，空闲扇区被用作其它所有扇区的暂时存放扇区。例如在设计里，有13个扇区Flash用来作线性文件系统区，有1个扇区作为空闲扇区。假设对于最坏情况的碎片整理(13个扇区都影响到)，如果每天进行1次碎片整理，对于100 000次擦写次数的Flash而言，可用期能够超过(100 000/13/365=21)。20年是基于每天进行1次碎片整理，并且所有扇区都影响到的情况。碎片整理的频率和整理所影响到的扇区数受应用程序使用文件的限制。用户可以根据文件系统的应用来估算Flash扇区的磨损情况，并作相应的处理。
下面讨论文件系统是如何使用扇区的。Flash扇区仅仅在碎片整理时候才被擦除。当删除文件的时候，只是简单地作一个标识(文件头的一个位)。如果一个存在的文件以写的方式打开，实际的修改步骤是，删除原有的文件，并在当前文件系统的最后一个文件之后重写该文件。最后，这个过程会使文件系统的Flash空间被耗尽，这要就需要运行碎片整理程序。碎片整理程序会使已被删除文件所占用的空间被清除，所有活动的文件在Flash中的位置以连续的方式存放。每个扇区的整理过程是，扇区被拷贝到空闲扇区作备份，然后原来的扇区被删除，计算出该扇区在文件整理后的内容，写入扇区，之后删除空闲扇区的备份。文件系统从头到尾每个扇区重复这样作。在碎片整理时，如果一个扇区不需要进行碎片整理，碎片整理程序就不会动这个扇区因此，受碎片整理程序影响的扇区数目依赖于当前被文件系统占用的Flash扇区数和被删除文件在Flash中的位置。
在一个典型的嵌入式应用里，文件系统中的可执行文件本身就是应用程序。可执行文件一般是最大的文件，也是最不可能经常改变的文件。这意味着执行文件所占用的空间是相对固定的，将会减少空闲扇区因为碎片整理而进行的擦写次数。另外一方面，如果有任何文件需要定期改动，碎片整理将会更加频繁运行。
结语
嵌入式Flash 篇3
一般的嵌入式目标系统体积小,不可能象PC机那样带一个很大的磁盘存储器作为文件系统存储器。由于Flash存储器具有高可靠性、高密度、存取速度快、掉电可保存等特点,使之成为理想的嵌入式文件系统存储器。
嵌入式文件系统建立在实时系统内核之上,其设计不仅要求满足数据存储的各种要求,而且还要考虑其应用环境和存储器的物理特性。MS-DOS的FAT文件系统技术成熟、结构简单、系统资源开销小,嵌入式文件系统易于在设计上兼容FAT文件系统[1]。
2 可靠性
在MS-DOS的FAT文件系统中,仅仅对数据区域提供坏损管理,而对于它的主引导记录、文件分配表和根目录这三个极重要的文件系统数据结构却未做任何保护(虽然MS-DOS的FAT文件系统中存在着两张FAT表,但是DOS只是在更新FAT1时简单地复写FAT2表,但从不使用它)。一旦这三个区域的内容出现一点失效,将必然导致文件数据的大量损失。另外,如果这些数据结构的存储区域发生物理性损坏,更会导致整张磁盘的报废[2]。这在由Flash存储器占据很大成本比重的嵌入式应用中,是非常不希望的。
归结起来,嵌入式系统中的Flash存储器主要面临两大类不稳定因素:一是Flash存储器本身可能出现物理性的损坏;二是嵌入式系统面对较多的突发掉电与重启动,造成Flash存储器写操作的异常终止。
针对Flash存储器的物理损坏问题,对文件数据区域提供坏损块管理。在系统格式化时对坏块进行标记。
针对Flash存储器的写操作异常终止问题,将系统记录、文件分配表和根目录表这三个对Flash文件系统最重要的数据结构均进行双份的存储改善其安全性。在文件系统的操作中,程序对每一个表结构的两个备份进行顺次修改,以此确保Flash存储器上总是存有一整套完好的系统记录表、文件分配表和根目录表。在每块的首页空闲区保存了FAT表中该簇的簇值。在系统被启动运行时,文件系统初始化时,根据三个表在所在块的最后一页空闲区的写入成功标志和最后的更新时间确定每一张表备份的合法性和有效性,读取正确的记录。通过这样的设计,即使文件系统在使用中出现了写操作异常终止的情况,错误将只涉及当时被操作的文件数据,不会扩散给Flash文件系统中的其他文件,使损失降到了最低,更不会因此损坏三个文件系统表结构,造成整个文件系统的彻底瘫痪。
通过以上的改进,该Flash文件系统的可靠性比MS-DOS FAT文件系统有了很大的提高。
3 耗损平衡
JFFS文件系统中系统耗损平衡机制可以在不同的功能模块中采取不同的策略来控制[3]。下面分析耗损平衡机制在不同功能模块中的实现方法,研究它们的实现效率和系统代价。
(1)在垃圾收集模块中实现
(2)在块分配模块中实现
(3)使用专门的耗损平衡模块实现
上述三种策略可以在系统不同的模块中同时或分别实现,在耗损平衡的控制效果和实现耗损平衡的系统开销上有所不同。
通过上面三种实现闪存文件系统耗损平衡方法之间的比较,考虑到策略在嵌入式系统中实现的开销,考虑兼容FAT文件系统对系统记录、FAT表的频繁更新操作。对于系统记录、FAT表和根目录表采用交替更新来控制系统的耗损平衡;对于数据区在文件系统启动建立空闲块链表时,产生一个随机数,从该随机数开始的块开始搜索建立空闲块链表,如没有空闲块再从该存储器的第二块开始向后搜索空闲块,再根据空闲块的分配按先进先出策略来控制系统的耗损平衡。这样基本上保证了存储器各块的平均使用。
4 垃圾回收
FAT文件系统中没有垃圾收集机制,但由于FlashMeory的特点,为了提高文件系统性能加入了垃圾机制,优化文件系统的性能。考虑到嵌入式系统自身的特点,即系统中资源的有限性,在垃圾收集策略的实现上需要一定的可行性,尽量降低算法的复杂度,减小系统开销,且应该便于实现。故本文件系统垃圾收集算法如下:
将Flash盘中块分为三个队列,分别是干净块,空闲块和脏块队列。干净块队列是此块上的数据都有效。脏块是此块的数据己删除,需擦除变为空闲块。空闲块是指没有数据存储的可分配块,它们的状态可记录在FAT表中,当存储文件需要分配块时,如没有空闲块可分配,则启用垃圾收集机制进行脏块的擦除。或者当系统启动或空闲时,空闲块的数目少于设定的空闲块的数目n时,则启用垃圾收集机制进行脏块的擦除。其垃圾收集流程如图1所示。
5 性能优化
为了提高系统的性能,要采取以下策略:
(1)由于文件的写入速度与要擦除的块时间确定,同时还由要写入的数据量有关,故尽量减少写入的次数。
(2)文件删除时,对其目录项的第一个字节做删除标记,同时释放该文件所占用的簇链,并标记为脏块,当系统启动或空闲时启动垃圾收集进程进行脏块的收集。
(3)为加快给文件分配空闲块的速度在系统启动时就建立空闲块链表,按先进先出策略取得空闲块。
(4)为提高文件的查找速度,除根目录外将文件目录项所占用的簇在FAT表中标记为EOC,查找文件时只查找根目录和簇值为EOC的簇,提高了查找文件的速度。
(5)将FAT表以数组形式调入内存做为全局变量,利用数组的随机访问特性,大大提高了簇的寻址速度。
6 多任务支持
为了加载的文件系统跟内核很好地配合工作,在μcos-Ⅱ内核的0S_TCB中增加了文件控制块指针,该指针指向该任务打开的文件控制块链表。用户任务对文件进行读写操作时,系统必须维护当前被用户任务所打开的所有文件,用文件控制块来登记这些被打开的文件的相关信息。一个用户任务可能同时打开几个文件,对文件读写时要记录下文件的当前位置,以便在挂起后重新调度运行时能从这个位置继续进行。每个文件控制块记录了当前任务打开每个文件进行读写的当前位置。
7 实现与测试
(1)硬件环境
FFS的测试环境由宿主机和目标机组成。宿主机为一般PC机;目标机ARMSYS44BO-P嵌入式系统开发板,配有K9F5608型号的32M的NandFlash芯片。
(2)软件环境
目标操作系统:μcos-Ⅱ;宿主机操作系统:WINXP;开发调试编译工具:ARM Develop Suite V1.2。
(3)通信设置
PC机通过网络接口连接到开发板的网络接口,这样建立了主机与目标机的一条通信线路。这条线路主要用于程序下载。第二条线路是PC通过串口和目标板上的串口相连,用于程序下载,调试信息交互,主要用于目标系统的数据回显,我们在WINXP操作系统中启用一个监控串口的超级终端来接收并显示数据。
(4)系统测试
“测试”一般是指“为了发现程序中的错误而执行程序的过程”。但是在不同的开发阶段、对于不同的人员,测试的任务是不同的。
(5)功能测试
功能测试分为两部分,第一部分测试Flash驱动程序;第二部分测试文件系统核。通过功能测试和可靠性测试,验证了FFS文件系统有比较完整的文件系统功能,在数据的可靠性等方面能够满足设计初衷。
摘要：基于实时嵌入式操作系统μCOS-Ⅱ内核,采用类似DOS的FAT文件系统,实现了一种适用于NandFlash的嵌入式文件系统。该文件系统从可靠性、耗损平衡、垃圾回收及文件系统的优化几个方面进行设计。
关键词：flash存储器,嵌入式,文件系统
参考文献
[1]张长宏.一种基于NandFlash的嵌入式文件系统的设计.青海大学学报(自然科学版),2006;06.
[2]罗华春.基于Flash存储器的嵌入式文件管理器设计.交通与计算机,2005;01.
嵌入式Flash 篇4
Flash 嵌入的问题论坛中有人问了好多次，到底应该怎么用，为什么通不过验证，要通过验证怎么办等等等，讨论中也出现了不少的误解，所以我单开一个帖总结一下我所知道的东西，不想看我罗嗦的直接跳到最后看结论就可以了。
一、传统的方法
这方法是使用 object 和 embed 标签来嵌入，细心的会发现，object 的很多参数和 embed 里面的很多属性是重复的，为什么这样做？为了浏览器兼容性，有的浏览器支持 object，有的支持 embed，这也是为什么要修改 Flash 的参数时两个地方都要改的原因。这种方法是 Macromedia 一直以来的官方方法，最大限度的保证了 Flash 的功能，没有兼容性问题。但是它现在不那么好用了：无法通过验证，由于为了兼容性而嵌入的 embed 标签是不符合 W3C 的规范的。当然，如果你不在乎什么规范不规范，另当别论。
微软由于种种原因，在 sp2 后限制了 IE 的 ActiveX 的使用模式，就是在页面中的 ActiveX 有一个虚框，需要用户点击一次才能正常交互。Flash是作为一个 ActiveX 嵌入到网页中的，所以它也会受牵连，只有通过 JS 嵌入 Flash 才能解决这个问题。没有 Flash 版本检测，如果版本浏览器的flash插件版本不够，或者不能正常显示你的 swf 文件，或者会弹出一个 ActiveX 的确认安装的框――这个框对很多用户来说是很恐怖的。
二、只用 object 的方法
这种方法的名字叫做 Flash satay，最早是由 Drew McLellan 发表在 A List Apart 上，后来又经过了几次完善：
这方法没 embed 了，可以通过验证，是标准的嵌入 Flash 的方法，浏览器兼容性也不错，看起来几乎完美，不过还是有问题的：需要一个 holder swf 来加载你的目标 swf 以保证 IE 中的 stream 能力，如果你需要通过 flashvars 来传参，或者和页面的 JS 交互，会很麻烦。同上面第二点，ActiveX的虚框问题。继续同上没有版本检测，还是有少数用户代理（比如一些版本的 safari 和一些屏幕阅读器）不认这种方式，有 bug。
三、用JS嵌入的方法
用JS嵌入就是各有各的嵌入方法了，有嵌得好的有嵌得不好的，
有人用 document.write 直接写，这法子说实话不大好，感觉 hack 成分多了，有点为了验证而验证的意思，而且没有体现出什么 JS 的优势。我觉得一个好的 JS 嵌入脚本，在保证 Flash 应有功能的基础上，发?JS 的优势应该要有版本检测，要能很好解决可访问性问题（也就是用户在无法浏览 Flash 内容或禁用 JS 的时候应该如何处理的问题），要易于重复使用。我知道的比较常见的 JS 嵌入方法有以下几个：
SWFObject
UFO - Unobtrusive Flash Objects
Macomedia（现在是Adobe了..）提供的脚本[这里]和[这里]。
我 SWFObject 用的比较多，就挑它来说一些这种方法的优点：IE中没有讨厌的虚框问题了。提供了完善的版本检测功能，如果版本不够则显示其他东西，比如图片或文字。易于使用，只要在页面头加载一个 .js 文件，然后 HTML 写一个容器，里面放普通的文本或图片（用于无法显示 Flash 时显示），最后用脚本来替换这个元素里面的内容为 Flash。可以通过验证――当然这个不是重点，只是顺带效果罢了。
四、我的结论
现阶段用 JS 嵌入 Flash 是最完美的方法，虽然这法子这也是由于浏览器的种种问题而作出的妥协。但它在保证 Flash 功能的前提下还利用 JS 提供了额外的好处，再者又已经有人写了很完善的嵌入脚本可以方面地下载使用（推荐 SWFObject），我们还有什么理由不用它呢？
SWFObject 那网页是英文的，这里写个简单的用法教程：
下载它的.js文件，在这里：blog.deconcept.com/swfobject/swfobject1-4.zip（如果链接失效可能是版本有更新，请用上面给出的地址去主页下载最新版本）。在你的 HTML 页面头部区嵌入这个脚本文件：
在你的 HTML 中写一个用来放 Flash 的容器，比如，并随便给一个 id 比如 flashcontent。然后在里面放上你的替换内容。
这里放替换内容，用来在 Flash 无法显示时显示。
使用脚本替换这个内容：
这脚本可以写在 HTML 中也可以写在外部 .js 文件中。
嵌入式Flash 篇5
1嵌入式FLASH播放器工作流程
本文中实现的嵌入式Flash播放器架构如图1所示。其工作流程主要分为两步:
(1) 文件解析:
SWF文件的结构如下图所示
首先解析文件头,根据文件头的二进制内容,确定版本号,文件长度以及是否为压缩文件,当判断为压缩文件时,对压缩文件使用zlib算法从第9个字节进行解码,转换成非压缩文件。
然后根据文件头后的二进制内容解析出文件信息,包括:帧尺寸,帧速度及帧数。
接着解析所有的标记(tag), Flash文件中的标记分为两种:定义标记(Definition Tag)和控制标记(Control Tag)。前者定义Flash动画中使用到的所有对象,包括矢量图形,文本,声音等等,解析后以元素(Character)的形式存放在组件库(Dictionary)中;后者为控制组件库中对象的动作,主要包括:放置对象(PlaceObject), 移动对象(MoveObject), 移除对象(RemoveObject), 它们被解析后存放在每一帧的控制信息中。
(2) 文件播放:
从第一帧开始,根据每一帧中的控制信息,调用控制模块生成显示列表(DisplayList), 此列表中依次存着该帧中从最底层到最上层的每一个元素以及其位置信息等;然后调用矢量图形渲染模块将相应的元素画到相应的位置;完成一帧的显示后,再显示下一帧,由此形成动画效果。
2缓存思想的引入
2.1问题分析
最初开发出的播放器程序在嵌入式环境下运行时,速度非常慢,显示一帧需要数秒,这显然是用户无法接受的。测试表明整个播放流程中最耗时的部分是矢量图形渲染的过程,现在就重点分析其原因及解决方案。
Flash动画中的图形元素是一个个矢量图形,存储图形的轮廓以及填充样式等信息,在显示时再动态地用渲染引擎生成相应的位图。矢量图形在嵌入式环境下使用时,其高耗时就成了一个突出的问题。
为解决这一问题,首先对大量的Flash文件进行了分析:
(1) 统计Flash文件中三种控制标签的数量,发现其中移动对象标签(MoveObject)占了近90%, 而放置对象标签(PlaceObject)只占不到10%。
(2) 分析动画中的每一帧,发现当一个图形元素被放置到显示区域后,几乎肯定会出现在此后连续的几帧或几十帧中,它或保持原位置,或被平移、缩放或旋转,由此形成连续的动画效果。
(3) 每一帧中出现的矢量图形中,特别复杂的图形(主要指轮廓复杂)占20%左右,而渲染它们所耗的时间超过总耗时的70%,且复杂图形大多是小尺寸图形,大尺寸图形大都比较简单。
综合上述分析,Flash中的图形元素通常会被反复使用,且是在前后连续的许多帧中被反复使用。
2.2位图缓存的设计思想
如上文中所述,Flash播放中最耗时的部分为矢量图形渲染,存在大量的重复计算,而且它具有明显的时间局部性(时间局部性指最近被访问的资源在不久的将来可能再次被访问),因此可使用缓存技术来提高速度。
缓存技术是一种经典的以空间换取时间的思想,已广泛应用于计算机领域,尤其是在Web应用中,如代理服务器、网页浏览器等。在嵌入式Flash播放器中引入缓存技术,以解决矢量图形渲染过于耗时的问题。
设计缓存系统通常需要解决以下几个问题:
(1) 缓存内容:什么样的内容应该被缓存;
(2) 淘汰策略:当缓存空间不够时,缓存内容如何替换;
(3) 缓存一致性:即缓存内容的时效性问题,如何防止缓存的内容过时;
(4) 主动缓存:在使用资源前就预先获取资源的技术。
在本文设计的位图缓存机制中,不存在一致
性的问题,因此将重点讨论其余的三个问题。
2.2.1 缓存内容
Flash动画以矢量图形元素为基本对象,在显示时使用渲染引擎生成相应的位图,因此可以在第一次放置该元素时将生成的位图缓存下来,下次再遇到时就可直接将缓存的位图拷贝到相应的位置,由于Flash具有很强的时间局部性,这样必然能大大节省显示时间。
一个Flash动画中有大量的图形元素,而嵌入式系统中的内存资源是比较有限的,因此不可能为所有的元素都作位图缓存,由于图形渲染过程中主要耗时的是轮廓复杂的图形,所以可据此判断哪些元素需要被缓存。判断方式如下:在文件解析过程中,统计每一个元素的轮廓由多少条曲线组成,将这个值作为元素的属性保存起来(mNumOfEdges)。播放时,用一个门限值N(不同的硬件环境下N会有不同的值,在开发用平台上由于处理器较低端,因此N取为10)与其比较,若某元素的mNumOfEdges > N, 则对该元素作位图缓存,否则就直接渲染。
在使用已被缓存的数据时,需要解决一个问题:图形元素在后续帧中,可能会被平移、放大、缩小甚至旋转,除平移外,其余三种情况都不能直接拷贝位图,需要在拷贝时做一些处理,放大时需要插值,缩小时需要亚采样,而旋转时需要改变采样方向。具体地说,Flash中元素的位置与大小变换都是通过变换矩阵(Matrix)来实现,放置元素(PlaceObject)与移动元素(MoveObject)标签都有一个参数就是变换矩阵。如果一个点的原来的坐标为(x,y),变换后的坐标为(x′, y′),则计算公式如下:
x′=x*ScaleX+y*RotateSkew1+TranslateX
y′=x*RotateSkew0+y*ScaleY+TranslateY
需要注意的是,作为参数的变换矩阵是从原始位置到目标位置的,而使用位图缓存时是已知目标位置坐标要到原始图中找到相应的相素值,因此计算前要先对变换矩阵求逆后再使用。经插值或亚采样后的位图与用矢量图形重新渲染相比,画质会有所下降。但为了在嵌入式环境下得到更浏畅的动画,这种折衷是值得的,也是必要的。
2.2.2 淘汰策略
当渲染模块遇到需要缓存而尚未缓存的图形元素时,检查剩余缓存空间大小,如果剩余空间不足以容纳要缓存的位图,就需要淘汰一些缓存。淘汰策略以最小化损耗为原则,以最大限度地发挥缓存的作用,本系统使用以下淘汰策略。
1)首先淘汰所有过期数据,即淘汰再也不会被用到的位图缓存。
由于Flash动画是按顺序播放的,因此在文件解析过程中就能确定每一个元素最后一次使用时的帧号,缓存元素时将这个帧号保存在BitmapCache结构中(mLastUsedFrame);当缓存空间不足时,首先遍历缓存池中的所有位图缓存,将其mLastUsedFrame与当前帧号比较,若大于当前帧号,则将其删除。
2)淘汰了过期数据后,剩余空间可能仍然不能满足申请缓存区的大小。
此时必须淘汰某些仍然有效的位图缓存。此时理想的淘汰对象应该是这样的:淘汰该对象之后释放的内存空间越大越好,下次重新渲染该对象所对应的矢量图时耗时越短越好。根据以上的原则,设计位图缓存的淘汰优先级计算函数如下:
undefined
其中,mWidth与mHeight为元素的宽和高,mNumEdges是图形轮廓的曲线数。
生成位图缓存时,就计算出淘汰优先级存放在BitmapCache结构中,再将BitmapCache插入到链表中,而该链表是按淘汰优先级从大到小排列的。这样,每当需要淘汰有效缓存时,总是从链表头开始淘汰,比较需要被换入的位图缓存的mPriority值与链表头缓存的mPriority值,若前者比后者还大,则不对前者进行缓存。
2.2.3 主动缓存
在解析过程中就提前渲染并缓存特别复杂的图形元素(mNumEdges > 60),这样能进一步提高速度,并且提高播放的流畅程度。
3位图缓存的实现
位图缓存机制的工作流程如下图:
位图缓存的数据结构如下:
typedef struct _bitmapCache{
struct _bitmapCache * mNext;
U16 mCharacterID; //元素ID号
U32 mWidth; //位图宽度
U32 mHeight; //位图高度
U32 mPriority; //淘汰优先级
U32 mLastUsedFrame; //最后使用帧
U8 *mData; //位图数据
}BitmapCache;
4测试结果及分析
文中设计的嵌入式Flash播放器,实际运行环境是以SIGMA公司EM8500为核心的机顶盒。测试位图缓存的性能时,分配的最大缓存空间为2M。测试用的Flash动画取自各门户网站页面上的Flash动画与广告(因为该播放器的设计目的主要是作为浏览器插件使用)。在开启与关闭缓存功能的情况下分别播放各测试文件,通过对比两种情况下各帧的显示时间来检验优化效果 。
实际测试了多个文件,在不使用缓存机制的情况下,平均每帧显示耗时最小的为2137毫秒,最大的为6724ms;使用缓存机制的情况下,平均每帧显示耗时最小的为57毫秒,最大的为183ms。下面以两个实际的测试用例作一个直观的说明:
1) 文件一
总帧数:175 帧率:18 尺寸:640 X 120
测试结果如图4:
2) 文件二
总帧数:262 帧率:12 尺寸: 728 X 110
测试结果如图5:
在以上两图中,横座标为帧号,这里只显示了前70帧;纵座标为显示耗时,由于两条曲线时间值相差很大,所以纵座标为对数值(2为底,时间单位为ms)。上方的曲线为优化前的用时情况,下方的曲线为优化后的用时情况,图中虚线为严格按帧率播放时每帧耗时。
从图中可以看出,使用缓存机制之前,显示一帧需要数秒;而使用缓存机制后,除第一帧与中间个别帧(场景突变帧)外,大部分都只需要几十毫秒至百余毫秒,基本可达到或接近帧率要求的显示耗时。
大量的测试表明,位图缓存机制对嵌入式Flash播放器起到了极好的优化作用,能将播放速度提高数倍至数十倍之多,使之能够被实际应用。
5结束语
本文设计并实现了嵌入式Flash播放器中的位图缓存系统,在资源受限的嵌入式系统中,使用少量的内存充当缓存,并采取一定的缓存淘汰机制,可以极大地提高系统性能。实际运行情况表明,优化后的播放器已能较流畅地播放大部分网络上的Flash动画,大大改善了用户体验。下一步还可以考虑用RLE等简单的算法压缩缓存的位图,以减少缓存空间,或增加缓存的元素数目,进一步提高系统的性能。
摘要：本文将缓存思想引入了嵌入式Flash播放器的设计。将矢量图形渲染出的位图进行缓存,同时根据Flash文件的特点,使用一种简单可行的缓存淘汰策略与提前缓存策略,充分地利用缓存资源,极大地提高了系统性能,解决了播放速度过慢的难题。
关键词：嵌入式Flash播放器,位图缓存,淘汰策略,矢量图形
参考文献
[1] Macromedia Flash(SWF)and Flash Video(FLV)File Format Specification Version 8,www.adobe.com,2006
[2] SIGMA DESIGNS EM8620L Datasheet 2005
[3] DAVISON B D.A Web caching primer[J].IEEE Internet Computing,2001,5(4):38-45
[4]胡贯荣,阳富民.嵌入式浏览器缓存策略设计与实现.计算机工程与设计,2005,26(12):336 2-3364
嵌入式Flash 篇6
失效分析就是判断失效模式, 查找失效原因, 弄清失效机理, 并且预防类似失效情况再次发生。通过芯片失效分析, 可以帮助设计开发人员尽快找到设计上的缺陷;帮助生产技术人员尽快找到工艺上的缺陷;帮助设计开发和生产技术双方尽快找到由于设计参数与工艺参数不匹配而造成的功能性问题。进而实施控制和改进措施, 更好地加以完善。
1 VPOS失效
发生失效的对象产品是130nm线宽的Embedded (嵌入式) Flash产品, 主要失效模式为VPOS失效 (Positive HV Trimming fail) , 失效表现为无法给Flash提供正常工作所需要的正向高压信号。失效芯片的VPOS电压大部分被钳制在5V左右 (正常应该为7.2V) 。
失效芯片所在晶圆的Wafer Bin Map (如图1所示) 、Wafer面内VPOS分布 (如图2所示) 和VPOS值分布 (如图3所示) 。通过对比, 可以发现发生失效的正是那些VPOS值过小的芯片。
因为是Trimming失效, 因此这里先介绍下Trimming, 以及为什么需要Trimming。
产品用到的Flash单元, 在Program (编程) 和Erase (擦写) 的时候都需要一定精度的高压模拟信号 (VPOS/VNEG) 来驱动, 但在晶圆制造过程中, 由于设计窗口和工艺窗口可能存在GAP (间隙) 。正常范围内的工艺波动可能会造成信号无法完全满足这一精度要求。所以, 我们需要在晶圆测试过程中, 通过对每一颗芯片的Trimming, 将这一模拟信号微调到满足精度要求的区间内, 以保证每一颗芯片都能正常工作。微调的幅度比例数据将被保存到某个寄存器 (PDAC/NDAC) 中, 每一颗芯片今后在用户模式下工作时将调用这一数据。
举例来说, 如下图 (图4) 所示, 晶圆上的某颗芯片制造出来的VPOS中心值为6.6V, 通过PDAC微调, 我们可以得到5.9-7.4V范围内的16个单调阶梯值, 其中PDAC值等于13时对应的VPOS值最匹配设计需求 (7.2V) 。所以PDAC=13就作为VPOS Trimming值被记录下来。
这次的失效就是一种Trimming失效, 即VPOS无法Trimming到正常的工作电压范围内。我们进一步确认了后续测试项目, VNEG (Negative HV Trimming) 也失效了 (由于VPOS Fail Stop, 而没有显现出来) 。
2 失效机理分析
VPOS产生的路径 (如图5所示) :通过电荷泵 (Charge Pump) 电路得到初始VPOS高压, 通过PDAC输入值调节可变分压电阻进行VPOS Trimming, 通过比较电路 (与VREF比较) 反馈给电荷泵电路一个使能信号 (继续或停止Charge Pump) 。
然后, 我们来分析下可能的原因: (1) 输入信号异常 (2) VPOS生成电路 (包含电荷泵电路、可变电阻分压电路、基准比较电路) 异常 (3) Flash Array本身异常 (有漏电) , 导致VPOS电压被拉低。
其中, VPOS模块的输入信号包含电源供给, VREF (基准电压) 输入和PDAC信号输入。
由于其他电路模块工作正常, 我们可以首先排除电源供给的问题;VREF是内部产生的信号, 通过验证, 可以准确无误地读出;而PDAC是我们外部加给测试仪的信号, 也没有问题。因此, 可以判断VPOS模块输入信号均没有异常。
我们借助MOSAID机台 (一种适合工程失效分析的存储器测试设备) , 进入测试Debug模式 (非用户模式) , 尝试更改PDAC输入值和VREF输入值, 通过TP PIN检测确认失效芯片的VPOS, 是否会随之而发生变化。结果VPOS电压仍Stuck在4-5V而没有发生变化 (表1) 。这一结果使我们仍然无法排除“电阻分压电路”或“基准比较电路”出现异常的可能性。
表1.更改PDAC和VREF, 确认VPOS
同样借助MOSAID机台, 进入测试Debug模式 (非用户模式) 后, 我们通过TP PIN对失效芯片外加固定VPOS信号, 试图发现一些新的线索:
监测TP端与GND (接地) 端的漏电流, 失效芯片漏电 (1-2m A) 远大于正常芯片 (u A级) 。如图6所示。
根据已有的经验, 正常芯片在工作状态下不可能达到如此高的漏电。通过这一实验, 我们能够得到如下结论:VPOS生成电路或者Flash Array内部, 发生了较大的漏电。
分析失效芯片的Bitmap, 并没有发现Hard失效 (Flash Array内部无地址定位失效) 。
通过这一实验, 我们能够得到如下结论:VPOS无法Trimming到我们需要的电压, 并非是Flash Array内部某个Bit, 某条Word Line或某条Bit Line的Hard失效造成的。
综合以上结论, 虽然明确了漏电的发生, 但漏电发生的具体位置, 仍然无法判断。在一大片电路里找到失效点, 无疑是大海捞针。
3 失效缺陷定位与物理解析
由于失效芯片和正常芯片的静态电流Standby Current没有差别, 因此, 无法简单通过静态的Emission (发光显微镜) 获取亮点 (具体失效位置) 。另外, 由于测试仪和Emission机台不在同一厂房, 直接通过测试仪和Emission相连来获取动态亮点的方案也无法实施。
为此, 我们通过FPGA (现场可编辑门阵列) 植入动态程序, 给失效芯片提供动态的工作状态, 再接入Emission机台捕捉动态工作时的异常亮点。借此方法, 终于在芯片上 (VPOS生成电路区域) 发现了异常的发光点。 (如图7所示)
我们通过电路版图和芯片实物的对比, 借助TEM (透射电子显微镜) , 对异常发光位置进行物理失效分析, 发现异常发光的位置:HV GOX (高压栅氧) 电容的边缘位置 (AA与STI交界处) 的氧化膜, 作为电容介质层, 厚度明显比正常值要薄不少。 (如图8所示)
(a) NG芯片TEM结果 (b) Good芯片TEM结果
正是由于此处的电容介质层的氧化膜较正常薄, 导致了电容的BV下降, 以及漏电的发生。再次分析确认电路版图, 发现此电容正是VPOS电荷泵 (Charge Pump) 电路中的滤波电容 (如图9所示) 。从机理上不难理解, 正是该电容BV降低导致VPOS总是被钳制在5V左右, 而正常应该为7.2V, 电压无法满足要求, 导致芯片无法驱动存储单元的正常工作。
4 失效问题的改善
在产品失效上找到根本原因之后, 通过进一步调查, 我们发现其实失效区域用到了最紧的设计规则。但是, 由于设计人员没有违反设计规则, 我们没有理由要求设计人员更改这里的设计。所以, 我们尝试着进行工艺方面的优化改善。
通常HV GOX (高压栅氧) 刻蚀用到的都是湿法刻蚀, 由于湿法刻蚀具有各向同性的工艺特性, 过高的刻蚀速率或过多的刻蚀时间, 都会导致过多的侧向蚀刻.从而导致光刻胶边界处的氧化膜偏薄。但降低刻蚀速率或刻蚀时间, 会有氧化膜残留等风险。
作为对策, 在湿法刻蚀前, 通过降低光刻胶固胶步骤温度, 改善光刻胶边缘的翘曲状态, 减少湿法刻蚀的氧化膜侧向刻蚀损失, 从而防止HV GOX (高压栅氧) 边缘被刻蚀减薄。此项改善取得了既定的效果, 失效得到了改善。同时, 我们也建议设计人员在设计下一代产品的此类电路时, 综合考虑生产线的工艺窗口, 优化电路设计。
5 结言
130nm嵌入式Flash产品由于VPOS失效导致存储单元无法正常工作。本文通过失效机理分析、多种电学及物理解析确认, 发现由于电容介质层氧化膜的边缘异常致使VPOS发生漏电, Flash因无法获得足够的正向高压信号导致存储单元无法正常工作。通过工艺条件优化, 扩大工艺窗口, 使这一问题最终得到了解决。为今后类似失效问题的分析和改善, 提供了解决的思路和方法。
参考文献
[1]Ashok K.Sharma著, 曾莹等译.先进半导体存储器瑱结构、设计与运用[M].北京:电子工业出版社, 2005.
[2]Hong Xiao;Introduction to Semiconductor Manufacturing Technology Prentice Hall, 2000.
嵌入式Flash 篇7
关键词：分裂栅薄膜闪存,纳米晶体,嵌入式闪存,尺寸缩小,电可擦除只读存储器
0 引言
自从上个世纪80年代闪存技术发明之后, 人们已经在flash技术上获益了很多, 像独立的高密度的数据存储设备, 被广泛应用在了计算机, 照相机, U盘。当然除了这些能够看得到的, 还有一些应用在嵌入式应用的, 像一些分布式智能控制中, 智能家电, 智能电表, 医疗器械, 工业控制, 汽车行业, 便携设备中, 嵌入式非易失存储器 (ENVM) 在很多方面正在或者将要影响和改变着我们的生活。而作为嵌入式MCU应用, 每年都有相当的市场和稳定的增长率, 预计到2015年全球市场份额将达到$20B。在很多的智能嵌入式应用和便携式应用中, 要求我们能够实时存储或者更新数据, 或者一些低端应用中, 都需要我们能够提供低功耗, 能够灵活配置的容量, 快速编程以及擦除的性能。飞思卡尔Kinetis L系列MCU就能为用户提供了比较灵活的应用。
1 基于纳米硅晶体存储介质的分裂栅薄膜flash
1.1 scaling的优势
我们知道, 传统的浮栅结构在进入到20nm以下的工艺时, 因为本身的结构和特征以及工艺有着不可克服的困难[1]:1) 尺寸缩小使得相邻bitcell的耦合效应增强, 进而导致编程的时间加长。2) 位于控制栅极和浮栅之间的绝缘体层必须保持在一定厚度。3) 因为电子数量的减少而使可靠性恶化。因此, 这些传统的浮栅结构的局限以及工艺的发展不断驱动人们寻求新的技术。而Kinetis L系列产品中, 采用的正是一种以一个个纳米硅晶体存储电荷的薄膜技术的flash, 它是将用于存储电荷的传统浮栅结构用一层纳米硅晶体替代。图1[2]和图2分别是电子显微镜下纳米硅晶体的水平分布图和每个SG-TFS单元的纵切面图。因为电荷的存储是采用一个个独立的纳米晶体, 因此它的尺寸可以做的很小, 他使传统的浮栅结构在进一步缩小尺寸上获得了重大突破。而且因为一个个纳米晶体点是被顶层氧化层和沟道氧化层所包裹, 它水平方向的电荷移动变的非常的少。另外因为每个硅纳米晶体的独立性, 即便在某个地方出现污染的情况下, 损失的也仅仅是附近的有限几个纳米晶体的电荷, 而不像传统的浮栅, 因为它的整体的导电性, 即便是局部的污染也将会有大量的电荷泄露, 以至于引起器件的失效。这些优势使得以一个个纳米晶体为存储电荷介质的薄膜flash能够随着工艺的进一步发展而缩小尺寸, 甚至在20nm制程上依然表现了良好的特性[3]。
2.2 SG-TFS flash的读写特性
Kinetis L MCU上的SG-TFS flash是集成在90nm工艺的一个平台上。如图3所示, 存储电荷的纳米硅是在控制栅下面, 它的上下都生长有氧化层, 选择栅以及下面的薄氧化层与低压晶体管共用。SG-TFS flash通过源极热电子注入的方式编程 (programming) , 利用F-N隧穿效应进行擦除 (erasing) 。通过调整源极和控制栅的偏置电压, SG-TFS flash的编程时间可以很快 (<20us) , 而且功耗较低 (4-16u A/bit) , 还能得到良好的Vt特性 (如图3) 。通过在控制栅极上14V左右的偏压, 可以得到小于1ms的擦除时间。通过快速的、低电压的晶体管提供低功耗读取性能, 操作电压可以低达1.71V, 这使得它在功率敏感型的客户应用提供了可能性。而且经过测试, 这种flash有着超过20年的数据保持能力。
1.3 可配置的耐用性的片上EEPROM功能
TFS Flash通过一个对用户不可见的RAM (Flex RAM) , 以及和flash一起可以灵活配置, 来实现片上EEPROM的功能。首先, 用户可以快速对接口部分EERAM (分配给EEPROM功能的Flex RAM部分) 进行读写访问, 然后通过内嵌的固件 (Firmware) 来将Flex RAM的来写进EFLASH, 通过内嵌固件的支持实现对flash的大容量编程和擦写来模拟EEPROM的功能。通过对flash的灵活配置, 在确保现有EEPROM容量 (高达16KB) 和持久性 (在整个适用温度和电压范围超过一百万循环) 的同时, 提供客户选项和应用优化;擦除和写入仅需1.5微秒即可完成, 这比传统EEPROM解决方案快了5倍。
2 微控制器 (MCU) 的特征
这款MCU是基于32-bit ARM Cortex-M4处理器上的, 在90nm工艺制程上制造的, 它有着良好的低功耗设计技术 (stop模式下静态电流小于<500n A) , 灵活的功耗模式配置, 同时集成了多个高速16-bit ADC的模拟模块, 上文提到的片上flash作为代码存贮或者数据存贮, 以及多个外设, 给客户的不同的应用提供了一个灵活的平台。
多种功耗模式:Kinetis MCU具有多种低功耗模式设计:WAIT、STOP、以及VLLS和LLS模式。这些不同的模式下MCU中保持工作的外设也不同, 被唤醒的条件也不同, 并且提供了不同的工作电流和功耗。这些灵活多变的低功耗设计, 给一些功耗敏感的嵌入式应用或便携式应用提供了便利的条件。
4 结论
Kinetis L MCU是第一款以纳米硅晶体作为电荷存储的SG-TFS的flash的商业MCU产品, 它具有良好的低功耗设计, 灵活多变的flash配置以满足代码, 数据存贮以及EEPROM的的开发提供了便利条件。
参考文献
[1]S.J.Hong, Memory Technology Trend and Future Challenges[J].IEEE, 2010.
[2]K.M.Chang, SG-TFS:a Versatile Embedded Flash with Silicon Nanocrystals as the Storage Medium[J], IEEE, 2008.