基於固態硬碟的韌體演算法與硬體架構快速標準制訂工具

(1)

國立交通大學

資訊科學與工程研究所

碩士論文

基於固態硬碟的韌體演算法與硬體架構快速標

準制訂工具

A Rapid Algorithm/Architecture Prototyping Tool for

Solid-State Drive

研究生：郭晉廷

指導教授：張立平教授

(2)

基於固態硬碟的韌體演算法與硬體架構快速標準制訂工具

A Rapid Algorithm/Architecture Prototyping Tool for Solid-State Drive

研究生：郭晉廷 Student：Ching-Ting Kuo

指導教授：張立平 Advisor：Li-Pin Chang

國立交通大學

資訊科學與工程研究所

碩士論文

A Thesis

Submitted to Institute of Computer Science and Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science

June 2010

Hsinchu, Taiwan, Republic of China

(3)

II

基於固態硬碟的韌體演算法與硬體架構快速標準制訂工具

學生：郭晉廷

指導教授：張立平

國立交通大學資訊科學與工程研究所

摘要

固態硬碟所採用的快閃記憶體具有獨特的物理特性，不論在韌（軟）體或硬體都需要採用特殊的設計策略。目前不論就硬體架構與資料管理演算法方面，都已經有許多良好的設計方案可供選擇。然而，固態硬碟的整體效能表現，取決於軟體，硬體，以及工作環境三大要素的交互影響。如何在已知的產品定位下尋找最佳的軟硬體組合，以達到最佳的效能成本比，則需要反覆的調整與測試，且為一曠日費時的工作。為了克服此一設計上的課題，本研究計畫開發了一個固態硬碟的快速雛型工具，該工具提供非常豐富的軟硬體設計選擇，並以相當簡易一致化的程式介面呈現。該工具可幫助系統工程師快速地測試不同的軟硬體組合的效能，而可大幅減少系統工程師在調校與測試方面的時間。關鍵字：固態硬碟，效能模擬，雛型工具

(4)

III

A Rapid Algorithm/Architecture Prototyping Tool for Solid-State

Drive

Student：Ching-Ting Kuo

Advisor：Dr. Li-Pin Chang

Department of Computer and Information Science

National Chiao Tung University

Abstract

Designing high performance solid-state disks is a very challenging task because of the diversity of host applications, complexity of SSD hardware architectures, and firmware algorithms. SSD performance is mainly subject to not only hardware designs but also software algorithms. One practical problem that industry faces is how to combine hardware/software design options for the best performance under a specific niche market. This study introduces a fast hardware-software prototyping tool for SSD design. It features a set of highly simplified programming interfaces and a rich collection of hw/sw design options. This tools aims at reducing the cost of debugging and help to find out the best design without lengthy trial-and-error cycles.

(5)

IV

誌謝

謝謝交大，謝謝土地公，謝謝你總在奇蹟的一刻回應無神論的我的祈禱。謝謝張立平老師，謝謝您！聽說過很多嚴格老師帶學生的方式，相比之下我深深感受到您的體貼入微，在您眼中我是個難搞的人吧！時常誤會老師的意思，有時候則是我沒有把想法清楚表達出來，老師應該沒遇過這麼有溝通障礙的學生吧？幸好我是個還算牛的人，總會刻苦耐勞把老師的要求做好，有機會我真的很想跟老師當好朋友，但老師恐怕很害怕讓我讀博班吧？不過我也不想讀啦！我還是沒辦法喜歡上做研究，務實一點對我的簡單頭腦比較沒有負擔，再次謝謝您。謝謝我的家人，謝謝爸爸，不管我做什麼都給我支持，謝謝媽媽，我可以從眼神中感覺您對我的呵護，謝謝您們對我生活上的一切支援，不管是機車、房子還是電腦，也謝謝妹妹，雖然妳好像沒什麼實質的幫助，但妳的存在就是對我的鼓勵。很抱歉接下來又要在新竹工作，但我保證有時間就會回家去的，謝謝！謝謝我親愛的同學們，給話很少很悶燒兼戰友再兼未來同事的偉杰，謝謝你陪我經歷過的所有，不管是 wrk、游泳、魔獸、衝浪還是喝酒都讓我印象深刻，給講話總是理直氣壯讓我很想跟你吵架的義勛，謝謝你常常跟我討論研究上的問題，你也畫出我人生另一塊視野，給有貴婦氣質但卻做很多傻事的莉君，我們原先真的可以是很要好的朋友，可能我這個人比較固執吧！總之，祝福妳。最後再次謝謝你們這些朋友，我無法想像人生中沒有你們的存在，以後務必要常相聚。謝謝 ESSLAB 的前輩，謝謝畢業前後的你們對我的關心，謝謝士庭、明毅、宥全、Show、JJ、小狐狸和學姊，謝謝你們不吝於對我的經驗分享與指導，除了打球、打電動、烤肉，我也會永遠記得每一次的謝師宴。謝謝 ESSLAB 的後輩，謝謝阿誠、小節、玟蕙和 Uma，謝謝你們讓我了解指導別人前要先教育自己的準則，你們經歷很多，而那些也讓我感同身受，花蓮行的美好時光我會一直放在心底，也謝謝碩 0 的阿平、A 導和逸康，謝謝你們，希望我們在未來一起努力。謝謝很多很多新舊朋友，謝謝成大 GY 團的不離不棄，謝謝創惟夥伴們給的學習機會，謝謝東大同學們的相伴，謝謝其他實驗室的球友，謝謝彰師大朋友們的關心，謝謝 RTOS 修課同學們的支持，謝謝國科會計畫的教授、同學和負責人，謝謝口試委員的指導，謝謝神秘朋友給我的心靈經驗，謝謝很多很多人，你們都是影響這篇論文產生的蝴蝶效應中重要的一環，謝謝！最後的最後，謝謝我自己，只想對自己說一聲：「辛苦了，幹得好！」

(6)

V

圖目錄

圖 1、快閃記憶體的物理結構 ... -4-

圖 2、SOLID STATE DRIVE硬體架構 ... -5-

圖 3、各類型 FLASH TRANSLATION LAYER的 GC 流程 ... -6-

圖 4、SSD 硬體元件... -8- 圖 5、SSDINTER-CHIP硬體架構 ... -9- 圖 6、RAPT 操作示意圖 ... -10- 圖 7、INDEX標準模型關係圖 ... -14- 圖 8、INDEX應用範例 ... -14- 圖 9、ASSOCIATION標準模型關係圖... -15- 圖 10、ASSOCIATION應用範例 ... -16- 圖 11、PRIORITIZATION標準模型關係圖 ... -16- 圖 12、PRIORITIZATION應用範例 ... -17- 圖 13、RAPT 系統架構圖 ... -19- 圖 14、BAST、FAST 和 N-K 的寫入對應關係 ... -20- 圖 15、BAST、FAST 和 N-K 的 GC 範圍 ... -21- 圖 16、BAST、FAST 和 N-K 的寫入共同架構 ... -22- 圖 17、N-K 與 KAST 的 ASSOCIATION模型使用示意圖 ... -23- 圖 18、RAPT 硬體模組架構圖 ... -24- 圖 19、硬體模組模擬示意圖 ... -25- 圖 20、CHANNEL運作示意圖 ... -25- 圖 21、INTERLEAVE運作示意圖 ... -26- 圖 22、資料搬移運作示意圖 ... -26- 圖 23、PLANE運作示意圖 ... -26- 圖 24、非對稱性 SSD 架構 ... -27- 圖 25、RAPT 軟體模組架構圖 ... -28- 圖 26、RAPT 使用者開發介面 ... -28- 圖 27、SSD 硬體溝通示意圖 ... -30- 圖 28、韌體演算法讀取驗證 ... -32- 圖 29、韌體演算法寫入驗證 ... -32- 圖 30、不同MAPPING單位的 FTL 效能 ... -37- 圖 31、加入 SEQUENTIAL優化機制後的 FTL 比較 ... -38- 圖 32、LOG-BASED FTL 中 N 與 K 的對應關係 ... -39- 圖 33、LOG-BASED FTL 中 N 與 K 的對應關係 ... -40-

圖 34、不同 OVER PROVISIONING下 LOG-BASED FTL 的效能 ... -41-

圖 35、平行演算法效能表現 ... -43-

(9)

VIII

圖 37、SYNCHRONIZED和 INDEPENDENT-CHANNEL的比較 ... -45-

圖 38、混合式 MULTI-CHANNEL在 WINDOWS上的表現 ... -45-

圖 39、INTERLEAVE的效能表現 ... -46- 圖 40、COPY-BACK的效能表現 ... -47- 圖 41、MULTI-PLANE的效能表現 ... -48- 圖 42、各種硬體架構的效能提升率 ... -49- 圖 43、最佳 SSD 架構的效能 ... -50- 圖 44、BUFFER大小對 IND-CHANNEL架構的影響 ... -51- 圖 45、DATA PLACEMENT優先權關係... -53- 圖 46、DATA PLACEMENT對效能的影響 ... -53- 圖 47、韌體機制優劣對硬體架構的影響 ... -54- 圖 48、各種 FTL 在 MULTI-CHANNEL的表現 ... -55- 圖 49、CHANNEL數量對 SYNCHRONIZED架構下 FTL 的影響 ... -56-

