多層單元快閃記憶體儲存系統之設計

行政院國家科學委員會專題研究計畫 成果報告

多層單元快閃記憶體儲存系統之設計 研究成果報告(精簡版)

計 畫 類 別 ： 個別型

計 畫 編 號 ： NSC 98-2221-E-011-070-

執 行 期 間 ： 98 年 08 月 01 日至 99 年 09 月 30 日 執 行 單 位 ： 國立臺灣科技大學資訊工程系

計 畫 主 持 人 ： 謝仁偉

計畫參與人員： 碩士班研究生-兼任助理人員：林毅展 碩士班研究生-兼任助理人員：張尚揚 碩士班研究生-兼任助理人員：鄭育丞 碩士班研究生-兼任助理人員：李暐屴

報 告 附 件 ： 出席國際會議研究心得報告及發表論文

處 理 方 式 ： 本計畫涉及專利或其他智慧財產權，1 年後可公開查詢

中 華 民 國 99 年 11 月 06 日

行政院國家科學委員會補助專題研究計畫 ■ 成 果 報 告

□期中進度報告 多層單元快閃記憶體儲存系統之設計

計畫類別：■個別型計畫 □整合型計畫 計畫編號：NSC 98-2221-E-011-070

執行期間：98 年 8 月 1 日至 99 年 9 月 30 日 執行機構及系所：國立台灣科技大學資訊工程系

計畫主持人：謝仁偉 共同主持人：

計畫參與人員：林毅展（碩士生）、張尚揚（碩士生）、李暐屴（碩士生）、鄭育 丞（碩士生）

成果報告類型(依經費核定清單規定繳交)：■精簡報告 □完整報告

本計畫除繳交成果報告外，另須繳交以下出國心得報告：

□赴國外出差或研習心得報告

□赴大陸地區出差或研習心得報告

■出席國際學術會議心得報告

□國際合作研究計畫國外研究報告

處理方式：除列管計畫及下列情形者外，得立即公開查詢

□涉及專利或其他智慧財產權，□一年□二年後可公開查詢

中 華 民 國 99 年 9 月 30 日

國科會補助專題研究計畫成果報告自評表

請就研究內容與原計畫相符程度、達成預期目標情況、研究成果之學術或應用價 值（簡要敘述成果所代表之意義、價值、影響或進一步發展之可能性）、是否適 合在學術期刊發表或申請專利、主要發現或其他有關價值等，作一綜合評估。

1. 請就研究內容與原計畫相符程度、達成預期目標情況作一綜合評估

■ 達成目標

□ 未達成目標（請說明，以 100 字為限）

□ 實驗失敗

□ 因故實驗中斷

□ 其他原因 說明：

2. 研究成果在學術期刊發表或申請專利等情形：

論文：□已發表 □未發表之文稿 ■撰寫中 □無 專利：□已獲得 □申請中 ■無

技轉：□已技轉 □洽談中 ■無 其他：（以 100 字為限）

研究成果已在國際研討會 16th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA 2010) 中發表。

3. 請依學術成就、技術創新、社會影響等方面，評估研究成果之學術或應用價 值（簡要敘述成果所代表之意義、價值、影響或進一步發展之可能性）（以 500 字為限）

本為期一年的專題研究計畫提出了一個針對多層單元快閃記憶體儲存系統所 設計的機制，同時考慮了多層快閃記憶體所帶來的新挑戰與檔案系統的存取 特性，因此在效能優於其他相關的機制。我們的機制會針對不同的存取行為，

採取不同的管理方式，並且採用混合型的對應方式，在效能與記憶體需求之 間取得平衡。我們的研發成果不但可以立即應用在最新的快閃記憶體產品 上，所有參與計畫的學生也於相關的快閃記憶體儲存系統發展上，獲得很好 的研究經驗。

一、 前言

