我在 SiFive 處理器架構部門四年的經歷

最近在 LinkedIn 讀到了 Jonathan Combs （Intel Atom 架構師）為嚮往處理器架構師的學生所撰寫的文章，一開頭就是讓我覺得很有意思的話：

Very few folks "start" in architecture. For most, it's an earned position. If you get lucky coming straight out of school as an MS or PhD, it's usually due to being within a very specific computer architecture centered research group/program at select universities. If you have to ask if your university is one of those select few, then the answer is "probably not".

字面上看來，處理器架構部門是非常難進去的，除非你在學生時期便在傳統計算機架構名校做過研究（UT Austin, UMich, UIUC, UC Berkley, Cambridge, etc）據我所知，很多在台灣的架構師跟老師都是從 UMich 回來的。文章的下一段便解釋其困難之處：

With the Atom (E-core) team, our performance architects spend most their time in the C/C++ timing model and rely on both their excellent programming skills (lots of CS classes are a must) and their understanding of modern cpu microarchitecture. We additionally have unit/cluster level microarchitects within our architecture team who spend their time thinking in boolean/Verilog and working mainly with the design team. Every one of our microarchitects earned their position as essentially being world class designers who showed acumen for solving large scale microarchitectural problems in the RTL. They were technical leads in their design teams with a penchant for understanding performance and capable of moving to our architecture team to drive the microarchitectural evolution of the CPU.

除了本身的程式設計的能力要優秀外，對處理器的微架構必須非常清楚，教科書上的知識僅僅是門檻。而當代微架構的知識是需要長時間去累積的，試想一顆處理器的設計累積多少人的心血，更別說經歷了多少個世代。短時間拾起這些知識的能力需得要多年的經驗，更別說為下一代處理器架構提供建議。Jonathan 給這些學生具體的建議如下：

If you're hoping to be in one of these positions someday, I suggest you first work your way anywhere into a world class CPU design\validation team. Every place is a great place to start! There are often paths through validation into performance, design into performance, validation into design, as well as paths from design to microarchitecture. Plus there's a ton of microarchitecture that happens within the design organization itself and not micro-managed by "architects". The ideal front-end RTL design team is filled with expert microarchitects.

從一個接近你的領域的職缺開始了解處理器微架構的。例如：電機系的學生可以從 Designer 開始，資工系的學生可以從 Performance Validation 或 Design Verification 開始。這些都是很好的地方開始累積對微架構的知識。

我很幸運地在研究所時期，指導老師讓我去為 RISC-V Vector Extension 開發指令集模擬器及設計處理器架構，並為其開發效能模型。也因為這個經歷，讓我錄取了 SiFive 的處理器架構部門，得以一窺產業界是如何做事的。以下是我在 SiFive 四年的經歷，希望能讓更多人多了解處理器架構部門。

處理器效能建模

針對 SiFive High Performance Out-of-Order Core Architecture 進行效能建模。舉凡任何 BTB, RAS, TAGE Predictor, Register Renaming, Out-of-Order Issue, Load Speculation, Hardware Prefetcher, Load/Store Queue, Multiple Memory Outstanding, etc 任何處理器該有的單元都是進行建模的對象。

有時設計部門想實驗一個新想法改善效能，架構部門便快速進行建模分析效能的優劣。有時架構部門這邊開發了一個新的演算法，便請設計部門評估實作上的可行性。有時一個硬體單元的面積太大或是太耗電了，我們也會提供若移除或縮小該硬體單元對效能上的影響。

下一代處理器規格制定

當大大小小的想法累積起來後，各個部門必須一起討論哪一些想法可以做在這一代，而哪些想法必須延到下一代。我印象深刻的是，設計部門曾用 Floor Plan 解釋給我聽為什麼某根訊號的延遲會拉得那麼長。集合各方想法及硬體限制後，效能模型便能告訴我們這一代處理器架構效能會落在哪裡、而下一代又在哪裡。

反其道而行也是可以的，若產品部門覺得兩個不同的產品中間的落差太大（可能是效能、面積或是功耗），需要不同的產品補位。效能模型這時候也會派上用場去找出對應的處理器規格。

處理器效能驗證

有了效能模型後，不只可以拿來做以上的事情，也可以拿來驗證開發中的硬體的效能是否符合預期。有可能是效能建模太過樂觀，也有可能是硬體太過悲觀。架構部門必須確定效能模型足夠逼真，也必須即時驗證硬體效能。

為了達成以上的事情，架構部門必須設計大大小小的測試。而這些測試都是必須針對某個微架構進行撰寫的，否則便達成不到驗證的目的。這些測試的環境可以是 Bare Metal，也可以是 Linux；進行測試的平台可以是 RTL 模擬器、指令集模擬器、效能模型、 FPGA或甚至是已經 Tapeout 的晶片。架構部門的工程師必須對計算機系統有一定的了解，才能順利地進行上述的工作。

軟硬體共同最佳化效能

架構部門會收到來自軟體部門及編譯器部門的問題。像是這段軟體工程師寫的程式碼為什麼效能不好、又或者是為什麼加了一個編譯器最佳化結果效能沒有變好。過程中架構部門必須基於本身對指令集及微架構的了解給予硬體上的建議。必要時，可能需要產生波形圖或是利用效能模型進行深入的調查，說不定又因此找到一個硬體缺陷。

RISC-V 指令集模擬器開發

我一直很喜歡我們部門 “Eating your own dog food” 的精神。架構部門的 RISC-V 指令集模擬器是獨自一手開發的，不僅可以執行 System Call Emulation，也可以開機 Linux。模組化的設計讓我們的指令集模擬器可以協助分析軟體、硬體驗證及支援 Execution-driven 效能模型。

效能追蹤及分析軟體開發

肇於效能變動的成因實在是太多元了，例如像是：硬體變動、軟體變動、編譯器變動及效能模型變動。架構部門因此會建立自動化的工具去追蹤這些事情，架構部門也必須憑藉自身對硬體及軟體的認識，才能及時分辨出造成效能變動的主因，攔阻壞事發生。

架構部門亦還需開發各式軟體去協助效能分析，大致可以分為兩類：如何加速軟體模擬過程（如何在 RTL 模擬器上跑大型軟體像是 SPEC 或是 Geekbench）、如何分析效能瓶頸（如何知道效能瓶頸在處理器的哪一個單元）。

Jonathan 文末的一句話讓我感觸良多，因為上述四年經歷的確能讓我放心說出：SiFive 就是一個可以讓你起步處理器架構師生涯的好地方 :)

Find a humble place to start and then grow from there. The journey is more important than the destination.