第 1 回では全体の流れを紹介しました。SkyWater 130 で約 113 万個のスタンダードセルを持つ OpenTitan Earlgrey を、オープンソースのツールで RTL からサインオフタイミングまで進め、G2 で管理し、実作業の多くを Claude Code が担いました。この回は、その物語の最初の大きな転換点です。チップをフラットで試し、うまくいかず、チップチームと同じボトムアップのやり方に切り替えました。
データからフラットなチップの大きさを決める
40 個のブロックはすべて Yosys と yosys-slang で問題なく論理合成できました。何かを配置する前に、ネットリストからダイの大きさを見積もりました。113 万個のセルと 23 個のメモリには約 41 mm² が必要なので、フラットなチップには 8.1 mm のダイを与えました。最初の実行の前に 1 つ設定を変える必要がありました。デフォルトのセルパディングだけで配置面積が 2 倍になっていたので、小さくしました。
G2 ではフラットなチップはバージョン v1 です。OpenROAD のチェックアウトで、ステージごと（init、floorplan、place、CTS、route など）に 1 つのディレクトリがあり、それぞれにログ、レポート、QoR サマリー、README があります。
2:19YouTube で見る（英語） ↗Bilibili で見る（中国語） ↗
24.7 時間、そのほとんどが 1 つのステップ
初期化は 7 分、フロアプランは 23 分でした。配置には 24 時間 43 分かかりました。
そのうち約 22.5 時間は 1 つのステップでした。repair_design です。セルのサイズ変更やバッファの追加で、スルー、容量、ファンアウトを修正します。チップ内のすべてのドライバーをシングルスレッドで順に処理します。終盤には、進捗表の 1 行ごとに 1 時間近くかかりました。合計で約 76,000 個のバッファを追加しました。
結果は使えるものではありませんでした。
- どこもかしこも混雑。 推定配線混雑マップは、いくつかのホットスポットだけでなく、スタンダードセル領域全体が赤でした。
- 低速コーナーの reg2reg パスで −164 ns のセットアップスラック。最悪パスは多倍長演算アクセラレーターの otbn の中でした。
- 詳細配置で、合法な位置を見つけるためにセルが最大 2.8 mm 移動しました。
- ログにエラーが 1 つ： 電源グリッドのチェックで、VDD がメモリマクロの 2 本のピンとショートしていました。
症状は違っても、原因は 1 つです。1 か所にロジックが多すぎること。同じフラットなフロアプランで努力を重ねても、それは変わりません。
丸一日かかる実行から得たルール
これほど長い実行は、失敗するたびに 1 日を失います。そこから学び、プロジェクトの最後まで守ったルールがあります。
- 長い EDA 実行にタイムアウトを付けない。 以前の試行は、自分たちで設定した 4 時間のタイムアウトで止められました。出力は何もなく、何も学べませんでした。
- グローバル配置のあとにチェックポイントを保存する。 あとで失敗してもゼロからやり直さずにすみます。
- ツールに進捗を出力させる。 遅いステップと止まったステップを見分けられるようにします。
- スレッド数を明示的に設定する。 どのツールでもです。
階層化へ
単独でハード化するブロックを 9 個選びました。otbn、Ibex CPU コア、kmac、aes、entropy_src、フラッシュと RRAM のコントローラー、RRAM アレイ、そしてチップで 3 回使われる i2c です。合わせて 11 インスタンスになります。約 70 万個のセルがトップレベルから外れ、約 44 万個が残ります。
フラットなチップは、起きたことの記録として v1 のまま残しました。何も上書きしていません。階層化したチップは v2 になりました。
G2 でブロックをハード化する
どのブロックも同じ手順をたどります。新しいバージョン、OpenROAD のチェックアウト、そしてステージを 1 つずつ、それぞれ専用のディレクトリで。配置のあとにグローバル配線チェックを流すと、数分でそのブロックがそもそも配線できるかがわかります。何時間もかかるクロックツリー合成と詳細配線の前にです。
2:29YouTube で見る（英語） ↗Bilibili で見る（中国語） ↗
いちばん難しかったのは otbn で、5 つのバージョンを経ました。
- v2： 10 MHz でも幅の広いデータパスがタイミングを約 40 ns 外したので、新しい制約バージョン（SDC v03）で 2 サイクルパスにしました。
- v3、コア 2.1 mm： グローバル配線が使えるトラックの 104% を必要としました。止めました。
- v4、2.6 mm： 83.5%。まだ約 10 万本のトラックがオーバーフロー。
- v5、3.0 mm： 50.6%、オーバーフローはゼロ。配線可能です。
v5 でも配線が通るまでに 5 回の試行が必要でした。失敗はどれも、それを示したログと修正方法とともに、その実行の README に残っています。終わらない修正ステップ、後の再配線に漏れたフラグ、そして詳細配線が接続できないガイドです。
本当の解決策は数値 1 つでした。グローバル配線はトラックの 58% だけで計画していたため、実際には存在しないオーバーフローを報告し、詳細配線が使えないガイドを作っていました。レイヤーの derate を 0.2 にすると、グローバル配線のオーバーフローはゼロになり、詳細配線の違反は最初のパスの 591,884 件から 11 パス後には 1,988 件まで減りました。その配線には 6 時間かかりました。
残りの 8 つと、クロックの変更 1 つ
残りの 8 ブロックはもっと簡単でした。9 個全体で配置配線は約 20 時間です。下の図に 9 ブロックの結果をまとめました。負のスラックはブロックの入出力の予算と小さなホールドの不足で、コアロジックの失敗ではありません。たとえば flash_ctrl の −38.1 ns は入力から出力へのパスで、reg2reg のスラックは +26.8 ns です。
ブロックのうち 7 個は、チップのクロックを 10 MHz に決める前に配線済みでした。G2 ではクロックは公開された制約バージョンの一部なので、G2 のステージが配線済みのブロックを新しいクロックで再タイミングしました。配置も配線もやり直していません。
配線済みのブロックを IP にする
配線済みのブロックは 3 つのビューで再利用可能な IP になります。どれも finish ステージで書き出されます。
- abstract LEF： 外形、ピン、ブロックされた領域。
- タイミングモデル： 2 つのコーナー（ss 1.60 V と ff 1.95 V、どちらも 100 °C）。
- ブラックボックスの Verilog スタブ： ポートだけ。
1 つ落とし穴がありました。OpenROAD の abstract の書き出し処理は、ブロック内部のすべての電源図形を、それらをつなぐビアなしでピン形状として出力していました。1 つ上の階層では、そのピンは浮いてしまいます。電源ピンとしては最上位のストラップだけを残しました。ブロックはメタル 1 から 7 を使い、トップレベルはその上を配線します。
2:05YouTube で見る（英語） ↗Bilibili で見る（中国語） ↗
G2 では、これらのビューはハード IP としてライブラリマネージャーに入ります。ベンダーの IP と同じく、ブロックごとに 1 バージョン、コーナーごとに liberty ファイルを持ちます。エントリーは 11 個で、9 個のブロックと、OpenTitan のアナログスタブ 2 個（ast と USB の差動レシーバー）です。
トップレベルでは、ブロックごとに 1 行で扱いが決まります。synthesis の行はブロックをロジックのまま残します。hardmacro の行はブラックボックスを取り込み、OpenROAD はライブラリからそのレイアウトとタイミングを読みます。メインの電源ドメインにはハードマクロの行が 9 つあります。i2c は 1 行で 3 インスタンスです。
どのレポートも「問題なし」と言ったバグ
あるとき、11 個のマクロがすべて消え、それでもどのレポートもきれいに見えました。フラット化したネットリストを書き出すヘルパーがブラックボックス属性を落としたため、論理合成がマクロを平坦化して消してしまい、未マッピングのセルはゼロと報告しました。普通は成功を意味する数字です。
ネットリスト内のマクロを数えて見つけました。今では、ハードマクロがあるはずの階層に 1 つもなければ、フローは失敗します。教訓は、エラーがないことだけでなく、期待する階層があることを確かめることです。
結果
新しいトップレベルのインスタンスは 113 万ではなく 529,205 で、配置は数時間で終わりました。実行時間の問題は解決しました。しかし配線はまだです。次の回では、トップレベル最初の配線チェックで 122 万本のトラックがオーバーフローし、その発生源を突き止める必要がありました。