PDエンジニアがRTLを読むべき理由｜バックエンドの苦労の大半はRTLから始まる

30秒サマリー

• 物理設計の苦労の大半はRTLから始まる。配線をいくら上手にやっても、壊れたマイクロアーキテクチャは直せない。
• 論理合成とP&Rツールは最適化器であって魔法使いではない。巨大なMUX、深いコンビネーショナルチェーン、誤ったクロックゲーティングはツールが直せない構造的な問題だ。
• PDエンジニアがRTLを「設計」できる必要はない。だが読んで、匂いを嗅ぎ取り、フロントエンドエンジニアと渡り合えるレベルにはなるべきだ。
• 最低限の要件：always_ff／always_combの読み取り、ブロッキング vs ノンブロッキング、case／generate、推論ラッチの識別、ファンアウトとMUXデプスの感覚。
• 遅いRTL変更のコストは段階が遅くなるほど指数関数的に跳ね上がる。マスクセット一つに数百万〜数千万ドルかかる時代に、「RTLを知らなかった」せいで生じたECOはすべて罪だ。
• Chaseの結論：フロント・トゥ・バックをすべて触ってみろ。RTLから始めて、検証、合成／PD、STA／サインオフまで。PDだけ掘っていては天井が低い。

イントロ：バックエンドエンジニアがRTLを知らないと起こること

物理設計（PD）エンジニアの間には古くからのジョークがある。「RTLはフロントエンドの人たちの問題で、自分たちはネットリストさえ受け取ればいい」。この言葉を信じてネットリストだけを見て生きてきたエンジニアが最後に直面するのは、徹夜のコンジェスチョンデバッグと説明のつかないタイミング違反、そしてテープアウト一週間前に飛んでくるRTL ECOだ。

私は今、SynopsysでPrimeTime（STA／サインオフツール）を作るProduct Engineerとして働いている。フローの一番終わり、つまりチップになる直前のタイミングを扱う立場だ。そしてSiFive Korea（現SEMIFIVE）ではSamsung 5nmから14nmまでRTL-to-GDSフルオーナーシップで5回以上のテープアウトを経験した。フローの両端を経験した立場から断言できる。RTLを読めないPDエンジニアは、地図なしで運転するようなものだ。目的地（ネットリスト）は見えるが、なぜその道が塞がったのか、どこで迂回すべきかがわからない。

この記事は説教ではない。実際に起きた戦争の話4つをまず見せて、その次にPDエンジニアに本当に必要な最低限のRTL知識が何かを整理する。デザイナーになれという話ではない。読めて、危険なパターンを見抜き、フロントエンドエンジニアと同じ言語で話せればいい。

Episode 1. 巨大なMUXが生んだコンジェスチョン地獄

あるプロジェクトでは、クロスバー一つがブロック全体のルーティングを飲み込んだことがある。RTLを開けてみると、こんなコードだった。

