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 架構

- 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 的讀寫與抹除次數等資訊輸出到一個預設的輸出檔。 發平台（Design Area）兩個部分，補述如下。

CreateIndex ModifyIndex FreeIndex CreateAssociation AssignGroupUnit RemoveGroupUnit CreatePrioritization SetQueueNode DeleteQueueNode FlashRead

SetupArchitecture SetupFlashChip DisableHardwareModule

BufferRequest ProcessRequest DefaultOutput

Firmware API Hardware API

Software API

- 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 快速 與容易開發的目的。

- 30 - 5. EXPERIMENT

本章首先在 5.1 提出各項會影響模擬的指標參數，並呈現 RAPT 與真實硬體 的比較，接著再以 RAPT 平台開發各種不同的 SSD 韌體演算法與硬體架構，5.2 將說明各種實驗環境的設定，5.3 到 5.6 再分為四個部分依序討論各種 SSD 研究，

第一部分討論各種 FTL 的設計，第二部分討論各種硬體架構的變化和瓶頸，第 三部分再探討硬體架構實作需要關注的韌體設計議題，最後一部分結合各種韌體 演算法與硬體架構的設計組合作探討。

5.1 Simulation Validation

由於實際硬體的時間不確定因素太多，且必須在對韌體與硬體完全了解的情 況下才有辦法做模擬，因此目前仍然沒有關於 SSD 模擬正確性的討論，本節首 先針對各種可能的模擬影響參數做討論，再呈現 RAPT 與實際 SSD 的比較結果。

5.1.1 Timing Spec Analysis

圖 27 為 SSD 的硬體溝通示意圖，其溝通分為指令和資料的傳輸，其中資料 的傳輸是影響 SSD 效能的主要因素，因此在模擬上 RAPT 主要針對這點做考量，

至於其他未考慮的時間參數，就為模擬的誤差值，底下就 RAPT 模擬可能的誤差 做分析。

Host Buffer Register Memory Mapping

Info. Control DMA RAM Controller

Flash chip SSD

圖 27、SSD 硬體溝通示意圖

SSD 的內部溝通行為包含 Controller 指令、 RAM 的存取、DMA 的資料搬 移延遲、Buffer 和 Flash 暫存器的資料傳輸以及暫存器與 Flash memory 的資料傳 輸等，分列如表 2，打勾者表示 RAPT 有加入的模擬參數，其餘未加入模擬的參 數總影響力僅佔不到每一次讀寫時間的 1%，以 DRAM 為例，其多用於 mapping 資訊的存取，因此每次讀寫的存取不超過 2 Byte，所以至多也只需要花費 120 ns 的時間，對整體的模擬不會有很大的影響。其中 Flash bus delay 的時間瓶頸可能

- 31 -

為 Host 介面、DMA 傳輸速率、Bus 頻寬或 Flash 暫存器，Host 介面的影響像是 SATA 或 USB 等，而 DMA 速率則依處理器不同有所不同，Bus 的寬度一般為 Byte 或 Word，前幾者的傳輸速度都較快，因此本篇的模擬還是以 Flash 暫存器 的延遲作為瓶頸考量。

大部分的模擬工具都著重在細節的時間參數，但通常那些參數對結果影響不 大，且為了考慮過小的時間單位，容易造成模擬的速度下降，因此 RAPT 目前僅 針對時間影響大於 1 us 的參數做討論，其餘時間參數對 RAPT 的總影響僅在正 負 1%。

表 2、時間影響參數對照表

Simulated behavior Time delay DRAM access delay per cycle (tRC) 60 ns SRAM access delay per cycle (tRC) 10 ns Controller CMD latch (tCS+tCH) 25 ns Controller address latch ((tALS+tALH)x5) 85 ns ˇ Flash bus delay = R/W cycle (tRC, tWC) 25 ns ˇ Flash read busy (tR) 60 us ˇ Flash write busy (tPROG) 800 us ˇ Flash erase busy (tBERS) 1500 us

Flash multi-plane write busy (tDBSY) 500 ns Flash spare area read busy (tAR+tREA) 30 ns

5.1.2 Verification

為了驗證本篇所提出 RAPT 的正確性與可用性，本小節根據台灣 SSD 開發 廠商提供的韌體演算法和硬體架構與其真實產品做比較。首先針對單一 Chip 的 韌體演算法比較，採用的美光科技（Micron）的 NAND Flash，規格為 MLC，FTL 則採用加入 pending 機制的 Block Level，為了觀察驗證的細節，使用 HD tune [26]

工具記錄每一筆 request 的回傳資訊，藉此針對細部的回應時間做比較，比較結 果就讀取和寫入兩種行為討論，又分為 64KB 大資料和 4KB 以下小資料的存取。