Currently, multi-level cell (MLC) flash memory has occupied the largest part of the flash memory market, due to an increasing demand for a larger capacity and smaller-size storage medium. In MLC flash memory, each cell can store two or more bits of data. Although MLC flash memory offers a lower cost and higher density solution (compared with the traditional SLC flash memory), it introduces additional stringent constraints. First, the number of partial program cycles in the same page is limited to one. This constraint implies that it is no longer permitted to mark a page as dead by simply clearing some specific bit in the spare area, which is widely adopted in previous researches. Another constraint is related to the order in which write operations are performed. In MLC, free pages of a block must be written consecutively from the first free page to the target one in the block; random written order is prohibited. Such a constraint makes most existing block-level mapping schemes, such as NFTL, inapplicable for modern flash memory chips. Further, direct modification to these mapping schemes is not appropriate as it will inevitably lead to a significant increase of overhead.

二、 研究目的

Motivated by the above concerns, we propose a hybrid mapping scheme for the management of modern MLC flash memory. Since FAT file system is most commonly used for accessing flash memory, the proposed scheme focuses on the file access behavior under FAT file system. In the proposed scheme, the mapping granularity is adjusted adaptively according to the access behavior. Our scheme is distinguished from existing solutions in that the proposed scheme consumes less RAM, while providing a better performance. In addition, existing solutions does not take stringent constraints of MLC flash memory into account (since they were designed for SLC flash memory), while our scheme could apply to SLC flash memory as well.

三、 文獻探討

FAT File System

Figure 1 illustrates the structure of a FAT file system. A FAT file system consists of a boot record, File Allocation Tables (FAT1 and FAT2), a root directory, and data area. To create a file under the FAT file system, the system first creates the file name and writes it to the root directory. Note that the FAT file system does not allocate space for the entire file in a single step. Instead, it does so incrementally in multiple rounds. Basically, in each round of the operation, the system allocates space for only a portion of the file, followed by updating File Allocation Tables FAT1 and FAT2 (or FAT tables for short) and then writing the data to the data area accordingly. It repeats the above operation until all data of the file are written to the storage. During the write process, the root directory and FAT tables are updated repeatedly and the body of the file is appended to the data area of the storage step by step.

Figure 1: The Structure of a FAT File System.

Figure 2 is a trace extracted from a set of file creations in a FAT file system. Figure 2.(a) shows the write flow associated with creating two 4KB files, while Figure 2.(b) presents the write flow associated with creating two 64KB files after the previous file creations. We align the two traces for comparison purpose. In the figure, the column labeled with “Address” gives the starting address of the data accessed by a request with “WAddr”

indicating a write operation. It shows the sector address associated with a request, with each sector being 512 bytes in length. The column labeled with “Count” gives the size of the data associated with a request. In the trace, the basic space allocation unit is 32KB in size. The column labeled with “Area” indicates the part of the FAT file structure that is accessed.

Figure 2: Trace of File Creations under a FAT File System.

From the trace, the following observations are noteworthy: (1) The root directory and FAT tables are updated frequently; (2) As shown in Figure 2.(a), although only 4KB of data are written to the storage, 32KB space is occupied; the second 4KB file starts from 0x00004080, rather than 0x00004048; (3) For those files that are larger than 32KB, the FAT system allocates space continuously. As shown in Figure 2.(b), for creation of the

first 64KB file, the system writes data to 0x000040C0 with 0x00000078 sectors, followed by writes to 0x00004138 with 0x00000008 sectors. The second 64KB file starts from 0x00004140, right after the previous 64KB file.

Hybrid Mapping Schemes: BAST and FAST

Block Associative Sector Translation (BAST) is a hybrid mapping scheme proposed by Kim et al. [1]. BAST maintains a limited number of log blocks in flash memory to handle update requests. Each data block is associated with at most one log block. When processing an update request, the associated data is appended to free pages of the corresponding log block sequentially, as long as such free pages are available. Merge operation is activated when either of the following two conditions is met:

1. All pages in the corresponding log block have been written, and a new update request to the block arrives;

2. All log blocks are used, and a new write request requires an update to a data block that is not associated with any log block.

With a merge operation, all live pages in the data block and the associated log block are copied to a new data block. The old data block and log block are then erased. A merge operation in BAST may induce an overhead of copying N pages and two block erasures, where N is the number of pages per block.

