Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ハイパフォーマンスCPUの作り方_アーカイブ用.pdf
Search
msyksphinz
April 13, 2025
66
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ハイパフォーマンスCPUの作り方_アーカイブ用.pdf
msyksphinz
April 13, 2025
More Decks by msyksphinz
See All by msyksphinz
オープンソースでどこまでできる?フォーマル検証チャレンジ
msyksphinz
0
390
LiteXとオレオレCPUで作る自作SoC奮闘記
msyksphinz
0
1.9k
作って学ぶ コンピュータアーキテクチャ 出版にあたっての経験談
msyksphinz
1
1.8k
次世代を担うオープン命令セットアーキテクチャRISC-Vの最新動向
msyksphinz
3
5.6k
Rustで作るフルスクラッチQEMU型エミュレータ
msyksphinz
8
4.9k
ハードウェア記述言語Chiselを もっと活用するためのDiplomacy概説
msyksphinz
1
1.9k
ますます注目される オープンCPUアーキテクチャ RISC-Vの最新動向
msyksphinz
2
2.9k
オープンソースCPUアーキテクチャ 「RISC-V」を中心に変わる半導体の世界
msyksphinz
1
2.7k
ますます注目されるオープンCPUアーキテクチャRISC-Vの最新動向
msyksphinz
0
4.7k
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
135
9.9k
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
1
3.6k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.7k
Embracing the Ebb and Flow
colly
88
5.1k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.1k
Are puppies a ranking factor?
jonoalderson
1
3.5k
Why Your Marketing Sucks and What You Can Do About It - Sophie Logan
marketingsoph
0
160
Principles of Awesome APIs and How to Build Them.
keavy
128
17k
Optimising Largest Contentful Paint
csswizardry
37
3.7k
New Earth Scene 8
popppiees
3
2.3k
Fashionably flexible responsive web design (full day workshop)
malarkey
408
66k
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
380
Transcript
ハイパフォーマンスCPUの 作り方 Masayuki @ FPGA開発日記 (@masayukik.bsky.social) 2025/04/12第5回 自作CPUを語る会 1
本日の発表について • CPU作りが趣味の皆さんと楽しみを共有したい • 自分はプロダクト・レベルのCPU設計に関わることができた • CPU設計の現場で、何が行われているのか共有したい • 皆さんのCPU開発がさらに素晴らしいものになるように! 2
注意 • 本発表内容は、特定の半導体企業の開発フローを説明しているものではあり ません。 • 発表者は複数の企業で半導体設計を経験しています。 • 今回の発表では、これらを非常に抽象化させています。 • 非常に一般的と思われる内容にとどめます。
• 本発表内容 + 発表者の経歴から、特定の半導体企業の開発フローを推定しよ うとするのは、かなり無理があると思うのでやめてください。 3
半導体の開発からテープアウトまで • ASICの開発はやることが多い • 全体のフローは数年に及ぶことも • CPUの場合、IPとして他社に販売することも • テープアウトとはまた違う大変さ •
筆者の範疇 • マイクロアーキテクチャ • RTL設計 • 論理合成 ネット リスト マスク パタン (GDS) チップ 発表者の守備範囲 4
チップ内のCPUの立ち位置 • CPUだけでは何にもできない → SoC (System on a Chip) として構成
• チップの外部と通信するための回路や、モジュール感を通信するためのバスなど • CPUはSoC内の一部品 • CPU設計チームはCPUを「一部品」として SoCチームにリリースする • デザインそのもの • ドキュメント • などなど… • CPU自体をIPとして売り物にするときの 階層にもなる CPU0 CPU1 L2 Cache UART SPI DDR Controller Flash Controller Accelerator1 Accelerator2 Display Timer User I/O DDR Memo ry SPI Flash この単位(CPU+L2キャッシュ)がリリースの 単位になることが多い。呼び名は各社で様々。 「サブシステム(SS)」「Core Complex」「Tile」 5
本発表のリファレンス・ デザイン • いくつかの項目で例を出すために、 自作アウト・オブ・オーダ・コアでの実装例を だしています。 • https://github.com/msyksphinz-self/scariv_zero • SCARIV
: Scalable RISC-V Processor • 読み物として:./docs/ 以下に実装時に考えた いろんなことが書いてある。 • 性能的にはあんまり良いものではないので 中身をあんまりじっくり見ないでください(笑) 自作CPUをLiteXに組み込んで、FPGA上で動かした (地獄) 6
CPU設計チームの範疇 • 「CPU設計チーム」としては、完成されたIPをリリースする • アーキテクト。システム全体の構成や性能見積もりなどを考える • RTL設計チーム。RTLの設計を行う。 • 検証(Design Verification)チーム。RTLの検証を行う。
• 物理設計(Physical Design)チーム。論理合成から配置配線まで • テープアウトまでしない場合でも、小規模であるが存在する • チームの規模感 • アーキテクト : RTL設計 : 検証 : 物理設計 = 1 : 3 : 10 : 6? • 半導体設計において、検証がどれだけ重要かが分かる アーキテクト 設計 検証 物理設計 7
CPUが作られるまで マイクロ・ アーキテクチャの検討 RTL設計 • 仕様の決定 • 目標性能の決定 • モデルによる検討
• マイクロ・アーキテクチャの 詳細の決定 • RTL記述 • Smoke Testの実施 検証 • 検証プランの作成 • 検証詳細項目の作成 • 検証実施 論理合成 • 論理合成 • タイミング改善 ※ 発表者はRTL設計部分が専門なので、それ以外の 項目は詳細を突き詰めると嘘をついている可能性が あります。 8
マイクロアーキテクチャの検討 • どんな機能を搭載するのか? • RISC-V?拡張命令は何を搭載するのか? • コア数は? • どれくらいの性能を目指すのか •
Coremark値は?SPEC値は? • どの半導体プロセスを使うのか? • 動作周波数は?面積は?消費電力は? • Performance / Power / Area (PPA) のバランスが重要 9
見積もりのためのツール: サイクル精度シミュレータ • Cycle Accurate Simulator (CAS) • RTLよりも高速に動作するモデルシミュレータ •
C++などのプログラムで実際のマイクロ・アーキテクチャを模擬する • 経験上まじめな企業はだいたい用意している • 代表的なもの: Gem5 • だいたい みんな内製している気がする • 自分たちのマイクロアーキテクチャを模擬するんだから当たり前か • 現に発表者も研究で使っている • Sniper (https://github.com/snipersim/snipersim) • Gem5は中身がごちゃまぜすぎてマジ触れなかった • RISC-Vベクトル命令の載せて、提案手法を実装して性能をはかる • 相対性能を比較するのにはちょうどいい • (ハードを直接書くのに比べて) 実装が楽 10
サイクル精度シミュレータで どういったことをするのか? • 例 • 「キャッシュのサイズを~倍に増やした場合どれくらい性能が上がるのか見積もってよ」 • 「分岐予測のアルゴリズムを~に置き換えた場合、どれくらい性能が上がる?」 • こういったことが、実際にHWと作る前に見積もれる
• だいたいこれで狙った構成が目標性能を到達できるか見積もる • シミュレータと実際のHW実装の誤差が小さいことが重要 (※1) • だいたい数パーセント以内に抑えることが重要 • シミュレータ屋さんの腕の見せ所 • マルチコアでコヒーレンスとかまで考えると地獄を見る • ソフトウェアで現実のHWを如何にモデル化するか ※1 研究とかで相対性能を見積もるときはあんまり関係ないけど 11
自作アウト・オブ・オーダCPUと サイクル精度シミュレータ 俺のCPUは本来の性能を 発揮できているのか? サイクル精度シミュレータとの サイクル数一致比較環境 自作CPUとSniperシミュレータの
サイクル数を比較する環境 ベンチマーク全体での一致比較 1命令毎のサイクル数比較 だいたいこれで2~5%以内の精度に なることを確認する これが大きく乖離している場合、 実装が間違っている可能性が高い。 RTL実装のパイプライン・チャートと、サイクル精度 シミュレータのパイプライン・チャートを重ねて比較する。 12
RTL設計 • Verilogを書く • の、前に、マイクロ・アーキテクチャ・スペックの ドキュメントを作成する • 一般的にMAS (Micro Architecture
Specification) と呼ばれる • アーキテクチャ仕様書とは別物 • RTL実装の前にMASの執筆に数か月かける • モジュール内の階層構造 • 機能に対する実現方法 • 階層間のインタフェースの明確化 • 検証時にここを明文化することが非常に重要となる • DVチームに渡す前に、最低限のテストを通す • 一般的にSanity TestとかSmoke Testとか言われる LSUのMAS • モジュール階層 • 発行キュー • パイプライン • キャッシュ • ストアバッファ • インタフェース • LSU階層のインタフェース • モジュール間のインタフェース • 動作フロー • ロード命令の動作フロー • ストア命令の動作フロー • 例外発生時の動作フロー Pipe Issue L1Cache Pipe 13
検証 • CPUの検証とは :正しく動作することを確認する • 巨大なCPUを検証するための、さまざまなアプローチをとる • Topレベル一致検証 • プログラムを実際に流して検証する
• サブ階層検証 • フロントエンド・演算器・LSUなどを切り出して個別に検証 • Topレベルよりも検証効率が高い • UVMやフォーマル検証なども活用する • いつになったら検証は終わりなの? • バグ曲線の監視、カバレッジの取得など • まあ一般的に 14
命令 一致検証 • 命令セットシミュレータとの一致検証 • もっとも一般的 • プログラムカウンタ値 / レジスタ値
/ メモリアクセスなどを比較する • RTLシミュレーション中に同時に命令セットシミュレータを動かす • DPI-Cなど。RVVI (RISC-V Verification Interface) などが規定されている • 流す対象 • RISC-V Compliance Test (riscv-tests) • ランダムパタン (AAPG / torture など) • RTLの機能に特化した検証パタン (分岐予測とか) • 発表者の作った自作CPU • ランダムパタンを夜中に数億命令ながす x 数か月 15
自作の検証環境 • 機能シミュレータとしてSpike (riscv-isa-sim) を使用 • ↑ で登場したサイクル精度シミュレータとは別に、機能を正しくシミュレートするもの。 • 実際問題SpikeのISAの再限度としては微妙らしいが..
• Imperas (Synopsysが買収済) のOVPsimの方が精度が良いらしい。 • DPI-C を用いてコアとSpikeを接続 • 発表者は仕事でもこれ系の環境を死ぬほど作ったので割とこなれている。 • 命令コミットが行われる毎に、Spikeを1命令動かす • アウト・オブ・オーダ実行でも、コミットはかならずインオーダで実行されるので、ここで順番が保 証される。 • 命令PC + 命令コード + 書き込みレジスタ + CSRなどを一致検証 • 一定時間コミットが発生しないとデッドロックとして通知し停止。 16
サブ階層の検証 • CPU全体はでかすぎるので、もうちょっと細かい単位で検証する • フロントエンド (命令フェッチから命令ディスパッチ) • 演算器 (ALU /
FPU) など • メモリアクセス (Load Store Unit: LSU) など • 一般的にUVM (Universal Verification Methodology) とかを利用する • こちらでもランダムパタンをひたすら流す • サブ階層のI/FなどをUVMで監視する • 内部のモジュール間I/Fなども含めて挙動を チェック • 前ページの、MASのI/Fが重要なのはこのせい Issue Unit Pipe0 Pipe1 LDQ STQ L1D Store Buffer Instruction Dispatch Instruction Dispatch Instruction Dispatch Register Fetch Register Write Refill Request Eviction このあたりの、外部IFや 内部IFをモニタリングする 17
フォーマル検証 • テストベンチを流すだけでは、重箱の隅が見逃される可能性がある • 上記のLSUの検証とかまさに地獄となる • フォーマル検証 • テストパタンで検証するというより、設計が仕様通りであることを確認 •
EDAベンダのフォーマル検証ツール • Cadence Jasper Goldなど • フリーのツールでもなんとかなることがある • SymbiYosys : 発表者が試行した感じだと、データパス (ALUとか) の検証などが可能 • 自分で作った最適なALU/FPUを静的検証するくらいだったらなんとかなる 18
エミュレーション・FPGA • FPGAに実際に焼き込んで検証する • 検証効率がはるかに良い • 発表者はLiteXを使用してFPGA環境を立ち上げている。 • Nexys Video
Artix-7 FPGA を個人的に使っている • 10万円くらいするが、大人パワーで買った。 • EDAベンダが用意しているエミュレータ • 巨大なFPGAを組み合わせたタイプ • エミュレーション専用のASICを使っているタイプ • エミュレータを活用するための「エミュレーション・エンジニア」 • どのように検証環境を構築するか、大規模なデザインをどうやってエミュレータに乗せるか • 割とノウハウのかたまり • お値段的に、個人では使えない… • 大人パワーでも無理。 19
FPGA上で自作CPUを動かす • だいたい検証の甘い部分でバグを出す • 発表者の場合: CLINTとかPLICとか • デバッグが地獄 • 結局、Xilinx
(AMD) の Integrated Logic Analyzer (ILA) が最強 • これでLiteXのポート・ インタフェースとか、 CPUの内部に観測ポートを 挿入しまくる。 • 自作OoO CPUのLiteX上のブートに これで1ヶ月くらい溶かした。 20
論理合成 • RTLからネットリスト(AND/ORなどの基本単位と配線の組み合わせ) • 得られるもの • おおよその面積 (ゲート量) • 動作周波数
• → このへんからだいたいの電力とかも見積もれる • RTL屋さん的には、動作周波数と面積の改善 • 目標周波数に対して全く未達だった場合 • どこがクリティカルパス? • 論理を簡単化 or レジスタの前後で論理を移動できないか? • それでもどうにもならない場合、おそらく根本的にアーキテクチャが間違っている • 最悪の場合、設計しなおし • 電力改善のために、クロック・ゲーティングの挿入など 21
CPUをIPとして使ってもらうために • リリース・パッケージ • 顧客に応じてデザインをカスタマイズ • このために全部リグレッションを流し直すこともあり結構めんどい • ドキュメントの整備 •
インタフェース・リスト • コア特有のメモリ・マップやCSRなどの明示 • デザインの暗号化 • 自社のデザインが流出しないために • 完全にソースコードが見えないようにする • 変数名などをランダム化する • ライセンスの定義 • ロイヤリティ:量産チップの出荷個数に対して払うもの継続的な対価 • ライセンスの前払い:IPの権利を買うためのラインセンス • プロジェクト単位でライセンス料を払うか?複数のプロジェクトで使用してよいか? 22
まとめ • 実プロダクト・チームが、CPU設計にあたりどのようなことをしているのか簡単に紹介 • 自分の個人的な趣味の例も含めて。 • 無料のツールが増え、良い時代になった • 論理シミュレーション: Verilator
/ DSim / Vivado Sim • UVMを使った検証: DSim / Vivado Sim • フォーマル検証 : SymbiYosys • 一昔前では考えられない状況。 • 様々なアプローチで、CPUの品質を上げられる。 23