圖 28 為讀取行為的驗證結果，其中大檔案存取的不規律跳動曲線是讀取行 為跨越 block 時會去重新載入 RAM 中的 mapping 資訊的原因，此項已加入模擬 考量，圖中虛線部分表示模擬行為，實線部分為實際 SSD 行為，可見讀取的趨 勢兩者大致相同，但模擬時間約略少實際時間 1 ms，這段誤差來源主要是 Flash bus delay 的傳輸，如同 5.1.1 所述，其影響因素很多，因此要確認讀寫的瓶頸往 往需要煩雜的交叉比對驗證，暫時不在本篇的討論範圍內。

- 32 - 0

5 10

Response (ms)

Large read Sequence s

Small read Sequence

sim 同，其中因為模擬過程沒有根據資料搬移成本考量是要做 pending 或者做 merge，

與實作方式略有不同所以造成部分曲線不雷同。綜合而言，讀取行為的模擬時間

Large write Sequence simsrc

Small write Sequence sim

src

b、小檔案存取（4KB）

圖 29、韌體演算法寫入驗證

除了針對單一 Chip 的 FTL 驗證，本節也驗證在不同硬體架構下 RAPT 的表 現是否符合預期，其採用的 FTL 以 KAST 為基礎做變化，Over provisioning 將近 15%，使用 MLC 的 Flash chip，並且採用本篇所提及的平行演算法。表 3 就兩種 不同的架構測試，使用 IOmeter 純隨機的 workload 寫入，Time 表示測試的時間 長短，分為 3 分鐘和 30 分鐘的測試，結果以 IOPS 呈現，其中前 3 分鐘大部分 的資料被 spare block 吸收掉，因此效能會表現得較好，如表所示，在僅有 2-Plane 的架構下模擬與實際差異不大，誤差約 5%，但當架構變複雜以後誤差就上升到 15%，因為高平行架構的模擬需要考慮韌體與硬體實作的細節，而少部分細部資 訊是本篇無法從廠商取得的。

- 33 -

表 3、硬體架構寫入驗證

Time Source IOPS Simulation IOPS 1-Channel 1-Interleave 2-Plane 30 min 250 262 4-Channel 4-Interleave 2-Plane 3 min 1039 894 4-Channel 4-Interleave 2-Plane 30 min 474 554

本節的測試包含很多影響因素，像是未知的韌體錯誤、ECC 造成的重新讀 寫時間、RAM 的存取以及未知的硬體溝通時間等，所以數據的誤差仍然存在，

但也可以由驗證中得知，所有模擬結果與實際差異的趨勢相同且符合預期，所以 RAPT 對於 SSD 的測試與設計是有效的，未來將與本計畫開發的真實 SSD 做比 較，可以得到更完整且正確的驗證資訊。

- 34 - 5.2 Environment

本篇除了討論 SSD 設計的概念並開發一套快速模擬工具，也針對 SSD 韌體 演算法和硬體架構作一連串的探討，有關 SSD 的討論已持續好幾年，近年的研 究不管是 FTL 還是硬體架構的同質性都越來越高，因此本篇一方面歸納整理以 往的方法，一方面根據這些方法結論表現最好的韌體與硬體組合，也希望透過這 些研究給予 SSD 的設計更多啟發，同時從這一章也可以驗證 RAPT 的功能性與 準確度。

實驗部分採用之各項參數如表 4，Flash chip 規格取自 Samsung NAND K9XXG08UXA 和 K9XXG08UXM，分別代表 SLC 與 MLC，傳輸速度方面假設 DMA 與 Bus 的延遲很短，因此瓶頸為 Flash chip 內部 register 的讀寫（換算後約 40 MB/s），另外，所有 Log-based 的 FTL 在沒有特別說明的情況下一律以 workload 大小的 5 %作為閒置空間也就是 spare size。未計的時間參數的部分包含 RAM 以 及 page spare area 的存取，還有處理器下指令（Command）的延遲，由於這些時 間十分微小，平均每一個 request 影響不到 1μs，所以忽略與否並不會干涉結果。

表 4、實驗參數設定

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

Data transfer delay 25 ns/byte Spare block area 5 %

SSD 一般用於高效能要求的系統，本篇假設實驗對象的 SSD 為個人用儲存 系統和伺服器儲存系統，個人用的儲存系統像是筆記型電腦或 PDA 等，因為個 人使用習慣大多不一致，因此可能的存取行為較混雜，包含較多的高頻率存取資 料（Hot Data）和眾多的隨機（Random）與循序（Sequential）資料，本篇以使

SSD 一般用於高效能要求的系統，本篇假設實驗對象的 SSD 為個人用儲存 系統和伺服器儲存系統，個人用的儲存系統像是筆記型電腦或 PDA 等，因為個 人使用習慣大多不一致，因此可能的存取行為較混雜，包含較多的高頻率存取資 料（Hot Data）和眾多的隨機（Random）與循序（Sequential）資料，本篇以使