Fully Associative Sector Translation (FAST) is another hybrid mapping scheme proposed by Lee et al. [2].

FAST shares log blocks (RW blocks) with all of the data blocks. It allows an update request to be written to the current log block. As a result, FAST improves the utilization of log blocks and reduces the number of merge operations. However, since a log block may be associated with several data blocks at the same time, merging a log block may require the merging of several data blocks. To deal with sequential writes, FAST maintains a special log block, called sequential write log block (SW block). Since FAST must use physical page address in its page mapping table, rather than page offset as BAST does, FAST consumes more memory space than BAST while maintaining the same number of log blocks.

四、 研究方法

Data Structure

Some data structures are proposed to manage the proposed MLC Flash Translation Layer (MFTL), that is, BlockTable, UpdateRec, and PageMapStatus. BlockTable and UpdateRec are used to maintain block-level information, while PageMapStatus is used to keep page-level information. BlockTable, UpdateRec, and PageMapStatus are all stored in RAM. BlockTable is a one-to-one mapping table, which keeps the mapping information between virtual blocks and (physical) flash-memory blocks. When a write request arrives, MFTL calculates the corresponding virtual block address (VBA) via the logical address of the request, allocates a free (physical) flash-memory block for the virtual block, and writes data to the allocated block.

The physical block address (PBA) of the allocated block is recorded in BlockTable[VBA].

Since out-place update is a widely adopted solution for handling data-update requests, an extra replacement block (physical flash-memory block) is assigned to store the newly updated data. To keep track of the latest version of data, an UpdateRec is created whenever a replacement block is allocated for a virtual block. Each UpdateRec contains the following fields:

„ VBA records the corresponding virtual block address.

„ Primary records the physical block address of the associated primary block.

„ Replace records the physical block address of the associated replacement block.

„ LWP is the index of the last written page in the associated replacement block.

„ Count maintains the number of backward updates occurred in this record. The initial value of Count is 0.

„ Mode is a one-bit flag indicating whether the mapping is in block mapping mode (0) or page mapping mode (1).¹

„ Priority is the priority for UpdateRec replacement. When a write/update request arrives, Priority of the corresponding UpdateRec (if any) is set to 0xFF, while Priority of other UpdateRec's would be decreased by 1.

Finger 3 shows an instance of UpdateRec. To simplify the drawing, we assume that each flash-memory block contains eight pages. As shown in the figure, the physical block 3 is allocated for the virtual block 9 as its primary block. Starting from page 0, two continuous pages have already been updated. The physical block 1 is allocated as its replacement block, and the mapping is in block mapping mode. LWP is updated to 1 to indicate the index of the last written page in the replacement block. The value of Count is initialized to 0, and the initial value of Priority is set to 0xFF.

Figure 3: An Instance of UpdateRec.

Since data updates might be random and data amount of each update might be small, only UpdateRec is insufficient if fast data access is required. To deal with small and random updates, page-level mapping scheme might be an adequate solution. However, page-level mapping scheme must be used carefully since it will consume a large amount of RAM. In the proposed MFTL, PageMapStatus is created to work with UpdateRec whenever the mapping switches to page mapping mode. Each PageMapStatus contains two elements:

1 Initially, the mapping is in block mapping mode. When the Count value exceeds a pre-defined threshold, it will switch to page mapping mode.

„ VBA records the corresponding virtual block address.

„ MapArray[N] is an integer array keeping the page-mapping information of the block, where N is the number of pages per block. The value 0xFF in the MapArray[i] means the i-th logical page is located at the i-th page of the primary block. Otherwise, the i-th logical page is located at the MapArray[i]-th page of the replacement block.

To illustrate, we continue the example in Figure 3 but assume that the mapping has been switched to page mapping mode. Suppose subsequent data updates in the virtual block 9 are on pages 7, 3, 1, 6, and 3, in sequence. When a page is updated, the new version of the data is written to the first free page in the replacement block. After all the update requests are completed, a snapshot of UpdateRec and MapArray is shown in Figure 4. Backward updates occurred three times, so the value of Count in UpdateRec is 3. Here

