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。

而要進行平行時間的模擬則必須透過一套時序系統（Timing engine）來完

- 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，因此，透過這種概念就可以很輕易的呈 現各種 SSD 的硬體架構（更多實現方式可以參考 4.2）。

- 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

- 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）演算法略慢，但較省空間。

- 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 的對應關係就是一個樹節點。

- 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

Association D <-> L NO

YES

GC Recycle

Prioritization Priority -> PBA 接收到 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 模擬方式。

- 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 還有細分的空間，也有更多的設計議題是值得討論的。

- 24 - 4.2 Hardware Module

一個完整的 SSD 模擬工具最重要的就是硬體架構的支援，RAPT 的硬體模 組基於 SystemC 時序系統完成，結合 3.2 所定義的時間和硬體元件便可以很容易 的模擬出各種不同的 SSD 架構，並且也將各種架構的設定以簡易 API 表示，使

一個完整的 SSD 模擬工具最重要的就是硬體架構的支援，RAPT 的硬體模 組基於 SystemC 時序系統完成，結合 3.2 所定義的時間和硬體元件便可以很容易 的模擬出各種不同的 SSD 架構，並且也將各種架構的設定以簡易 API 表示，使