圖 50、OVER PROVISIONING對高平行架構下 FTL 的影響 ... -56-

圖 51、各種 FTL 在 4-INTERLEAVE中的表現 ... -57-

(10)

IX

表目錄

表 1、SLC 與 MLC 比較... -4- 表 2、時間影響參數對照表 ... -31- 表 3、硬體架構寫入驗證... -33- 表 4、實驗參數設定 ... -34- 表 5、WORKLOAD分析結果 ... -35- 表 6、FTL 關係對照表... -42-

(11)

- 1 -

1. INTRODUCTION

近年來由於筆記型電腦、手機、PDA 等可攜式裝置的蓬勃發展，固態硬碟（Solid State Drive，簡稱 SSD）的技術和應用也一再被探討，再者傳統硬碟（Hard Disk）具有低耐震、體積大、壽命短且發出噪音等為人詬病的缺點，因此 SSD 在可攜式裝置上取代傳統硬碟已成為必然的趨勢，同時它所擁有的快速隨機讀寫能力更可以作為高效能需求的伺服器應用，雖然市場需求日益加溫，但 SSD 仍有價格高的困境必須克服，因此如何找到 SSD 成本和效能的平衡點是目前最重要的議題。如何發揮 SSD 效能的解答在於如何設計它，SSD 是由 NAND 快閃記憶體（Flash Memory）所組成，設計上可以分為硬體和韌體兩部分，硬體包含快閃記憶體晶片（Flash chip）、訊號線（Control line）和資料匯流排（Bus）等，設計上需要考慮各種元件的平行架構與其之間的排列關係，而韌體的必要性是由於 NAND Flash 不同於傳統儲存裝置的各種特性，需要採用特殊的演算法去設計，而不同的演算法在不同的用途中也會表現不一樣的效能，因此充滿變化。綜合而言， SSD 的設計可以分為硬體架構（ Hardware Architecture）和韌體演算法（Firmware Algorithm）兩大議題，而兩大議題又彼此有關連，例如不同的硬體架構就需要相對應的韌體演算法支援。 SSD 韌體設計的作用是穩定各類型存取的效能，由於 Flash 具有的物理特性，需要採用特殊的機制去處理，但為了實現這些機制通常會對系統產生額外的負擔，像是使用較多的隨機存取記憶體（RAM）或者花費額外的時間搬移資料，而且這些機制在面對不同的存取行為（Workload）時會表現不同的效能，這些行為包含存取的空間與時間性，各種影響因素像是隨機或循序、密集度、次數和頻率等，因此 SSD 韌體演算法設計的目標就是在不減少系統負擔的前提下，平衡各種用途不同存取行為的效能。 SSD 硬體設計的需求是提升循序存取的效能，由於不同的 Flash chip 可以獨立存取資料，通常會將要求存取的資料（Request）分散到不同的 Chip 處理，因此增加 Flash chip 的數量除了增加容量外更可以增加 SSD 平行處理的效能，但每顆 Chip 是否可以平均分配到 request 就變成影響平行處理效能的關鍵，所以 SSD 硬體設計一般增加的是循序存取的效能，因為循序資料或較大筆的資料可以使 Flash chip 的利用度較高，平行處理的效能就比較明顯，相反的隨機存取的效能則會被限制。現今產業界在 SSD 的開發過程最常遇到問題有兩點，第一點是“不知道什麼是最好的硬體和韌體組合”，一般的大型系統如資料庫上較多循序、低頻率存

(12)

- 2 - 取的資料，且要求回應時間較短，所以必須考量高平行度高效能的硬體架構，小型系統像筆記型電腦等的存取行為則比較複雜，很多隨機、高頻率存取的小檔案，必須透過韌體吸收掉這種存取造成的效能負擔，因此 SSD 在大型系統和小型系統的效能需求就會不一樣，如果把適合大型系統的硬體架構用在小型系統上就會因為平行利用度不足而使得效能發揮不如預期，而用在小型系統的韌體演算法通常會針對高頻率存取的資料做特別處理，若這種演算法用在大型系統上則會因為並沒有這類型資料而產生額外的負擔，於是怎樣的硬體和韌體設計最好？以及怎樣的搭配最適合怎樣的應用？開發人員往往無法選擇。而 SSD 開發的第二個問題就是“過長的產品開發與測試週期”，從規劃硬體架構、撰寫韌體演算法到實際產品測試，往往需要很長一段時間才能得到結果，很多時候發現有錯誤或結果不如預期時，這些步驟就必須重新來一次，因此如何縮短開發週期卻又不降低品質也是開發者想知道的。本篇針對 NAND Flash 的 SSD 提出一個韌體演算法和硬體架構的標準制定工具（Rapid Algorithm/Architecture Prototyping Tool），簡稱為 RAPT，使用比硬體測試更加快速的軟體技術來設計 SSD，因此不僅有效解決開發週期過長的問題，其定義的標準模型更可以提供各種韌體演算法的概念，幫助開發者找到適合的設計。 RAPT 建立一個仿真的軟體環境，模擬 Flash-based SSD 的韌體和硬體運作。首先，其建立完整的 SSD 架構，包含豐富的硬體元件與指令支援，並結合 System C [1]函式庫增加模擬的效能與準確度，使用者可以很輕易的勾勒出希望的 SSD 架構。其次，RAPT 提出了一套 SSD 韌體演算法的標準模型，這套模型也符合 NAND Flash 的特徵，適用於所有 NAND Flash 的儲存裝置，它清楚點出設計概念與方法，因此可以利用它快速且容易的實現任何一種韌體演算法。最重要的是，RAPT 所建立的硬體和韌體環境都具有 SSD 設計的共通性，因此修改十分方便，換句話說若要由一種架構改成另一種架構或者由演算法 A 改成演算法 B 都不需要對程式做大幅度的更動。 RAPT 的開發目標是成為一套實務且便捷的工具，站在使用者的角度，不需要具備豐富的硬體或電路知識，也不需要熟知各類型的韌體演算法，就可以透過它快速的完成模擬 SSD 的工作。RAPT 首先必須實現各種硬體架構，像傳輸通道（Channel）、通道群（Gang）、通道葉（Interleave）等，為了真實符合現今的 Flash 設計，也提供 Copy-Back 和 Multi-Plane 等優化指令，這些原本複雜的硬體架構或平行關係除了實現之外還要簡化成為一套僅有數個參數的 API，且簡化後要能不失其功能性。其次，RAPT 要建立一組有效的韌體描述語言，韌體演算法的設計包含緩衝區（Buffer）、位址轉換（Address Mapping）、回收（Garbage Collection）等眾多議題，任何一點的變動都可以視為不一樣的演算法對 SSD 產

(13)

- 3 - 生不同的結果，而且不同議題的設計也是彼此相關的，很可能因為其中一部分的更動而導致演算法全盤的重新設計，而這些動作可以抽象為 Index、Group 和 Queue 三種模型標準，首先必須將各種設計議題視為平等，才有辦法以一種概念討論所有的設計變化，目的在於即使差異很大的韌體演算法，也可以用相同的設計架構去完成它，現存已知的 SSD 韌體演算法都可以用這三項標準去制定，這樣做的好處是不論設計或修改演算法都可以更加清楚且快速的完成。一個模擬環境的實作需要考量很多面向，首先是模擬的準確度，隨著參數的調整模擬誤差可能越來越大，因此與真實結果的比較是必須的，但通常實際產品內部的設計方法難以取得，所以要達到準確度的目標通常必須實作真實的硬體。其次是模擬的多樣性，一個工具提供的環境能夠模擬越多類型的設計，用途就越廣泛、價值也越高，但也表示其功能與支援必須越多，在開發與維護上也會花費越多時間。最後是穩定性與效能，需要多少系統資源才能完成某項模擬？模擬的速度又可以多快？這些全都是 RAPT 必須考慮的，因此與真實 SSD 做準確度的比較、提供豐富的硬體或韌體支援還有優化執行效能都是必要的工作。本篇餘下的章節如下：第二章介紹 SSD 設計的文獻以及目前已發表的軟體模擬工具，第三章說明 RAPT 的韌體開發概念，第四章討論實作以及給予 SSD 的設計支援，第五章探討各種韌體演算法與硬體架構的組合，並實現 RAPT 的驗證，第六章為本篇的結論與未來展望。

(14)

- 4 -

2. PROBLEM FORMULATION 2.1 Background

一顆 Flash chip 是由很多區塊（Block）組合而成，每一個區塊包含很多頁（Page）。如圖 1 所示，page 中包含使用者部分（User area）和備用部分（Spare area），User area 就是一般存取資料的區域，而 Spare area 是韌體的保留區通常用來記錄位址轉換或位元錯誤校正等資訊，其中 User area 又可細分多個區段（Sector），sector 是使用者可以存取的最小單位，一個 sector 為 512 byte，而 page 和 block 的大小則隨著設計不同有所變化，普遍來說一個 page 有 4~8 個 sector，而一個 block 有 32~128 個 page。 ‧ ‧ ‧ ‧ Block 0 Block 1 Block 2 Block N Block 3 Flash Chip ‧ ‧ ‧ ‧ Page 0 Page 1 Page 2 Page 63 Page 3 Block