“backward update” means the index of the target page is less than the index of the last written page in the associated replacement block. The MapArray records the information where logical pages are located. For example, logical page 2 is located at page 2 of the primary block as the value in MapArray[2] is 0xFF;

logical page 6 is located at page 5 of the replacement block due to the fact that MapArray[6] is 5.

Figure 4: A MapArray Example.

Write Flow

When the FAT file system creates a new file, it first issues a write to root directory to update the file information. It then updates FAT tables to allocate required storage space for the file. Finally, the file body is written to the allocated area. Conceptually, the storage space could be treated as containing two parts: system area and data area. System area consists of a boot record, FAT tables and a root directory, while data area is the area used to store file body. Any write/update to a file (data area) is accompanied by several small updates to the system area to ensure correct file information. Observing the very different behavior over system area and data area, we shall adopt various mechanisms to deal with write operations in an adaptive manner. Since writing data is trivial in flash-memory management, we will focus on the operation of data updating.

Figure 5 illustrates the flowchart of an update operation. Upon arrival of an update request, MFTL first determines whether the corresponding UpdateRec exists by checking the VBA field of each UpdateRec. If no such an UpdateRec exists, MFTL creates a new one. Since the number of UpdateRec's is limited, UpdateRec replacement may be required. In case that all the UpdateRec's have been assigned and the new update request does not match any one of them, MFTL will select the UpdateRec with the lowest priority, i.e., the one with the smallest Priority value, as a victim for replacement. Live pages in the primary block and the

replacement block of the victim UpdateRec will be merged to a newly allocated block, and the victim UpdateRec could then be released and reassigned to the new request. After the UpdateRec is located, MFTL determines the mapping mode of the UpdateRec. Different mapping mode would affect the manner how MFTL writes data to flash memory.

Figure 5: Flowchart of an Update Operation.

If the mapping mode is in block mapping mode, some further checks are required. According to the index of starting target page for the update request (i.e., STP) relative to the index of the last written page in the replacement block (i.e., LWP), the update request is treated differently. For the case in which STP is larger than LWP, the request is treated as a forward update. Otherwise, some previously updated data is to be updated again by the request, and the request is treated as a backward update. Since backward updates incur higher page-copying overheads, page-mapping mode is thus introduced to deal with small, random, and frequently updated data.

As mentioned previously, the Count field in UpdateRec is used to maintain the number of backward updates that had occurred in this record. When it exceeds a threshold, the mapping is switched to page mapping mode. If a backward update occurs but does not result in a switch to page mapping mode, MFTL will examine whether page-copying after updating data is required. The primary reason behind page-copying after updating data is the assurance of data integrity, since the primary block or the replacement block would be reassigned in this case.

Read Flow

For a read request, MFTL locates the target data through either BlockTable or UpdateRec's (and PageMapStatus's, if required). Figure 6 shows the flowchart of a read operation. When a read request arrives, MFTL first derives the corresponding VBA and STP via the logical address of the request. Then, MFTL determines whether the derived VBA matches the VBA field of any UpdateRec. If no such UpdateRec is

found, the PBA of the target data can be obtained from BlockTable[VBA]. With the PBA, MFTL accesses the corresponding flash-memory block and read the required data from page STP to the last page of the block.

Figure 6: Flowchart of a Read Operation.

Suppose that the UpdateRec is successfully found and it is in block mapping mode. In this case, MFTL has to identify which block and how many pages shall be read. For this, MFTL compares the derived STP with LWP of the UpdateRec. If STP is smaller than or equal to LWP, a portion of the required data shall be read from the corresponding replacement block. In this case, MFTL reads the required data from page STP to page LWP in the replacement block and then read from page LWP+1 to the last page in the primary block. Otherwise, MFTL simply reads the required data from STP to the last page in the primary block.

