← 講義ポータルへ戻る 第11回〜第13回 実験講義用

第6章：物理検証とテープアウト・実ボード展開（サインオフと実証）

本章は設計プロセスの最終防衛線です。LibreLaneが出力した完成データ（GDSII）が、工場の物理ルールを満たしているかを検証する「サインオフ（承認）」を行います。さらに、GitHubと連携したテープアウトの手順、そして実チップが届いた後のWiFi周辺機器拡張プランまでを解説します。

※本章は現行版（ttsky25b / LibreLane 3.0.3）に準拠して改訂しています。 成果物パスは runs/wokwi/final/... です。

6.1 【前提】DRC・LVSはLibreLaneフロー内で自動実行される

LibreLane（OpenLane 2系）のフローは、配置配線のあとにサインオフDRC（Magic／KLayout）とLVS（Netgen）を自動で実行します。つまり、ハードニングが最後まで完走した時点で、これらの物理検証はフローの一部として済んでいます。本節では、その結果を「自分の目で確認する」方法を学びます。

6.2 【Step 1】MagicツールによるGDSIIレイアウトの目視確認

自動配置配線が成功したレイアウトデータを、半導体業界標準のエディタであるMagicで開いて眺めてみます。Tiny TapeoutのツールにはGUIを開くショートカットが用意されています。WSLでGUIが開かない場合は、先に xhost +local:docker を実行してください。

# Tiny Tapeoutのツール経由でKLayout/OpenROAD GUIを開く（推奨）
./tt/tt_tool.py --open-in-klayout
# または
./tt/tt_tool.py --open-in-openroad

Magicを直接使ってGDSを開く場合は、最終GDSのパスを指定します。現行フローでは最終GDSは runs/wokwi/final/gds/ に出力されます（ファイル名はトップモジュール名）。

# 最終GDSをMagicで開く例（PDK_ROOT が設定済みであること）
magic -T $PDK_ROOT/sky130A/libs.tech/magic/sky130A.tech \
      runs/wokwi/final/gds/tt_um_riscv_soc.gds

※旧版の runs/tt_top/final/gds/... というパスは現行版には存在しません。runs/wokwi/final/gds/ が正しい場所です。また magic -T sky130A ... のようにtechを名前だけで渡す書き方は環境依存なので、上記のようにPDK内のtechファイルをフルパスで指定するのが確実です。GUIで眺めるだけなら --open-in-klayout が最も手軽です。

6.3 【Step 2】DRC（デザインルールチェック）結果の確認

DRC（Design Rule Check）は、配線幅・間隔・層の重なりなどが工場の製造ルールを守っているかの検査です。LibreLaneフローが完走していれば、サインオフDRCは実行済みです。違反があればフローが警告・停止するため、最後まで完走した＝DRCを通過したと考えてよいですが、念のためレポートを確認します。

# DRC関連レポートを探す例
find runs/wokwi -iname "*drc*"

DRCレポートに違反件数 0（またはエラーなし）と記録されていれば、製造ルール上の問題はクリアです。

6.4 【Step 3】NetgenによるLVS（回路図対レイアウト一致検証）

LVS（Layout Versus Schematic）は電気的な接続のチェックです。「合成で作られたネットリスト（あるべき回路）」と「レイアウトから抽出した接続（実際にできた回路）」を比較し、一致するかを検証します。これもフロー内で自動実行されます。

# LVS関連レポートを探す例
find runs/wokwi -iname "*lvs*"

LVSレポートの最終行に、両者が一致した旨のメッセージ（例：Circuits match uniquely.）が記録されていることを確認します。

※具体的なメッセージ文言はNetgen／LibreLaneのバージョンで異なります。「ミスマッチ0」「uniquely matched」といった一致を示す結論行を確認してください。これが確認できれば物理検証のサインオフは完了です。

6.5 【Step 4】GitHub Actions CIを用いたテープアウト提出

Tiny Tapeoutの大きな利点は、製造データの提出が「GitHubリポジトリへのプッシュ → CIによる自動ハードニング」で完結する点です。ローカルで設計を固めたら、それを自分のGitHubリポジトリに反映します。

  1. 新規プロジェクトは、現行シャトル用のテンプレート ttsky-verilog-template を「Use this template」から自分のリポジトリとして作成し、そこに設計（src/ のVerilogと info.yaml）を入れるのが基本です。

    ※旧版にあった tt09-verilog-template は世代が古いため、新規提出には使いません。提出先シャトル（例：ttsky26a など）に対応した最新テンプレートを使ってください。締め切りや対象シャトルは公式サイトで要確認です。

  2. 作成・編集したファイルをコミットします。 
    git add src/ info.yaml
git commit -m "Complete RISC-V SoC design (local DRC/LVS clean)"
  3. 自分のリモートリポジトリ（GitHub）へプッシュします。 
    git push origin main
  4. ブラウザで自分のGitHubリポジトリを開き、[Actions] タブをクリックします。クラウド上のCI（tt-gds-action、内部でLibreLaneを使用）が自動的に起動し、論理合成・配置配線・物理検証（DRC/LVS）を再実行します。
  5. すべてのジョブが緑のチェック（成功）になり、GDSが生成されれば、ローカルと同じ結果がCIで再現できたことになります。あとは公式サイトの案内に従い、対象シャトルへ提出します（提出フォーム／登録手順はシャトルごとに公式ページで確認）。

※「プッシュするだけで自動的にシャトルへマージされる」わけではありません。CIでGDSが正しく生成されることを確認したうえで、公式の提出手続き（対象シャトルへのサブミット）を行う必要があります。

6.6 【Step 5】実チップの到着と外部WiFiドングル（ESP32）拡張計画

提出・製造を経て数ヶ月後、自分のRISC-V CPUが刻まれたシリコンダイが評価用ボードに載った状態で届きます。

  1. デモボードでの基本Lチカ検証： ボードをPCとUSBで接続し、リセット（rst_n）を解除します。SoC内のRISC-Vコアが動き出し、アドレス 0x4000_0000 のレジスタを叩いて、ボード上の物理LEDが点滅することを確認します。
  2. WiFiモジュールによるIoT拡張： 双方向ピン（uio）のうち数ビットをSPI通信ポートとして再定義し、外部の安価なWiFiモジュール（ESP32マイコンボードなど）の通信ピンへ接続します。自作RISC-V CPUからSPI経由で通信要求を送り、ESP32に無線LANの処理を肩代わりさせることで、インターネットから受信したデータでLEDの点滅パターンを変えるといった、「インターネット接続型オリジナルRISC-V IoTボード」へと発展させられます。

※Tiny TapeoutのGPIO（ui_in/uo_out/uio）の電気的仕様（電圧・駆動能力・タイミング）には制約があります。外部モジュールと接続する際は、公式の GPIO仕様 とレベル変換の要否を必ず確認してください。

← 講義ポータルへ戻る