User area Spare area

Page

Sector 0 Sector 1 Sector 2 Sector 3

圖 1、快閃記憶體的物理結構

Flash 內部的讀取（Read）和寫入（Write）是以 page 作為單位，不同於傳統硬碟，Flash 採用電子式的運作方式，其無法在寫過的 page 上重複寫入資料，除非經過抹除（Erase）的動作將寫過的 page 清掉才能再次寫入，erase 是以 block 為單位，且經過一定次數的 erase 後，那個 block 就不能再被使用，這種被限制的 erase 次數，我們稱為 Flash chip 的磨損容忍度（Endurance）。

表 1、SLC 與 MLC 比較

SLC MLC

Page / Block size 2 KB / 128 KB 4 KB / 512 KB Read latency 25 μs 60 μs Write latency 200 μs 800 μs Erase latency 1500 μs

Endurance 100 K 5 K

Flash 依製程可以分為 Single Level Cell（SLC）和 Multi Level Cell（MLC）兩種，SLC 表示單位晶元中可以存取一個位元的資料，而 MLC 則是單位晶元中允許存取多位元的資料，因此相對而言 MLC 的單位價格較便宜，但是 MLC 的

(15)

- 5 -

存取速度較慢，Endurance 也較低。表 1 為 Samsung 的 Flash chip [2]規格，由表 可見 SLC 性質優於 MLC，但兩者共通的是讀取速度遠快於寫入速度，而寫入又比 erase 更快。

圖 2、Solid State Drive 硬體架構

SSD 是由多顆 Flash chip 所組成，是 Flash 極致的一種表現，圖 2 為一個典型的 SSD 硬體架構，其傳輸介面和傳統硬碟相同，採用 SATA [3]、PCI [4]等規格，資料進出前會先交由處理器（Controller）處理，所謂韌體指的就是處理器負責的動作，為了應付 Flash 的物理特性，韌體必須採用各種機制加以處理，Flash Translation Layer（FTL）就是為了實現這些機制所加入的轉換層，現今由於效能的考量，許多 SSD 又會在傳輸介面和處理器之間增加一塊 RAM 作為緩衝區（Buffer），其同樣由處理器管理，因此這邊把 Buffer 的管理機制和 FTL 合稱為 SSD 的韌體演算法（Firmware Algorithm），而 Flash chip 之間排列方式的討論則為 SSD 的硬體架構（Hardware Architecture）。

(16)

- 6 -

2.2 SSD Firmware Algorithm

SSD 的韌體設計包含 Flash Translation Layer（FTL）、緩衝區的替換機制（Buffer Replacement）、錯誤校正（Error Correction Code，ECC）和壞區塊偵測（Bad Block Detect）等，其中 FTL 和 Buffer 是韌體設計中影響 SSD 效能的關鍵，因此在本節稍作討論。

有關 FTL 的設計可以分為幾個議題，首先，由 Host 來的存取要求（Request）和實際被放入 Flash 中的位址通常不會一樣，因此需要將被寫入 page 本來的位址記錄下來，這種紀錄位址的行為稱為 Address Mapping。其次，由於 Flash 讀寫是以 page 為單位，但 erase 是以 block 為單位，因此每次進行 erase 之前必須把在 block 中還有效 page 搬移到別的 block，這種分類後回收的機制稱為 Garbage Collection（GC）。同時，為了減緩 block 超出 erase 次數限制而壞掉發生的情況，設計時會想辦法平均每一個 block 的 erase 次數，以延長 Flash 的使用壽命，這種機制稱為 Wear Leveling（WL）。 X Write Copy Copy

X

Erase

a、 Block Level FTL

X

Erase

X

Erase Log block Data block

New data block

Copy c、Log-based FTL

X

Erase Copy b、Page Level FTL

圖 3、各類型 Flash Translation Layer 的 GC 流程

最陽春的 FTL 是採用 in-place 的寫入方式，即資料寫在指定的位址，由於大部分的 NAND Flash 無法容許隨機的寫入，也就是說每一次寫入的 page 必須接續上一次這個 block 寫到的位址，因此每次在做這種 in-place 的寫入之前都必須將原本 block 的資料循序複製到新的 block，同時將要寫的 page 寫到新的 block，最後對原 block 做 erase 的動作並以新的 block 取代原本的，如圖 3a 所示，這種方法每一次寫入需要付出較高的時間成本，但 RAM 裡面只需要紀錄 block 的位

(17)

- 7 -

址，又稱為 Block Level FTL。於是為了改善效能，產生另一種 out-place 的寫入方式稱為 Page Level FTL，它將不同位址的資料依序寫入到空的 block 中，當 block 用完時必須做 GC 將有效資料複製出來，如圖 3b，這種方法每次 GC 後可以得到一個空的 block，經過寫滿一個 block 的時間才需要再次 GC，且每次 GC 所花費的時間成本較低，但缺點是必須紀錄每一個 page 的位址，RAM 的需求十分龐大。

現今多採用 Log-based 的 FTL，其結合 Block Level 和 Page Level 兩種方法，將 block 分為 data block 和 log block 兩種，使用者只會看到 data block 的部分，所以寫入 request 的位址都是 data block 的部分，但資料實際上會以 out-place 的方式存到 log block 裡，每次寫完一個 log block 就再配置一個，至於未配置的 log block 則稱為 spare block，而當 spare block 用完時就必須做 GC，如圖 3c 所示，它的 GC 要做一個合併（Merge）的動作，就是將 log block 裡面的有效 page 及其本來所屬的 data block 以 in-place 的方式搬移到新的 data block 中，然後 erase 本來的 data block，一直重複 merge 的動作等到所有 log block 中的有效 page 都被搬走後再將 log block 做 erase，而 erase 後的 block 都放到 spare block 中等待再次被配置。這種 Log-based 的 FTL 不僅能有效節制 RAM 的消耗，且效能表現佳，甚至 Page Level 像 Super Block FTL [5]也曾引用到這種 log block 的概念，因此目前廣泛被使用在 SSD 上面，其包括各式各樣的類型像是 BAST [6]、FAST [7]、 N-K [8]等，本篇的討論也多以 Log-based FTL 為主。

採用 Buffer 的主要目的是可以馬上吸收掉 request，避免回應時間過長，因此 Buffer 通常使用存取速度較快的 DRAM 實現，Buffer 又分為 Read 和 Write buffer，這裡討論的 Buffer 都作為 Write 用途，Buffer 寫滿後要做寫回（Write Back）的動作，於是該挑哪一筆資料寫回這個問題就衍伸許多不同的機制，像 First In First Out（FIFO）、Least Recently Used（LRU）等就是基本的方法，大部分的 Buffer Replacement 機制都是為了保留頻繁存取的資料，以減少寫回的次數。在 SSD 的設計上，Buffer 的使用還可以增加系統的平行度，由於隨機存取的行為容易造成不同 Flash chip 的資料分配不平均，因此可以透過 Buffer 的挑選機制把 request 平均分散到不同 Chip 上，這也將在之後做討論。

(18)

- 8 -

2.3 SSD Hardware Architecture

硬體設計的技術主要著重在資料的平行處理，可以大幅增加循序資料的處理速度，分為外部設計（Inter-Chip）和 Flash chip 內建（Intra-Chip）兩種，Inter-chip 的設計指的就是 Flash chip、資料線（Data line）和訊號線（Chip enable line）之間的組合，可以分為同步運作通道（Synchronized-Channel，簡化為 Syn-Channel）、獨立運作通道（Independent-Channel，簡化為 Ind-Channel）和共用通道（Interleave 或 Shared-Bus），而目前常見的 Intra-chip 設計則包含 Multi-Plane 和 Copy-Back。由於 Intra-chip 的限制較多且平行度較低，因此 Inter-chip 的設計就變成硬體設計中提升 SSD 效能的關鍵。

在 Flash 寫入的過程，資料會先由 Host 進入 SSD 的 Buffer，然後再由 Buffer 寫入 Flash chip 內部的暫存器（Register），這段時間稱為傳輸時間（Bus Delay），其多寡取決於用來搬移資料的處理器或 DMA（Direct Memory Access）的速度，但瓶頸也有可能在於 register 的存取速度，接著資料會再由 register 寫入到 Flash chip 中，這段時間稱為內部存取時間（Chip Busy），不同規格的 Flash chip 或不同行為的 Chip busy 時間也會不一樣（參考表 1），這兩段時間是 SSD 資料平行處理的主要考量。 Chip CE1 Chip Chip CE0 Bus0 Chip Bus1 Plane Flash Chip Register Chip CE3 Chip Chip CE2 Bus2 Chip Bus3 Channel0 Channel1 Channel2 Channel3

Gang0 Gang1 Plane Register Bus3 CE2 圖 4、SSD 硬體元件