For the case in which the corresponding UpdateRec is found and in page mapping mode, MFTL may not be able to read the required data sequentially because the live pages in the replacement block are not programmed in such a manner. MFTL must look up MapArray to determine physical locations of the needed data. For each target page i, if the value of MapArray[i] is 0xFF, MFTL reads data from page i in the primary block. Otherwise, MFTL reads from page MapArray[i] in the replacement block. Figure 7 illustrates a read operation in page mapping mode. Suppose the read request wants to read pages starting from page 4 (STP = 4).

According to the MapArray, the read sequence would be Primary:page4, Replace:page6, Replace:page7, and Primary:page7.

Figure 7: Read in Page Mapping Mode.

五、 結果與討論

Experiment Setup

The experiment is conducted by a trace-driven simulation. Traces with various access behaviors were collected under Windows XP with FAT16 file system over a 2GB flash memory. Note that although MFTL is designed for MLC flash memory, BAST and FAST are designed for SLC flash memory. Since directly apply

BAST or FAST over MLC flash memory would incur extra overhead, we compare the three schemes over SLC flash memory. The flash memory chip used in the experiment is Samsung K9WAG08U1B 16G-bit SLC flash memory, in which each block contains 64 2KB pages. All of the traces were captured by the SD/MMC card protocol analyzer VTE2100 [3]. The cluster size was set as 16KB, where the cluster size was the minimum allocation unit for a file. For example, FAT16 file system will allocate 16KB space for a 4KB file with internal fragmentation and allocate 4×16KB space for a 64KB file without any internal fragmentation.

Table I summarizes the characteristics of the seven evaluation patterns.

Table I: Characteristics of Evaluation Patterns.

Pattern Description

4KB-S Sequentially copy 5,000 4KB files into a directory to emulate a large amount of small file creations with internal fragmentation.

64KB-S Sequentially copy 5,000 64KB files into a directory to emulate a large amount of small file creations without internal fragmentation.

4KB-R Randomly create 120,000 4KB files and process up to 4,000,000 file write/update operations to emulate a tremendous amount of random small-file accessing with internal fragmentation.

64KB-R Randomly create 30,000 64KB files and process up to 4,000,000 file write/update operations to emulate a tremendous amount of random small-file accessing without internal fragmentation.

ROOT Copy files/directories of different sizes into the root directory to emulate a synthetic situation.

SUB Copy files/directories of different sizes into a subdirectory to emulate a synthetic situation.

MP3 Copy mp3 files and photos to NAND flash storage.

Experiment Results

Figure 8 and Figure 9 compare the number of extra page writes and the number of total block erasures for BAST, FAST, and MFTL, under different number of extra blocks over a 2GB flash memory. Except for the extreme cases (i.e., the patterns 4KB-R and 64KB-R), FAST performs better than the other two schemes when the number of extra blocks is very limited. In fact, its performance saturates at three extra blocks. This is because extra blocks are shared by all logical blocks with FAST. As the number of extra blocks is increased, BAST demonstrates better performance than FAST for patterns 4KB-S and SUB. For patterns 64KB-S, ROOT, and MP3, BAST and FAST perform similarly. However, MFTL outperform both BAST and FAST when four extra blocks are provided. In particular, the performance improvement with our scheme is significant when the number of extra blocks falls between four and six. This is due to the following two reasons: (1) At least four extra blocks are required in order to well support updates of two FAT tables, root directory, and data area, which are needed when writing a file to storage; (2) Windows XP uses two threads to carry out writing operations for files with sizes over 64 KB; hence five extra blocks are enough to support update operation for a large file. Additional extra blocks do not offer obvious improvement.

(a) 4KB-S, Page Writes (b) 4KB-S, Block Erasures

(c) 64KB-S, Page Writes (d) 64KB-S, Block Erasures

(e) 4KB-R, Page Writes (f) 4KB-R, Block Erasures

(g) 64KB-R, Page Writes (h) 64KB-R, Block Erasures

Figure 8: Performance Comparison of BAST/FAST/MFTL under Different Number of Extra Blocks for Accessing Small Files over a 2GB Flash Memory.

(a) ROOT, Page Writes (b) ROOT, Block Erasures