// Combinational, unregistered crossbar — no pipeline register
assign data_out = (sel == 3'd0) ? data_in0 :
                  (sel == 3'd1) ? data_in1 :
                  (sel == 3'd2) ? data_in2 :
                  (sel == 3'd3) ? data_in3 :
                  (sel == 3'd4) ? data_in4 :
                  (sel == 3'd5) ? data_in5 :
                  (sel == 3'd6) ? data_in6 :
                  (sel == 3'd7) ? data_in7 : 32'd0;

完璧に合法なRTLだ。シミュレーションも通る。ところが論理合成はこれを数千のゲートに展開してチップ全体にばらまく。8つの32ビット入力がすべて一点に集まる構造——配置の立場ではすべての入力バスを一点に引き寄せなければならず、結果はルーティングコンジェスチョンのホットスポットだ。実際に業界では、4,000-to-1のMUX一つが「routing and timing nightmare」を作ったという記録もある。合法なRTLが合法な災厄を作るわけだ。

RTLを読めるPDエンジニアなら、ネットリスト段階ではなくRTLハンドオフレビューの段階でこれを捕まえる。「このクロスバーはなぜunregisteredなのか？1ステージのパイプラインを入れればコンジェスチョンは半分になる」という一言が、3週間のP&Rイテレーションを3日に短縮する。

Episode 2. 合成が直せないタイミング——問題はマイクロアーキテクチャだ

STAレポートを受け取ったPDエンジニアの日常：スラック-320psのセットアップ違反が数百件。バッファを打ち、ゲートを大きくし、リタイミングを回しても直らない。なぜなら問題が構造にあるからだ。

典型的なパターンはこうだ。1クロックサイクル内に128ステージものコンビネーショナルロジックが入っている。ワイドMUXの後ろにキャリーチェーンが付き、そこに高ファンアウトネットまで。合成の最適化は局所解に囚われる。バッファ挿入も、ゲートリサイジングも、リタイミングも無駄だ。数学的にそのクロック内に収まらない量のロジックが1サイクルに入っているからだ。

このとき必要なのはツール設定ではなくマイクロアーキテクチャの変更だ。パイプラインステージを一つ増やすか、MUXを分割するか、データパス自体を描き直すかだ。ところがPDエンジニアがRTLを読めなければ、この判断自体ができない。フロントエンドチームに「これは構造の問題だからRTLを直してくれ」と言わなければならないのに、RTLを読めないので証拠を出せない。結局何週間もツールオプションだけ回して、後でRTLチームがパイプラインを入れて1時間で解決するのを眺めることになる。

PrimeTimeを作る立場から付け加えると、サインオフ段階で見る最悪の違反はたいてい「ツールがもっと頑張れば直せる」問題ではなく「RTL段階で防ぐべきだった」問題だ。STAツールは真実を教えてくれるだけで、真実を変えてはくれない。

Episode 3. 遅いRTL変更とECO地獄の経済学

チップ開発ではバグ修正のコストは段階が遅くなるほど指数関数的に跳ね上がる。RTL段階で1行直すことと、P&Rが終わった後にECOで直すことと、マスクを作り直すことでは次元が違うコストになる。

公開されている見積もりを見れば感覚が掴める。90nm時代のマスクセットは約100万ドル、65nmは約150万ドルで、5nmクラス以下ではマスクセット一つに1,000万ドルをゆうに超える水準として知られている。テープアウト一週間前にRTL変更が入れば、選択肢は二つだ。メタル層ECOで耐えるか、フルリスピンを覚悟するか。どちらも高く、どちらもスケジュールが崩れる。

ここでPDエンジニアのRTL読解力がお金に直結する。ECOをするとき、変更されたRTLが本当にその程度の変更を要求するのかを判断できなければならない。ときどきフロントエンドから降りてくるECO RTLを見ると、機能的には同じなのにコーディングスタイルだけ変わっている場合がある。RTLを読めなければ「変わった部分だから全部回し直そう」となり、読めれば「これは機能的に等価だからスペアセルで吸収可能だ」という判断が出る。その一行の判断が数百万ドルと受注を分ける。

Episode 4. クロックゲーティングを一つ間違えると生じる電源グリッドの悪夢

RTLレベルのクロックゲーティングのミスは、PD段階で最も見つけにくいバグの一つだ。たとえば、手書きのゲーテッドクロックがある。

// DANGEROUS: hand-rolled clock gating — glitch risk
assign gclk = clk & en;

グリッチが生じるとクロックとして使うネットに望まないエッジが生じ、下流のフリップフロップが誤動作する。合成が集積クロックゲーティングセルに置き換えてくれることを期待するが、コーディングスタイルによってはツールが認識できない場合がある。そうなるとPD段階でクロックツリーがおかしく合成され、CTSは苦労し、ダイナミックパワーは跳ね、IRドロップ解析では的外れなホットスポットが出る。

RTLを読むPDエンジニアはクロック構造を見た瞬間に問う。「このイネーブル信号はグリッチフリーか？合成はICGとして認識したか？クロックゲーティングチェックはSTAでカバーされているか？」この質問をP&Rの前に投げるか、シリコンでデバッグするかの違いだ。

PDエンジニアが本当に知るべき最低限のRTL

改めて強調する。設計できるようになれというのではない。読んで、リスクを感知し、対話できればいい。範囲は以下の通りだ。

1. 読むべきコンストラクト（Verilog／SystemVerilog）

• always_ff／always_comb／assign——シーケンシャルとコンビネーショナルの区別はそのままタイミング構造の区別だ。
• ブロッキング（=）vs ノンブロッキング（<=）——シミュレーションと合成のミスマッチの古典的な原因。他人のRTLをレビューするときに一番最初に見るもの。
• if-else／case——プライオリティエンコーダ vs パラレルMUX。caseの中にdefaultがなければラッチが推論される。
• generate／parameter——パラメータ化されたモジュールが実際に何個のインスタンスに展開されるかを感覚的に知らなければ、面積／コンジェスチョンの見積もりができない。
• interface／modport（SystemVerilog）——最近のRTLはポートが数百個あるモジュールがinterfaceで束ねられている。読めなければ階層の追跡ができない。
• リセットスタイル——同期 vs 非同期リセット、リセットドメインがいくつあるか。リセットはPDでは高ファンアウトネットの主犯だ。

2. 見抜くべき合成に敵対的なパターン

• 巨大なunregistered MUX／クロスバー（Episode 1）
• 深いコンビネーショナルチェーン——1サイクルにロジックレベルが数十段以上あればマイクロアーキテクチャの問題（Episode 2）
• 手書きクロックゲーティング（clk & en）——ICG未認識、グリッチのリスク（Episode 4）
• 推論ラッチ——ifにelseがない、またはcaseにdefaultがなければラッチ。タイミング解析の暗黒地帯。
• 高ファンアウトリセット／イネーブル——数万のフリップフロップにかかるグローバルネット。CTSと電源に直接打撃。
• フリップフロップに推論された大きな配列——SRAMに行くべきメモリが数千のフリップフロップに展開されれば面積／コンジェスチョンが爆発。RTLでメモリ推論を読めなければならない。
• クロックドメインクロッシング——シンクロナイザなしで渡る信号。STAでフォルスパスに誤って切ればシリコンで死ぬ。

3. フロントエンドとの対話法

RTLを読めるようになると対話が変わる。「タイミングが出ません」ではなく「このパスのMUXデプスが6段なので1GHzに入りません。パイプラインを1段入れるかMUXを分割してください」になる。前者は愚痴で、後者はエンジニアリングだ。フロントエンドエンジニアも後者には反応する。同じ言語を話すからだ。

次のステップ：edu.vlsi.krでフロント・トゥ・バックのロードマップを辿る

RTL読みは一人で悶々と学ぶものではない。順序がある。VLSI EduのRTL2GDSロードマップは、RTLからGDSまでのフロー全体をキャリアパスとして整理した出発点だ。特にPDを目指す人なら、RTL → 検証 → 合成 → PD → STA／サインオフの順に踏むことを勧める。

キャリアパスの全体地図は44の半導体キャリアパス概要で確認できる。Architecture & RTL、Verification、Implementation & Signoffのカテゴリに分かれており、各役割ごとに段階別のスキルと学習リソースが整理されている。（参考：現在このページはベトナム語ロケールでレンダリングされており、韓国語（/ko/roadmaps）と英語（/en/roadmaps）のページは2026-10-11現在404／レンダリングエラー状態だ。サイトには日本語版RTL→PDキャリアパスの詳細ページとSTA／サインオフ深化チュートリアルページが追加されるべきだ。）

Chase's Take

正直に言うと、私も最初からRTLをうまく読めたわけではない。SiFive KoreaでRTL-to-GDSをフルオーナーシップで担ったとき、最初の数ヶ月はネットリストだけ見てP&Rを回した。そうしてSamsung 5nmプロジェクトでコンジェスチョンのために3週間を失ったことがある。原因はEpisode 1とまったく同じunregisteredクロスバーだった。そのときRTLチームのリードが私の席に来てコードを広げて言った。「これ、パイプライン1段入れるだけでいいよ」。その一言で3週間が蒸発した。その日から私はRTLを先に読む。

今はSynopsysでPrimeTimeを作る側にいる。毎日見ているのはタイミング違反レポートだ。面白いのは、サインオフ段階で最も直しにくい違反ほど原因がRTLにあるという点だ。ツールは正直だ。数字を見せるだけだ。その数字を変えるのは結局人の設計判断で、その判断の材料はRTLだ。

だから私は後輩たちにいつも同じことを言う。「全体的に全部やってみなければならない」。RTLから始めろ。次に検証、次に合成とPD、次にSTAとサインオフ。PDだけ掘れば当面は楽だ。ツールの回し方だけ知ればいいから。だが天井が低い。本当の問題は常に境界にあり、境界を行き来するには両方の言語を知らなければならない。

PrimeTimeの最も末端で働く私がRTLから始めろと言うのは皮肉に聞こえるかもしれない。だがフローの終わりで働くほど始まりがよく見える。すべての苦痛の根はRTLにある。だからそこから学べ。

FAQ

Q1. PDエンジニアがRTLを直接「設計」できる必要はありますか？

ない。目標は可読性（readability）だ。他人の書いたRTLを読み、タイミング／コンジェスチョン／電力の観点から危険な構造を見つけ出し、フロントエンドエンジニアに具体的に説明できれば十分だ。直接モジュールを設計する能力はボーナスだ。

Q2. RTLを学ぶのにどれくらいかかりますか？

読みレベルまでなら2〜3ヶ月でいい。Verilog／SystemVerilogの基本文法1ヶ月、合成がRTLをどう解釈するか（ラッチ推論、MUX構造、リソース共有）1ヶ月、実際のプロジェクトのRTLレビュー参観1ヶ月。この記事のチェックリストを手にレビューに入れば最も早く伸びる。

Q3. 合成ツールが良くなればRTLの知識は不要になりませんか？

逆だ。ツールが良くなるほど残るのはツールが直せない構造的な問題だけだ。AIベースのツールがルーチンの最適化を持っていくほど、マイクロアーキテクチャ判断のような人間の取り分がより重要になる。RTLの理解は減価しない資産だ。

Q4. STA／サインオフエンジニアにもRTLの知識は必要ですか？

もっと必要だ。STAはタイミングを「判定」する段階なので、違反の根本原因がRTL構造にあるのかツール／制約の問題なのかを見分けなければならない。PrimeTimeレポートを読んで「これはSDCの問題ではなくパイプラインの問題だ」と言えるSTAエンジニアが最も高く評価される。

本記事は著者の実務経験に基づくキャリア視点の記事です。特定プロジェクトの数値は説明のために簡略化されています。