Inter-chip 的硬體架構可以根據 Flash chip、Data line 和 Chip enable line（CE）三種硬體元件的組合來分類，Data line 即為 Bus，是資料傳輸的通道，CE 則是訊號線，是處理器用來啟動 Flash chip 動作的管道。如圖 4 與相同 Data line 連接的 Chip 稱為一個通道（Channel），每一個 Channel 必須由一個處理器或 DMA 負責資料傳輸的工作，而連接相同 CE 的 Channel 又稱為通道群（Gang），連接相同 CE 的 Chip 則必須同時運作，每一個 Channel 中相同對應位址的 Chip 又合稱

為晶片排（Bank），Gang 和 Bank 都必須保持資料的平行度，其中 Gang 中的每

(19)

- 9 - 著數倍大小的 block 和 page。

經由上述硬體元件的組合， Inter-chip 的架構可以簡單歸類為三種： Syn-Channel、Ind-Channel 和 Interleave，如圖 5a 所示，Syn-Channel 就是 1-Gang 的表現，每一個 Channel 可以同時存取資料，但由於 CE 是共用的，因此就算其中一個 Channel 沒有工作但也必須存取和另一個 Channel 相同的位址，所以為了增加 Channel 的利用度較適合處理循序的資料。相反的，圖 5b 的 Ind-Channel 架構下 Gang 與 Gang 的 CE 是不同的，因此可以獨立的運作並存取不相同的位址，這種設計可以適應較複雜的 Workload，但要如何平行不同 Channel 的工作也值得思考。圖 5c 為 Interleave 的架構，其 CE 分開，但 Bus 共用，因此必須輪流傳輸資料，Bus delay 的時間無法重疊，因此平行度低於 Syn-Channel 或 Ind-Channel。

Chip CE0 Bus0 Chip Bus1 Chip CE0 Bus0 Chip Bus1 CE1 Chip CE1 Chip CE0 Bus0

a、Synchronized-Channel b、Independent-Channel c、Interleave 圖 5、SSD Inter-Chip 硬體架構

Intra-chip 的硬體支援包括 Copy-Back 和 Multi-Plane。Copy-Back 是 Flash chip 提供的特殊指令，使同一顆 Chip 的資料搬移可以不經過 Bus，而是直接透過 register 的讀寫來完成，因此相較於一般的搬移動作免去兩次的 Bus delay，但缺點是不經過 Bus 也就不會經過處理器，因此無法對資料做額外的處理例如錯誤校正（ECC）等，所以使用上會有一定的風險。一般的 Flash chip 可以分為多個區階（Plane），如圖 4 每一個 Plane 都有一個 register，Plane 的資料讀寫都可以經過 register 來完成，因此同一顆 Chip 的不同 Plane 可以同時進行 Chip busy 的工作，其平行度類似 Interleave，但限制是 Plane 必須同時運作而且要存取相同的位址，這種 Multi-Plane 的行為是大部分 Flash chip 所支援的特殊指令，其支援的行為包含 read、write 和 erase。

(20)

- 10 -

2.4 Design Objectives

RAPT 提供一個軟體模擬的環境，允許事先評估可行的 SSD 設計，使用者可以自由規畫所需要的韌體演算法和硬體架構，然後透過 RAPT 的建構成為一個虛擬的 SSD。如圖 6 所示，在 RAPT 中使用者可以接觸到的部分包括兩個輸入檔案 Design 和 Trace 以及一個輸出檔案 Result，Design 是一個.cpp 檔，RAPT 的函式庫提供各種 API，使用者引用後就可以利用那些 API 完成韌體部分包含 Buffer、FTL 等設計以及硬體部分包含架構、規格的定義，這些設計或定義就寫在 Design 檔案內，Trace 則是使用者要測試的存取行為（Workload），以文字檔表示，這兩個輸入檔在經過 RAPT Interface 整合後首先會根據 Design 檔的設定產生一個虛擬 SSD，內容包含對應的硬體和韌體模組，再透過虛擬 SSD 執行 Trace 中的存取行為，並且將最後的結果輸出到 Result 檔案，預設輸出的內容包含效能（Throughput）、磨損情況（Wear state）等統計資料。 Trace file (.log or .txt) Result file (.txt) Design file (.cpp) Firmware Module Hardware Module Interface RAPT User area API 圖 6、RAPT 操作示意圖

為了確保 RAPT 的實用性，我們規範了功能性（Function）、可靠性（Reliability）和移植性（Portability）三項指標，並且個別進行測試，功能性要求 RAPT 所提供的 API 必須能夠快速實現目前知名的 FTL 像是 BAST、FAST、N-K 等，並且可以正確模擬已知的 SSD 規格以及架構，可靠性部分將以真實 SSD 進行驗證，我們定義在各項硬體參數值正確的情況下，模擬誤差不能高於 10%，最後關於系統移植性，RAPT 是由 C++搭配 System C 函式庫實作完成，因此允許在 Windows 或 Unix 平台上編譯執行，是具有高度可攜性的系統。

(21)

- 11 -

2.5 Related Work

以軟體模擬硬體的概念很早就被提出來，各類型的模擬器（Simulator）也行之有年，近幾年 SSD 的熱度持續飆高，因此各種模擬與測試方法也一再被提出來，本節針對已發表的 NAND Flash-based SSD simulator 作討論，它們有各自的做法或用途，但目的都是為了正確模擬 SSD 的行為。

微軟公司（Microsoft）的 Nitim Agrawal*等人首先提出基於 Disksim [9]的 simulator，並以此為基礎發表 SSD Design Tradeoffs [10]，其歸類 SSD 效能的瓶頸，並整理出各種 SSD 的硬體架構，將可平行化的硬體元件分為 Gang、Die、 Plane 三個層級，同時測試各種組合與設定下的效能，對於 SSD 架構的認識有很大的幫助。隨後 Ji-Yong Shin 等人又以相同的 simulator 發表關於 High-Performance SSD [11]的研究，主旨以 Page Level FTL 為基礎探討在高平行度的架構下各種添加的 FTL 設計方法，其討論包括資料擺放位址（data allocation）、冷熱資料分離（hot/cold separation）和資料傳輸平衡（load balance）等。兩篇對於 SSD 的硬體和韌體上分別提供前瞻性的研究，但其所採用的 simulator 架構完全與 Disksim 綁死，因此韌體與硬體的架構難以修改，Disksim 本來用於模擬傳統硬碟，其原始碼的混雜也無法提供給使用者充足的設計概念，且其所作的 SSD 模擬研究以硬體架構為主，FTL 方面僅討論 Page level，研究範圍太過狹隘。

Jongmin Lee 等人提出 SSD simulator 的研究，並命名為 CPS-SIM [12]，其主要探討 SSD 各硬體元件之間的溝通行為與時間，它將會影響 SSD 效能的時間列為 tR、tPROG、tE、tCMD 和 tBUS 五項，並且透過模擬找出平行架構像 Syn-Channel 和 Interleave 下效能的瓶頸。本篇提到的 SSD simulator 跳脫 Disksim 成為獨立開發的模擬工具，但同樣沒有足夠的韌體支援，且只有對單一 FTL 做過討論，因此僅適合作為 SSD 硬體架構的研究用途，並不是完整的模擬工具。

前幾篇研究的議題都關注在以 simulator 所模擬的研究成果，但其實只要有便利的工具，使用者可以更自由並更快速的產生高價值的研究成果。Youngjae Kim 等人提出 FlashSim [13]的研究，並建立一份詳盡的 simulator 架構，它將處理器、FTL、SSD、Channel、Bus、RAM 等韌體和硬體全部以元件的方式表示，元件和元件之間可以觸發不同的行為，基於物件導向的設計可以讓使用者對於 SSD 的模擬更熟悉。FlashSim 提供豐富的硬體模擬資源，但其依然缺乏給予使用者的韌體支援，雖然其預設有四種 FTL 給使用者選擇，但並沒有提出修改或設計的概念，因此使用者難以對 SSD 的韌體設計做出選擇，同時其開發彈性過少，例如使用者無法存取底層讀寫統計資料等的統計資訊，也沒有提供自定變數或函式的窗口等，且其定義的各種元件的分類是否適用於所有組合也無法判定。

(22)

- 12 - 綜觀以上 SSD 的 simulator，大部分單純為學術研究用途而開發，因此並未提供給使用者足夠便捷且完整的開發環境，大部分的 simulator 都強調硬體資源的強度，但複雜的硬體設定對精確度幫助有限，反倒增加韌體設計的負擔，增加使用的困難度，所以模擬工具提供韌體支援是必要的。其次由於設計藍圖難以取得，因此所開發的 simulator 往往沒有討論其模擬準確度，FlashSim 雖然有與真實 SSD 做過比較，但僅限於以 workload 複雜度測試效能的走向，並沒有關於模擬誤差的討論。另外，眾多關於 SSD 的研究都著重在單方面硬體或韌體設計的討論，而忽略不同韌體與不同硬體之間的搭配關係。因此本篇提出 RAPT 工具，首先改善傳統 SSD 模擬韌體支援不足的問題，提出一套便利有效的韌體模型，並建立 Block level、Page level、BAST、FAST 和 N-K 等 FTL 為範本，使用者可以透過韌體模型輕易的修改 SSD 韌體，同時 RAPT 也將各種支援整合成 API 讓所有設計可以更方便進行。其次，本篇透過與實際 SSD 的比對，並歸納各種誤差可能性，以增加使用的有效性。最後利用 RAPT 探討各種韌體與硬體架構的組合，使得 SSD 的研究可以更加具有宏觀性。