(c) SUB, Page Writes (d) SUB, Block Erasures

(e) MP3, Page Writes (f) MP3, Block Erasures

Figure 9: Performance Comparison of BAST/FAST/MFTL under Different Number of Extra Blocks for Accessing Synthetic Files over a 2GB Flash Memory.

Memory Requirement

We now discuss memory requirements for the three hybrid mapping schemes. Since block mapping tables are of the same size for all schemes, we focus on memory requirements for managing update requests. Table II lists memory requirements for each extra block and for managing page mapping information.

Table III lists the memory requirements for these schemes with respect to different number of extra blocks. As shown in the table, when the number of extra blocks is six, MFTL can save about 40.85% memory space

compared with BAST and up to 74.70% compared with FAST. These savings can be as high as 59.44% and 83.89% when there are ten extra blocks provided by the system.

Table II: Memory Requirements for Extra Block and MapArray (Unit: Bytes).

Extra Block Page Mapping VBA Primary Replace Other VBA Array

BAST 2 2 2 1 0 64

FAST 2 2 2 0 0 192

MFTL 2 2 2 3 2 64

Table III: Memory Requirements for Managing Update Requests with Different Number of Extra Blocks.

(Unit: Bytes)

Number of Extra Blocks

2 3 4 5 6 7 8 9 10 BAST 142 213 284 355 426 497 568 639 710 FAST 204 402 600 798 996 1,194 1,392 1,590 1,788 MFTL 84 159 234 243 252 261 270 279 288

參考文獻

[1] Kim, J., Kim, J. M., Noh, S. H., Min, S. L., and Cho, Y. 2002. A Space-Efficient Flash Translation Layer for CompactFlash Systems. In IEEE Transactions on Consumer Electronics, Vol. 48, No. 2. 366-375.

[2] Lee, S.-W., Park, D.-J., Chung, T.-S., Lee, D.-H., Park, S., and Song, H.-J. 2007. A Log Buffer-Based Flash Translation Layer Using Fully-Associative Sector Translation. In ACM Transactions on Embedded Computing Systems, Vol. 6, No. 3, Article 18.

[3] Testmetrix Inc. VTE2100.

計畫成果自評

In this one-year project, we focus on designing a hybrid mapping scheme, which could provide a transparent way for existing file systems to directly access large-capacity MLC flash memory. Observing that most of existing user applications access NAND flash memory under FAT file system, we take new constraints of MLC flash memory and access behaviors of FAT file system into consideration. The proposed MFTL scheme treats different access behaviors in an adaptive manner. It adopts a hybrid mapping approach to balance between performance and RAM requirement. An extensive set of experiments has been conducted to evaluate the performance of the proposed MFTL. Our experiment results show that the proposed scheme outperforms existing works in terms of extra page writes and block erasures while RAM requirement is largely reduced compared with existing schemes. Students involved in this project are now well-trained and have excellent experiences in developing flash-memory storage systems.

與執行計畫相關之論文或專利發表

[1] Yuan-Hao Chang, Jian-Hong Lin, Jen-Wei Hsieh, and Tei-Wei Kuo, “A Strategy to Emulate NOR Flash with NAND Flash,” ACM Transactions on Storage, Volume 6, Issue 2, Article No. 5, July 2010.

[2] Jen-Wei Hsieh, Chung-Hsien Wu, and Ge-Ming Chiu, “Design and Implementation for Multi-Level Cell Flash Memory Storage Systems,” the 16th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA 2010), Macau SAR, P.R.C, August 23-25, 2010.

[3] 中華民國發明專利，證書號：I331337，卷號：37，期號：28，公告日期：2010/10/01，張原豪, 謝 仁偉, 郭大維, 楊政智，『快閃記憶體之高效率靜態平均抹除方法』

[4] 中華民國發明專利，證書號：I329804，卷號：37，期號：25，公告日期：2010/09/01，謝仁偉, 張 立平, 郭大維, 謝享奇，『快閃記憶體之高效率資料特性辨識方法』