(23)

- 13 - 3. DESIGN ISSUE RAPT 的訴求是讓 SSD 的開發能夠更加迅速，因此本篇提出全新的韌體和硬體設計概念，幫助使用者簡化大部分的模擬工作。本章將分別在 3.1 和 3.2 中討論韌體演算法和硬體架構的設計概念，前者將探討如何抽像 FTL 的各種行為，後者說明 RAPT 以何種方法快速建構各種 SSD 硬體架構。

3.1 Abstract Firmware Layer

現存各種 SSD 的模擬器，多著重在硬體模擬的支援，使得 SSD 硬體架構漸漸變成制式化的設計，所有允許的支援都大同小異，卻沒有研究是針對韌體設計來討論，因此 RAPT 特別針對 SSD 韌體的設計提出一套模型。

為了減少使用者開發 SSD 韌體的負擔，並且建立一個簡易修改的韌體架構，簡化設計的行為是必要的，簡化的方式首先要找到各種 FTL 的共通行為，其必要的行為像是 Address Mapping、Garbage Collection 等就變成值得討論的重點，其次，找到這些行為後必須以怎樣的方式呈現才有辦法減少模擬的負擔？從規劃設計的角度而言，最能夠減輕負擔又不喪失彈性的方法就是紀錄資訊，若所要用的資訊能夠以有效率的方式紀錄起來，透過適合的窗口供使用者取用，就可以大大減少設計的麻煩，於是本篇提出紀錄各種 FTL 共通行為中的資料關係（Data Relation）的方法。要紀錄的資料類型很多種，本篇定義元素（Element）、群組（Group）和關聯性（Relation）三者來解釋各種共通的 FTL 行為。Element 表示單一數值的資料，像是索引（Index）、位址（Address）或計數值（Counter）等。而 Group 指的是單一類型的資料集合，成員可以是 Element、Group 或 Relation，其用來表示較大筆的資料。Relation 則用來表示資料與資料之間的關聯性，可以是 Element 和 Element 之間的關聯或 Group 和 Group 之間的關聯等，舉例像索引與資料之間的對應關係或順序性（Priority）等。本篇就以 Element、Group 與 Relation 制定了三種韌體標準模型，分別是 Index、Association 和 Prioritization，依序在本節接下來的小節討論。

3.1.1 Index

由於 Flash-based 的 SSD 具有無法在相同位址重複寫入的特性（Write-Once），必須將要寫入的資料暫時寫到其他 block 或 page，所以 Address Mapping 的行為在任何 FTL 都是必要的，因此本篇定義 Index 為 RAPT 的第一種韌體標準模型，用來表示鍵（Key）與值（Value）的關係，如式 1 所示：

(24)

- 14 -

Definition

R={(k_i,v_j)|k_i∈Key,v_j∈Value} （式 1）其中 Key 是唯一，用來作為索引，Value 則表示對應到的資料，簡而言之，Index 是一對一的關係，如圖 7 所示，以 Key 為索引，每一個 Key 會對應到一個 Value，並且允許重複。

Group Key Group value

Relation = (Element, Element)

圖 7、Index 標準模型關係圖

Index 的應用範圍很廣泛，可以用來紀錄資料的範圍或屬性，但最主要用途還是在 Address Mapping，圖 8 為 Index 的應用範例，其中 LBA 表示邏輯頁位址（Logical Block Address），PPA 表示實體頁位址（Physical Page Address），依此類推。在 BL 中由於 page 寫入每一個 block 的相對位址是固定的，因此只需要紀錄 LBA 對應到 PBA 的關係，同理 PL 中則需要紀錄 LPA 對應到 PPA 的關係，而結合兩者的 Log-based FTL 不僅要紀錄 data block 中 LBA 對應 PBA 的關係也需要紀錄 log block 中 LPA 對應 PPA 的關係，以 Log-based 的圖為例，在 block 位址對應上，LBA 5 和 LBA 0 就是 Index 中的 Key，而 PBA 0 和 PBA 1 則是 Value，而 page 位址的 Key 和 Value 對應關係要記錄的就是 21、0、23、3 和 1 邏輯位址分別對應到 8、9、10、11 和 12 實體位址，因此這類的位址對應關係都可以用 Index 來表示，其在各種 FTL 的使用都是必要的。 35 102 13 44 7 59 14 page 14 0 1 2 3 20 22 23 LBA 5 LBA 0 page 1 21 page 1 page 22 Data block Log block PBA 0 PBA 1 Block Level LBA -> PBA 0 1 2 3 4 5 6 7 Page Level LPA -> PPA 4 5 6 7 0 1 2 3 x x 2 x LBA 0 PBA 1 4 5 6 7 20 22 x LBA 5 x PBA 0 0 1 2 3 ₂₁ 0 23 3 1 8 9 10 11 12 13 14 15 Log-based LBA -> PBA LPA -> PPA PBA 0 PBA 1 PBA 2 PBA 3 圖 8、Index 應用範例

(25)

- 15 -

3.1.2 Association

BL 和 PL 架構簡單，主要考慮 Address Mapping 的關係，因此實作起來比較容易，但 Log-based FTL 包含 block 和 page 的對應搭配，其 Garbage Collection 時候的變化與種類都很繁複，因此除了以 Index 表示，也必須用其他韌體模型刻劃，於是 RAPT 定義 Association 韌體標準模型，用來表示資料集合（Data Set）之間的關係，如式 2： Definition R={(ai,bj)|ai ⊆A,bj ⊆B} _{（式 2）} 其中 A 和 B 是兩個集合，兩者的成員以 a 和 b 表示，a 和 b 在各自的集合中都必須是唯一，其可以是位址、計算值或者其他結構的索引，因此也可以用來表示 Group 或 Relation，歸納而言，Association 表示的是多對多資料的關聯性，如圖 9 所示，它將兩個 Group 關聯在一起，Group 中可以僅有一個 Element，因此也可以表示一對多或多對一的關係。

Group A Group B

Relation = (Group, Group)

圖 9、Association 標準模型關係圖

建立 Association 的目的在於可以更方便的處理 FTL 中 block 與 page 的關係，以 Log-based FTL 為例，request 在寫入時會進入 log block，由於 GC 時要做 data block 與 log block 的 merge 動作，所以要記錄 log block 中的 page 是屬於哪個 data block，這種關聯性在 Log-based FTL 中是必要的，如圖 10，範例中的 Association 模型可以用來表示兩種關聯性，第一種是 log block 內包含的 LPA 資訊，是一對多的關係，像是 PBA 2 與 LBA 21、0、23 和 3 具有的關聯性，兩者可以分別表示 Group A 和 B，第二種是 log block 與其所關聯到的 data block，因為相同 data block 的資料可能存在不同的 log block 內，所以兩者的 PBA 就構成多對多的關係，以圖例而言，PBA 0、1 和 PBA 2、3 就構成 Association 的關聯性，當空間不夠用時，就可以直接找到要 GC 的 Association，將 Group A 和 Group B 中的 PBA 全部 erase。

(26)

- 16 - Data block Log block x x 2 x LBA 0 PBA 1 4 5 6 7 20 22 x LBA 5 x PBA 0 0 1 2 3 ₂₁ 0 23 3 8 9 10 11 Log-based

Log PBA <-> LPA Data PBA <-> Log PBA