[5] 中華民國發明專利，證書號：I329805，卷號：37，期號：25，公告日期：2010/09/01，蔡易霖, 郭 大維, 謝仁偉, 張原豪, 謝享奇，『可調式快閃記憶體管理系統及方法』

[6] 中華民國發明專利，證書號：I329860，卷號：37，期號：25，公告日期：2010/09/01，謝仁偉, 吳 柏良, 張原豪, 郭大維, 楊政智，『 硬碟資料讀寫快取裝置及方法』

[7] 中華民國發明專利，證書號：I313871，卷號：36，期號：24，公告日期：2009/08/21，謝仁偉, 郭 大維, 謝享奇，『快閃記憶體資料存取可靠性提昇方法』

出席國際學術會議心得報告

計畫編號 NSC 98-2221-E-011-070

計畫名稱 多層單元快閃記憶體儲存系統之設計

出國人員姓名

服務機關及職稱 謝仁偉 國立台灣科技大學資訊工程系 助理教授

會議時間地點 August 23-25, 2010 Macau SAR, P.R.C

會議名稱 16th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA 2010)

發表論文題目 Design and Implementation for Multi-Level Cell Flash Memory Storage Systems

一、 參加會議經過

IEEE International Conference on Embedded and Real-Time Computing Systems and Applications 是即時暨嵌入式系統領域裡重要的會議之一，2010 年於 8 月 23 日至 8 月 25 日在澳門舉行，

共有 17 個不同的國家投稿，共接受 41 篇論文。今年的 keynote talk，大會邀請到了即時系統 領域的權威，University of Texas at Austin 的 Aloysius Mok 教授，以及 Polytechnic of Porto, Portugal 的 Luis Miguel Pinho 教授來演講，講題分別為『From Scheduling to Cyber-Physical Systems – A Real-Time Systems Research Perspective』以及『Real-Time Programming Paradigms

and Languages』。演講內容精彩，並且涵蓋了目前最新的研究趨勢與技術，令申請者受益非淺。

在這一次的國際學術會議中，報告者有 30 分鐘的時間，來發表自己的研究成果，並回答 在場與會的學者專家所提問的相關問題。申請者所投稿之論文『Design and Implementation for Multi-Level Cell Flash Memory Storage Systems』，是被安排於 8 月 25 日的 Session 8 報告投稿 之論文。申請者順利於時間內完成論文的口頭報告，並且與在場的學者專家討論相關研究問 題。而申請者所報告的論文則是被編排於 IEEE RTCSA Proceedings 中的第 247 頁至第 252 頁。

二、 與會心得

參加這次國際會議最大的收穫，除了瞭解到即時暨嵌入式系統這個領域最新的研究趨勢之 外，就是與各國的研究學者進行交流。申請者在這次會議中，認識到許多即時暨嵌入式系統 領域的先進，包括：IEEE RTCSA 國際會議的發起人之一，香港浸會大學的吳其彥（Joseph Kee-Yin NG）教授、此次會議的議程主席（Program Chair）Jason Xue 教授、香港專業教育學 院電子計算系系主任梁秉雄博士、University of Texas at San Antonio 的 Dakai Zhu 教授、香港 城市大學的 Victor Lee 教授、香港理工大學邵子立教授等等。參與此次國際會議讓申請者收 穫良多，獲得了許多寶貴的意見與想法，在在都可以幫助申請者在未來研究上的進步，進而 完成更有品質、更有學術貢獻價值的論文。

無衍生研發成果推廣資料

98 年度專題研究計畫研究成果彙整表

計畫主持人：謝仁偉 計畫編號：98-2221-E-011-070- 計畫名稱：多層單元快閃記憶體儲存系統之設計

量化

成果項目 ^{實際已達成}

數（被接受 或已發表）

預期總達成 數(含實際已

達成數)

本計畫實 際貢獻百

分比

單位

備 註 （ 質 化 說 明：如 數 個 計 畫 共 同 成 果、成 果 列 為 該 期 刊 之 封 面 故 事 ...

等）

期刊論文 0 0 100%

研究報告/技術報告 0 0 100%

研討會論文 0 0 100%

論文著作 篇

專書 0 0 100%

申請中件數 0 0 100%

專利 已獲得件數 4 0 0% 件

件數 0 0 100% 件

技術移轉

權利金 0 0 100% 千元

碩士生 4 4 50%

博士生 0 0 100%

博士後研究員 0 0 100%

國內

參與計畫人力

（本國籍）

專任助理 0 0 100%

人次

期刊論文 2 0 20%

研究報告/技術報告 0 0 100%

研討會論文 1 1 80%

論文著作 篇

專書 0 0 100% 章/本

申請中件數 0 0 100%

專利 已獲得件數 0 0 100% 件

件數 0 0 100% 件

技術移轉

權利金 0 0 100% 千元

碩士生 0 0 100%

博士生 0 0 100%

博士後研究員 0 0 100%

國外

參與計畫人力

（外國籍）

專任助理 0 0 100%

人次

其他成果

(無法以量化表達之成

果如辦理學術活動、獲 得獎項、重要國際合 作、研究成果國際影響 力及其他協助產業技 術發展之具體效益事 項等，請以文字敘述填 列。)

獲邀參與以下學術活動：

1. General Chair, International Workshop on Software Support for Portable Storage (IWSSPS 2010)

2. Session Chair (Session 10 Architecture and Practice I), the 16th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications (IEEE RTCSA 2010)

3. Local Arrangement Chair, the 8th IEEE International Symposium on Parallel and Distributed Processing with Applications (IEEE ISPA10) 4. Workshops Chair, the 8th IEEE International Symposium on Parallel and Distributed Processing with Applications (IEEE ISPA10)

5. Program Committee Member, International Workshop on Software Support for Portable Storage (IWSSPS 2010)

6. Program Committee Member (Track on Embedded Systems), the 12th IEEE International Conference on High Performance and Communications (HPCC) 7. Program Committee Member (Track 3. Ubiquitous Computing and Mobile Systems), the the 3rd International Conference on Human-centric Computing (HumanCom-10)

成果項目 量化 名稱或內容性質簡述

測驗工具(含質性與量性) 0

課程/模組 0

電腦及網路系統或工具 0

教材 0

舉辦之活動/競賽 0

研討會/工作坊 0

電子報、網站 0

科 教 處 計 畫 加 填 項

目 計畫成果推廣之參與（閱聽）人數 0

國科會補助專題研究計畫成果報告自評表

請就研究內容與原計畫相符程度、達成預期目標情況、研究成果之學術或應用價 值（簡要敘述成果所代表之意義、價值、影響或進一步發展之可能性）、是否適 合在學術期刊發表或申請專利、主要發現或其他有關價值等，作一綜合評估。

1. 請就研究內容與原計畫相符程度、達成預期目標情況作一綜合評估

■達成目標

□未達成目標（請說明，以 100 字為限）

□實驗失敗

□因故實驗中斷

□其他原因 說明：

2. 研究成果在學術期刊發表或申請專利等情形：

論文：□已發表 □未發表之文稿 ■撰寫中 □無 專利：□已獲得 □申請中 ■無

技轉：□已技轉 □洽談中 ■無 其他：（以 100 字為限）

研究成果已在國際研討會 16th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA 2010) 中發表。

3. 請依學術成就、技術創新、社會影響等方面，評估研究成果之學術或應用價 值（簡要敘述成果所代表之意義、價值、影響或進一步發展之可能性）（以 500 字為限）

本為期一年的專題研究計畫提出了一個針對多層單元快閃記憶體儲存系統所設計的機 制，同時考慮了多層快閃記憶體所帶來的新挑戰與檔案系統的存取特性，因此在效能優於 其他相關的機制。我們的機制會針對不同的存取行為，採取不同的管理方式，並且採用混 合型的對應方式，在效能與記憶體需求之間取得平衡。我們的研發成果不但可以立即應用 在最新的快閃記憶體產品上，所有參與計畫的學生也於相關的快閃記憶體儲存系統發展 上，獲得很好的研究經驗。