PBA 2 1 12 13 14 15 PBA 3 圖 10、Association 應用範例 3.1.3 Prioritization 存在 FTL 的另一項必要行為就是空間配置（Allocation）與回收（Recycle），舉例而言，在 SSD 中每次要寫入資料而舊的 block 沒有空間時，就必須配置一個新的 block 做寫入，但要根據什麼因素來作配置並沒有統一的方法，最久未被使用到的還是磨損次數（即 erase 次數，表示 block 的 Endurance）最少的 block 等，這些配置方法的共通點是都具有優先序關係，像是最久或最少，於是 RAPT 提出 Prioritization 標準模型，用以表示有順序性的資料，如式 3： Definition {( , )|( , ) , } ) , ( 1 1 1 + + + ∈ × < = = i i i i i i p p p P P p p p orderset P ψ ψ （式 3）

其中 P 為一個偏序集合（Partially Ordered Set），ψ 用來表示其成員具有由小至大的順序關係，如圖 11 所示，P 為一個包含很多 Key 的 Group，Key 不能重複，但會依據其優先權關係被排序，透過 Prioritization 標準模型，可以表示所有 FTL 中包含的順序性資料。 Group Key Ordered set 圖 11、Prioritization 標準模型關係圖

圖 12 為 SSD 中 block 配置的示意圖，做 GC 時首先要選擇 erase 哪一個 block，被選中的稱為犧牲者（Victim），這些 victim 的挑選就與優先權有關係，可以挑選最 cold 的資料或回收成本最低的資料，同理在做 Allocation 時也必須從 spare block 中挑選空白的 block（Free block）以供寫入，這些挑選都存在著先後關係，

(27)

- 17 -

因此這些 victim 或 free block 都可以透過 Prioritization 模型建立為順序性的資料。圖中以三種優先權為例，分別是時間、GC 負擔和磨損次數，而所需要排序的 Key 則是 PBA。 PBA 1 PBA 100 PBA 102 Free block Allocate Recycle Victim block PBA 20 PBA 13 PBA 59 TimeStamp -> PBA GC overhead -> PBA Endurance -> PBA GC record 圖 12、Prioritization 應用範例綜合而言，RAPT 提出三種韌體模型，足以抽象 SSD 韌體中 FTL 的各項主要行為，其中 Index 模型用來處理 Address Mapping，Association 模型用以處理 Garbage Collection，而 Prioritization 可以用來表示 Allocation 和 Recycle，透過這些模型可以很快速的將 FTL 制定出來，由於這些模型也代表各種 FTL 的共通行為，所以制定的架構可以適用於多種 FTL，使得不同 FTL 的實現可以透過模型的部分修改就達成，這樣可以更加速 SSD 的韌體開發，此部分可以參考 4.1.1 的實現範例。

3.2 Timing Simulation Framework

硬體架構是 SSD 的設計重點之一，在模擬上通常會制定各種相關的硬體像是 Chip、Bus 等，依據這些硬體的組合便可以模擬不同 SSD 的架構，多數的工具提供十分細節的硬體模擬，但是精細的時間單位與硬體溝通就需要較長的模擬時間，而越複雜的硬體架構也會加深韌體實作的難度，因此 RAPT 簡化部分硬體溝通的機制，並且建立對應的設計介面以避免硬體設計對韌體開發造成負擔。 RAPT 以時間元件取代傳統工具以硬體元件模擬的方法，舉例而言，在 SSD 運作上最花費時間的動作是資料傳輸，於是 RAPT 將模擬分為 Bus 上的傳輸和 Chip 內部的資料搬移時間，分別以 Bus delay 和 Chip busy 兩個時間元件（Timing Component）表示，每個時間元件有各自對應的硬體，像是 Bus delay 可能是屬於 Bus 0 或 Bus 1，透過這些時間元件的組合就可以表示各種不同行為的時間，像是讀取的動作相當於經過一次 Chip busy 和一次 Bus delay，寫入的動作則相反，先會經過 Bus delay 才是 Chip busy。

(28)

- 18 - 成，為了提升模擬效率和準確度，RAPT 基於 System C 的時序概念做設計， SystemC 是一套硬體描述語言，以 C/C++為基礎，具備模組化的概念，包含很多硬體溝通的支援像是通道口（Port）與事件（Event）等，其多執行緒的運作可以模擬各種平行的時間，RAPT 採用其事件傳遞的溝通機制與時間計算函式，並且利用 System C 在模組建立虛擬的時間軸。模擬時 RAPT 允許虛擬時間軸同時存在多個屬於不同硬體的時間元件，於是 RAPT 利用所定義的時間元件與 SystemC 時序系統，就可以模擬不同架構的平行關係，像 2-Channel 的讀取是重疊的 Chip busy 加上 Bus delay，而 2-Interleave 則是重疊的 Chip busy 加上兩次 Bus delay，因此，透過這種概念就可以很輕易的呈

(29)

- 19 -

4. IMPLEMENT

RAPT 可以分為內部介面和外部介面討論，如圖 13 所示，內部介面分為韌體模組（Firmware Module）、硬體模組（Hardware Module）和軟體模組（Software Module），韌體模組負責處理 SSD 韌體的設計，包含 FTL、Buffer 等，依據使用者設計不同而有所變化，硬體模組負責計算不同硬體元件的運行時間，主要維持平行架構的運行，軟體模組負責接收 Trace 中的 request，同時也統計各項測試數據。外部介面則包含使用者介面（User Interface）和三個使用者檔案，使用者介面建立三個模組對應的 API，負責與內部介面的溝通，使用者可以利用那些 API 撰寫 Design 檔，並選用適合的 Trace，最後 RAPT 會將測試結果輸出至 Result。

圖 13、RAPT 系統架構圖

目前 SSD 模擬器的實作方式可歸類為兩種，一種是建立在已存在的模擬工具中，與原來模擬工具的原始碼混雜，因此不僅很多硬體參數無法動態做調整，韌體上要修改也很不容易，另一種則是獨立為一個完整的程式或模組，通常這樣

的做法必須提供一個設計窗口（Design Window），提供使用者包含參數設定、演

算法修改的介面，RAPT 的 Design file 就是一個 Design window，但是一般工具卻缺乏 Interface 幫助使用者存取模擬的資訊，舉例而言若要得到某個 block 的 erase 次數就要看懂大部分的程式碼才有辦法，為了避免這項困擾 RAPT 分別在三個模組中建立 API。本章分為三節，依序討論韌體模組的實現方式、硬體模組的實作與各種架構的實現、軟體模組與使用者介面的支援。 4.1 Firmware Module 韌體模組就是 SSD 的韌體演算法內容，根據不同的需求而有所不同，使用者可以利用所提供的 API 進行設計，API 包含三種韌體模型的對應關係、Flash

(30)

- 20 -

指令讀、寫、抹除等以及資訊查閱的功能，實作時，使用者可以透過 Index、 Association 和 Prioritization 三種韌體模型的 API 快速的將不同的 FTL 以類似的架構制定出來，4.1.1 小節便以 Log-based FTL 為例，討論如何使用 Index、 Association 和 Prioritization 建立一套架構可以適用於 BAST、FAST 和 N-K 三個 FTL，4.1.2 則討論目前的韌體實作方式仍需要做的改善。

4.1.1 Modeling FTL

Index、Association 和 Prioritization 包含不同類型資料對應的關係，RAPT 採用改良式的 Avl-Tree 實作，其不僅可以儲存順序性的資料，還具有節省空間、快速插入與搜尋等優點，因此可以很容易解決所有模型的需求。

BAST、FAST 和 N-K 都是 Log-based 的 FTL，都有區分 data block 和 log block，寫入時資料會進入 log block 中，但三者寫入的位址不一樣，BAST 是一個 data block 對應一個 log block，FAST 是全部的 data block 對應全部的 log block，而 N-K 則是 N 個 data block 對應 K 個 log block，因此 N 個 data block 與 K 個 log block 表示一個 Group，如圖 14 所示，request 會根據邏輯位址所在的 data block 寫到對應的 log block 中，這樣的對應方式根據資料的 locality 不同會產生不同的效能，這部分可以參考 5.3.2 的實驗。

BAST FAST

N-K

圖 14、BAST、FAST 和 N-K 的寫入對應關係

首先，為實現這三者 FTL 必須先紀錄其 Address Mapping 的關係，RAPT 使用 Index 來記錄邏輯位址對應 log block 中 page 的實體位址，同時也記錄 data block 的邏輯位址對應到的實體位址，前者在 request 寫入 log block 的時候作記錄，後者當 GC 時以新的 data block 替換舊的時候需要紀錄，因此，在 Index 的使用上三個 FTL 是相同的。實作上每一個樹節點可以表示一筆對應資料，每次對應需要花費 log N 的時間蒐尋資料，比雜湊（Hash）演算法略慢，但較省空間。

(31)

- 21 -

BAST FAST

N-K

圖 15、BAST、FAST 和 N-K 的 GC 範圍

而 Association 用來表示三個 FTL 不同的 GC 範圍，如圖 15 所示，BAST 每次會 GC 所挑中的 log block 與其對應的 data block，會付出一次 merge 包含兩次 erase，而 FAST 每次 GC 一個 log block 以及與其有關連的 data block，也就是說假設一個 block 包含 64 個 page，則其最多會做 64 次 merge 包含 65 個 erase，因此 FAST 的其中一個缺點就是 GC 時的 response time 過高，至於 N-K 的 GC 範圍與其寫入位址一樣，但只有關聯到的 data block 需要做 merge，因此最少是一次 merge 兩次 erase，而最多是 N 次 merge 加上 N+K 次的 erase。實作時每個 Association 會有一個索引值，用來找到對應的樹節點，每一個樹節點可以關聯到兩個鍊結串列（Linked List），假設為 Group B 和 Group A，分別記錄每次要 GC 的 log block 以及所對應到的 data block，則 GC 時就可以由 Group A 依序挑選 data block 作 merge，等到 data block 都 merge 完再挑選 Group B 中的 log block 作 erase。

Prioritization 用來表示 Allocate 和 Recycle，在 Allocate 時三者都是依據 FIFO 的原則，因此 Priortization 紀錄的 Key 是 block 的實體位址，而優先序關係則為 block 成為 Free block 的時間，因此每次 Allocate 時都會挑選時間最早的。在 Recycle 時三者的優先權都是最後被寫入的時間，表示挑選最久未被更新的位址做回收，而紀錄的 Key 則不相同，BAST 和 FAST 記錄單一 log block 的實體位址，而 N-K 是以一個範圍的 log block 位址為考量，因為挑選中的位址也表示要做 GC 的位址，所以 Prioritization 的用途此處除了 Allocation 也和 Garbage Collection 有關。實作時每一個 Prioritization 就表示一個優先權佇列（Priority Queue），每一筆優先權與 Key 的對應關係就是一個樹節點。

(32)

- 22 - QueryIndex FlashRead FlashWrite FlashErase SetQueueNode ModifyIndex FreeIndex RemoveGroupUnit QueryBlock QueryQueue DeleteQueueNode FlashWrite ModifyIndex AssignGroupUnit QueryQueue DeleteQueueNode QueryGroup Get request Write Free block use up Prioritization Priority -> PBA

Priority = Last write time

BAST

D = Data block i L = Log block i

FAST

D = Association of log block i L = Log block i

N-K

D = Association of log block i ~ i+k L = Log block i ~ i+k

Index

LBA -> PBA

BAST, FAST

Key = Log block i

N-K

Key = Log block i~i+k

Allocate Association D <-> L NO YES GC Recycle Prioritization Priority -> PBA Priority = FIFO Index LPA -> PPA 圖 16、BAST、FAST 和 N-K 的寫入共同架構圖 16 為 BAST、FAST 和 N-K 的共同架構，以寫入為例，一開始由 Host 端 接收到 request，然後透過 QueryBlock 找到要寫入 block 的 page 位址，若寫入的 空間不足則以 QueryQueue 和 DeleteQueueNode 配置一個 Free block，再利用 FlashWrite 做寫入，並使用 ModifyIndex 和 AssignGroupUnit 建立 page 以及 data block 與 log block 的對應關係，完成寫入後依據剩餘的空間判斷是否需要做 GC， 若不需要則繼續接收 request，若需要就透過 QueryQueue 找到 victim，如圖 BAST 和 FAST 是以一個 log block 的 PBA 為 Key，而 N-K 以一個範圍的 PBA 為 Key， 這些實體位址都需要透過 QueryIndex 的查詢，而所挑中的 victim 也表示 GC 範 圍，就是 data block 對應到 log block 的關係，BAST 是一對一，FAST 是一個 log block 與所關聯到的 data block，而 N-K 是最多 K 個 log block 與關聯到的 data block，這些都以 QueryGroup 得知，merge 時使用 FlashRead 和 FlashWrite 做資 料搬移，最後再依序將 data block 和 log block 做 FlashErase，同時再以 SetQueueNode 記錄 Free block 的順序，並用 ModifyIndex 重設 data block 的實體 位址，並且用 FreeIndex 和 RemoveGroupNode 清除不必要 page 和 block 的關係。

透過 RAPT 所制定的韌體 API，可以適應各種不同 FTL 的變化，並且任何程式碼的修改都可以透過這些 API 快速完成，舉例而言，由 FAST 修改為 N-K 只需要更動不到 10 行的程式碼即可完成，因此 RAPT 韌體模組的實作方式提供一種創新的 SSD 模擬方式。

(33)

- 23 -

4.1.2 Deficiencies of the Current Firmware Module

RAPT 的韌體模組可以用來設計任何 FTL，但在使用上仍然有很多無法簡化的動作，以圖 17 為例，KAST [14]是近年提出的 FTL，與 N-K 一樣是多個 data block 與多個 log block 組成一個 Group，不同點在於 N-K 的 Group 有連續性，例如 LBA 0~3 是 Group 0 而 LBA 4~7 是 Group 1，依此類推，而 KAST 每一個 Group 的 data block 的 LBA 是不連續的，這樣的好處是關聯性的利用度較高、存取的彈性較大。但在 RAPT 的實作上 N-K 可以直接以數學方法得到 Group 的索引，再利用過索引查詢 data block 對應到 log block 的 Association 關係，但 KAST 沒有固定的運算法則，因此實作上就必須先以 Index 記錄每個 data block 對應到的 Group，才能找到對應的 Association，實現過程也就多一道手續。 Index Association LBA0 LBA1 LBA2 LBA3 LBA0 LBA1 LBA2 LBA3 Group 1 Group 0 Group 1 Group 0 N-K KAST Association

Key = LBA / 2 Key = Index of LBA

圖 17、N-K 與 KAST 的 Association 模型使用示意圖

雖然任何 FTL 都脫離不了 RAPT 所提出的資料對應關係，但很多關係是複雜的，以 RAPT 所提出的 API 仍無法有效簡化它們，除了上述的 KAST，還有採用樹結構（Tree）實作的 FTL [15]等都必須透過多重對應的關係才能建構，因此，不僅已存在的 API 還有細分的空間，也有更多的設計議題是值得討論的。

(34)

- 24 - 4.2 Hardware Module 一個完整的 SSD 模擬工具最重要的就是硬體架構的支援，RAPT 的硬體模組基於 SystemC 時序系統完成，結合 3.2 所定義的時間和硬體元件便可以很容易的模擬出各種不同的 SSD 架構，並且也將各種架構的設定以簡易 API 表示，使用者可以透過調整 API 的參數很容易達成模擬不同 SSD 架構的目的。4.2.1 說明硬體模組的實作方式，4.2.2 和 4.2.3 分別呈現 Inter-chip 和 Intra-chip 架構在實作上的細節，最後一小節則分析目前硬體模組的缺失。 4.2.1 Modeling Architecture

圖 18 是硬體模組的架構，當使用者使用 RAPT 的韌體 API 如 FlashRead、 FlashWrite 等指令後， request 便會切割成對應的時間元件進入到指令佇列 （Operation Queue），等到韌體模組的動作結束後便會進入到硬體模組中運行各個時間元件，每一個時間元件都有歸屬的硬體，硬體模組會將所有 Operation queue 中對應到準備完成（Ready）硬體的時間元件都放到時序系統中，同時更改該硬體狀態為忙碌（Busy），當某個時間元件運行結束後其對應的硬體就會被釋放回 ready 的狀態，此時其他要用到此硬體的時間元件才可以存取它，透過這樣的實作方式就可以模擬時間的平行關係與硬體之間的相依關係。 Operation queue HW ready pool HW Busy pool Combine Timing engine (System C) Operation Firmware API Timing

Component _ComponentHardware

圖 18、RAPT 硬體模組架構圖

以圖 19 為例，假設要模擬 2-Gang 4-Channel 2-Interleave 架構的 SSD，可以 直接採用 RAPT 所提供的 API 來完成，SetupArchitecture 就是用來設定 SSD 的 Inter-chip 架構，所有的模擬必須先經過這些硬體參數的設定後才能進行，上述的架構經過設定後便會在模組中建立對應的硬體，包含兩條兩倍寬的 Bus 和四組兩個同時運作的 Chip。而假設要制定 Flash chip 的規格，像是 2-Plane、MLC 或 SLC 等參數，也可以很快速的透過 SetupFlashChip 來完成。此外，由於時序系統 的運行必須花費比較長的模擬時間，因此 RAPT 也提供 DisableHardwareModule 的指令讓不需要模擬時間只要計算次數等統計資料的使用者可以關閉 RAPT 的硬體模組，藉此加速模擬速度。

(35)

- 25 - SetupArchitecture SetupFlashChip Chip Chip Chip Chip Channel0 Channel1 Gang0 Chip Chip Chip Chip Channel2 Channel3 Gang1 2xBus 0 2xBus 1 2xChip 0 2xChip 1 2xChip 2 2xChip 3 Operation queue Hardware component

Virtual architecture Real architecture

圖 19、硬體模組模擬示意圖

RAPT 的硬體模組不僅提供豐富的資源，也建立簡易的 API 讓使用者在模擬設定上非常方便，同時透過 SystemC 時序系統的輔助，RAPT 在平行時間的模擬效能也表現不俗，接下來將就各種 RAPT 所提供的架構支援做探討。

4.2.2 Inter-chip Architecture

Inter-chip 分為 Syn-Channel 和 Ind-Channel 兩種，兩者都是 Multi-Channel 的架構，以 RAPT 所定義的時間元件很容易描述其平行關係，如圖 20 所示，模擬時相當於同時存取不同 Chip 與不同 Bus，因此在 Bus delay 與 Chip busy 的時間都可以平行，不同點在於 Syn-Channel 中每個 Channel 必須同時運作且存取相同的位址，而 Ind-Channel 的每一個 Channel 可以獨立存取，所以 Syn-Channel 又可以稱為 1-Gang Multi-Channel，而 Ind-Channel 則稱為 Multi-Gang。Syn-Channel 的缺點在於較容易造成空間利用度不足，因為小或隨機 request 的寫入無法同時利用到所有 Channel，同時運作的方式就使得沒有資料要寫入的 Channel 的位址空間浪費掉，相對而言，Ind-Channel 架構對不同 Channel 存取的利用度較高，但由於每個 Channel 要記錄的位址資訊不同，因此消耗的 RAM 較大，且為了使各個 Channel 的存取時間較平衡，其韌體演算法的實作考慮也會比較複雜。 Chip 0 Chip 1 Bus 0 Bus 1 Chip 0 Bus 0 Chip 1 Bus 1 Channel 0 Channel 1 Channel 0 Channel 1 Read Write 圖 20、Channel 運作示意圖

Interleave 又稱為 Shared-Bus，因為其存取的不同 Chip 的 Bus 共用，因此 Bus delay 無法重疊，運作示意如圖 21，寫入與讀取都會有 Chip 等待的時間，因此 Flash chip 的選擇與 Bus 的傳輸速度對 Interleave 的影響較大，像是 MLC 會比 SLC 佔便宜，因為其 Chip busy 的時間較長，相對而言平行賺到的時間較多，而 Bus 傳輸越快，圖中的等待時間就越短，其平行度就越高，也越接近 Multi-Channel。

(36)

- 26 -

Iterleave 的韌體實作方法與 Ind-Channel 類似，因為其不同 Chip 的運作也可以視為獨立，因此如何使各個 Chip 的存取平衡也值得討論。 Chip 0 Chip 1 Bus 0 Bus 0 Chip 0 Chip 1 Read wait Chip 0 Bus 0 Chip 1 Bus 0 Chip 0 Chip 1 Write wait 圖 21、Interleave 運作示意圖 4.2.3 Intra-chip Operation

Intra-chip 是透過 Chip 內部 register 加速 Chip 運行的指令，通常有 Multi-Plane 和 Copy-Back 兩種。圖 22a 是一般的資料搬移方法，等同於一次讀取加上一次寫入，而圖 22b 是 Chip 內建的 Copy-Back 指令，其透過內部的 register 協助搬移資料，不需要經過 Bus，因此一次 Copy-Back 就等於先讀後寫的兩個 Chip busy 時間元件。Copy-Back 有效增加 SSD 效能，但其缺點是不經過 Bus 的資料無法經由 Contoller 加上 ECC 等除錯機制，因此大大的增加資料遺失或錯亂的風險。

Chip Bus Bus Chip

Read + Write a、讀取後寫入 Chip Chip Copy-Back b、Copy-Back 指令圖 22、資料搬移運作示意圖

Plane 是 Chip 內的單位，每一個 Plane 有自己的 register，因此資料的讀寫和抹除在相同 Chip 的不同 Plane 可以同時運行，但是因為一個 Chip 僅會有一條 Bus，所以不同 Plane 的 Bus delay 無法重疊，如圖 23，Multi-Plane 的平行度類似 Interleave，不同點在於其 Plane 的運作時間要同時，所以已經準備好的 Plane 必須等待另一個 Plane 的資料傳入 register 才一起運作，RAPT 在實作上為每一個 Plane 建立虛擬暫存器（Virtual Register），使用者可以單獨存取某一個 Plane，但此時未被存取的 vitual register 會進入等待，直到所有 Plane 的 virtual register 都被存取後才會執行這個 Chip 不同 Plane 的提交動作（Commit），經 commit 後的 Chip 才算完整執行過 Multi-Plane 指令，這樣的設計可以讓使用者在使用上更有彈性。 Multi-Plane 的缺點是共用 CE，所以不同 Plane 同時存取的位址也必須一樣，這個限制使得 Multi-Plane 無法成為提升效能的關鍵。 Plane 0 Plane 1 Bus 0 Bus 0 Plane 0 Plane 1 Read wait Plane 0 Bus 0 Plane 1 Bus 0 Plane 0 Plane 1 Write wait wait 圖 23、Plane 運作示意圖

(37)

- 27 -

4.2.4 Deficiencies of the current Hardware Module

本篇所定的各種硬體架構與指令足以模擬現存大部分的 SSD，但是仍然無法滿足推陳出新的 SSD 設計，例如目前 RAPT 的硬體模組是以單一種類 Chip 的設計為主要考量，但有些研究提出與硬碟混合的架構[16]，或者以 NAND Flash SLC 作為快取（Cache）而 MLC 作為儲存空間的概念[17][18]，還有為了適應不同作業系統高頻率存取的 Hot-data 而經過特殊處理的硬體架構等，像是圖 24 所舉例的一個 Gang 中包含不同的 Channel 數量或一個 Channel 中包含不同 Chip 數量，這類的設計目前並不常見且韌體的演算法會相對複雜，所以本篇仍然以對稱性的硬體架構為主題。 Chip Chip Channel0 Gang0 Chip Chip Chip Chip Channel1 Channel2 Gang1

a、不同 Channel 數量的 Gang

Chip Chip Chip Channel0 Channel1 Gang0 b、不同 Chip 數量的 Channel 圖 24、非對稱性 SSD 架構

(38)

- 28 -

4.3 Software Module and User Interface

為了增加使用者輸入與輸出的方便性，RAPT 規劃軟體模組特別處理這部分，如圖 25，其包含行為描述檔處理器（Trace Player）和模擬結果產生器（Result Generator）兩個小模組，而 Trace player 中又分為 Request Loader 和 Request Queue 兩個部分，RAPT 使用讀寫系統行為描述檔（Trace）的方式做模擬，使用者可以採用任何格式的 Trace 或不同的 workload，並自行修改讀檔方式，然後透過 BufferRequest 這個 API 將 request 放到 Request Queue 中，再執行 ProcessRequest 平行處理那些 request，藉此模擬 Buffer 的功能。同時也可以在 Result generator 中自定要輸出的統計資訊，或者採用 RAPT 提供的預設輸出 API ，執行 DefaultOutput 後 RAPT 會將回應時間（Response Time）、效能（包含 Thoughput 和 IOPS）以及每一個 Chip 的讀寫與抹除次數等資訊輸出到一個預設的輸出檔。 Result generator Firmware Module Hardware Module Trace file Result file Request queue Request loader Trace player 圖 25、RAPT 軟體模組架構圖開放式的模擬工具都會提供一個窗口給予使用者設定模擬對象的行為，但是大部分的工具卻沒有提供和底層溝通的介面，表示使用者要修改或取得模擬的內容就必須看懂全部的程式碼，為了解決這個問題 RAPT 建立一套完整的介面，採用物件導向的 C++撰寫而成，如圖 26 所示，分為開發函式（Design API）和開發平台（Design Area）兩個部分，補述如下。 CreateIndex ModifyIndex FreeIndex CreateAssociation AssignGroupUnit RemoveGroupUnit CreatePrioritization SetQueueNode DeleteQueueNode FlashRead FlashWrite FlashErase PlaneRead PlaneWrite PlaneErase CopyBack QueryBlock QueryGroup QueryIndex QueryQueue SetupArchitecture SetupFlashChip DisableHardwareModule BufferRequest ProcessRequest DefaultOutput

Firmware API Hardware API

Software API RAPT.h Trace Player Result Generator FTL Init Design Area 圖 26、RAPT 使用者開發介面

(39)

- 29 -

開發函式即為韌體、硬體和軟體模組的 API，韌體 API 可以分為指令（Command）、抽象模組（Abstract Model）和資料查詢三個部分，指令像是 FlashRead、FlashWrite、FlashErase、Multi-Plane 和 Copy-Back 等，而抽象模組則是 3.1 所述的 Index、Association 和 Prioritization，資料查詢的 API 提供使用者獲取由 RAPT 所記錄的一切資訊。硬體 API 主要用來設定 SSD 的硬體架構，包含架構參數和 Flash chip 的規格等。軟體模組則包含暫存和處理 request 的 API 以及輸出預設統計資料的 API，透過這些介面使用者可以在開發與設計上可以更加清楚且方便。

開發平台就是使用者的設計檔案 Design file，內容包含使用者自定的韌體演算法和硬體架構，其分為四個設計主要設計區塊，分別是 Trace Player、Init、FTL 和 Result Generator，Trace Player 和 Result Generator 提供軟體 API 供給使用者規劃輸入 Trace 和模擬輸出資訊，其中 Buffer 的實作也包含在 Trace Player 中，而 Init 提供韌體和硬體 API，主要是作為使用者初始化硬體架構和韌體演算法的區域，而 FTL 中提供給使用者韌體 API，是主要設計 SSD 韌體演算法的地方。

這些分散的模組資源被統一規劃到使用者介面中，所有開發函式和開發平台皆建立為 RAPT.h 函式庫檔中，因此使用者可以很方便的引用，達到 RAPT 快速與容易開發的目的。

基於固態硬碟的韌體演算法與硬體架構快速標準制訂工具

國立交通大學

資訊科學與工程研究所

碩 士 論 文

基於固態硬碟的韌體演算法與硬體架構快速標

準制訂工具

A Rapid Algorithm/Architecture Prototyping Tool for

Solid-State Drive

研 究 生：郭晉廷

指導教授：張立平 教授

基於固態硬碟的韌體演算法與硬體架構快速標準制訂工具

A Rapid Algorithm/Architecture Prototyping Tool for Solid-State Drive

研 究 生：郭晉廷 Student：Ching-Ting Kuo

指導教授：張立平 Advisor：Li-Pin Chang

國 立 交 通 大 學

資 訊 科 學 與 工 程 研 究 所

碩 士 論 文

基於固態硬碟的韌體演算法與硬體架構快速標準制訂工具

學生：郭晉廷

指導教授：張立平

國立交通大學資訊科學與工程研究所

摘要

A Rapid Algorithm/Architecture Prototyping Tool for Solid-State

Drive

Student：Ching-Ting Kuo

Advisor：Dr. Li-Pin Chang

Department of Computer and Information Science

National Chiao Tung University

Abstract

誌謝

目錄

圖目錄

表目錄

X

X

X

X

碩士論文

研究生：郭晉廷

指導教授：張立平教授

研究生：郭晉廷 Student：Ching-Ting Kuo

國立交通大學

資訊科學與工程研究所

碩士論文