--- title: "OpenLane2とは？後継LibreLane 3.0の導入・使い方と移行手順【2026年11月】" url: "https://www.issoh.co.jp/tech/details/10733/" published: 2026-01-26 updated: 2026-11-11 categories: ["開発"] publisher: "株式会社一創" --- # OpenLane2とは？後継LibreLane 3.0の導入・使い方と移行手順【2026年11月】 OpenLane 2は、RTL（Verilogなどで書いた回路記述）からGDSII（製造用のレイアウトデータ）までを、オープンソースのEDAツールだけで自動実行するASIC設計フロー基盤です。Efabless社で開発されましたが、同社の事業停止を受けて原作者が**LibreLane**と改称して開発を引き継ぎ、2025年8月18日に最初の版（2.4.0）を公開しました。2026年11月11日時点の最新の安定版は[PyPIのlibrelane](https://pypi.org/project/librelane/)で3.0.17（2026年10月26日公開）、次の3.1.0は開発版（3.1.0.dev6、11月8日）の段階です。PyPIの`openlane`パッケージは、正式版としては2025年2月21日の2.3.10が最後です。 この記事では、OpenLane 2とLibreLaneの関係を整理したうえで、インストール方法の選び方、最初の実行、Classicフローの工程と出力、トップレベル用のChipフローとの使い分け、設定ファイルとPythonでのフロー拡張、マクロ統合、OpenLane 2からの移行で変わる設定までを、LibreLane 3.0.17の公式ドキュメントと、Python環境に導入してフロー定義を調べた結果に基づいて解説します。 ## まとめ：OpenLane 2の現状と使い始める手順 - **これから使うならLibreLane**：OpenLane 2の開発は[GitHubのlibrelane/librelane](https://github.com/librelane/librelane)へ移り、PyPIのパッケージ名もコマンド名も`librelane`です。旧リポジトリ（現`chipfoundry/openlane2`）のREADMEも移動先としてLibreLaneを案内しています。 - **OpenLane 1は新規設計に使わない**：公式FAQは、OpenROAD Project配下のOpenLane 1.0を保守モードとし、新しい設計には推奨しないと明記しています。 - **インストールはNixが第一候補**：LinuxとmacOS（Intel・Apple Silicon）でネイティブに動きます。Linux・WSL2ならAppImage、手元にDockerがあるなら`pip install librelane`と`--dockerized`でも動きます。 - **最初の確認は2コマンド**：`librelane --smoke-test`で環境を確かめ、`librelane --run-example spm`で例題を一周させます。 - **マクロはClassic、チップ全体はChip**：既定のClassicフロー（80工程）はTiny TapeoutやCaravelに載せるブロックの作成用で、パッドリングやシールリングを生成するトップレベル用には3.0で加わったChipフロー（83工程）を使います。 - **OpenLane 2の設定はほぼそのまま動く**：3.0で`FP_PDN_`系が`PDN_`系へ改名されましたが、設定ファイルでは旧名を非推奨の別名として受け付けます。一方、ホールド違反の判定範囲の拡大など、結果が変わる既定値の変更があります。 ## OpenLane 2からLibreLaneへの改称と開発体制 OpenLane 2は、OpenLane 1をTclからPythonで作り直す計画として2022年にEfablessで始まりました。FOSSi Foundationのニュースレター[El Correo Libre 88](https://fossi-foundation.org/blog/2025-08-18-ecl88)（2025年8月18日）に引用された開発者の説明では、OpenLane 2は2024年2月にソフトローンチし、厳しいタイミング要件のシリコンで検証を終えた数日後に、Efablessが資金難で事業を停止しました。商標や名前空間をEfablessから引き継ぐのが難しく、OpenLane 1とは中身も大きく異なっていたため、プロジェクトはLibreLaneへ改称され、FOSSi Foundationの下で開発が続いています。 | 系統 | リポジトリ | PyPI | 状態（2026年11月） | | ---------- | -------------------------------- | ---------------------------- | --------------- | | OpenLane 1 | The-OpenROAD-Project/OpenLane | なし（Makefile・flow.tcl） | 保守モード・新規非推奨 | | OpenLane 2 | chipfoundry/openlane2（旧efabless） | openlane 2.3.10（2025-02-21） | 開発はLibreLaneへ移動 | | LibreLane | librelane/librelane | librelane 3.0.17（2026-10-26） | 開発中・Apache-2.0 | 版の流れは、OpenLane 2の正式版2.0.0が2024年4月17日、LibreLaneとして最初の2.4.0が2025年8月18日、Python 3.10以上を必須にした3.0.0が2026年3月25日です。英語のチュートリアルには「2026年初頭に改称され、3.0.0が最初のLibreLane版」と書くものがありますが、PyPIの公開記録と2.4.0の変更履歴（「Efablessの事業停止後に原作者が作ったOpenLane 2のフォーク」）のとおり、改称は2025年8月の2.4.0です。2.4.0ではPDKの版管理ツールをVolareからCielへ、Nixのバイナリキャッシュを`nix-cache.fossi-foundation.org`へ切り替えています。 シャトルでテープアウトする場合は、使う版をテンプレート側が決めます。旧OpenLane 2の[chipfoundry/openlane2のREADME](https://github.com/chipfoundry/openlane2)は、ChipFoundryでテープアウトするなら`caravel_user_project`や`openframe_user_project`のテンプレートが適切な版を自動で取得すると案内しています。手元で最新のLibreLaneを入れても、提出用のテンプレートが指定する版と一致するとは限りません。なおChipFoundryは、ChipCreate CC2509シャトルからLibreLaneを主要フローに採用しています。 ## OpenLane 1・LibreLane・他のフローの違い ### OpenLane 1との違い LibreLaneの既定フローClassicは、OpenLane 1のフローをPythonで再実装したもので、OpenLane 1の設定ファイルの約99%をJSONでもTclでも読み込めると[公式の移行ガイド](https://librelane.readthedocs.io/en/latest/getting%5Fstarted/migrants/index.html)は説明しています。ただしTclの設定は扱いが不安定なのでJSONへの書き直しが推奨され、Tclで書いた対話スクリプトは動きません。移行ガイドは、途中で失敗しても前の工程までのメトリクスとレポートが残る点と、工程を指定して再実行できる点を移行の利点に挙げています。 | 項目 | OpenLane 1 | LibreLane（OpenLane 2） | | ---------- | ---------------------- | --------------------- | | 実装 | Tclスクリプト | 型チェック付きPython | | 起動 | ./flow.tcl -design spm | librelane config.json | | 設定の検証 | なし（不正値は途中で異常終了） | 変数名の誤記・型違いで停止 | | 最終成果物 | results/final | final | | メトリクス・レポート | フロー終了時にまとめて抽出 | 工程ごとのフォルダに保存 | | 環境 | Docker＋Makefile | Nix・AppImage・Docker | ### OpenROAD・OpenROAD Flow Scriptsとの関係 OpenROADはLibreLaneが呼び出すツールの1つで、フロアプラン・配置・クロックツリー合成・配線・タイミング解析を担います。LibreLaneはこれにYosys（論理合成）、Magic・KLayout（GDSII出力とDRC）、Netgen（LVS）などを束ねて、RTLからGDSIIまでを1本のフローにしたものです。同じくOpenROADを使うフローとして、OpenROAD Projectが保守するOpenROAD Flow Scripts（ORFS）とZeroASICのSiliconCompilerがあります。 | 比較点 | LibreLane | ORFS | SiliconCompiler | | ------- | ----------------------------- | ------------------------------------------ | --------------------- | | 設定 | JSON・YAML・Tcl・Python | Make変数（config.mk）・Tcl | Python | | ツールの入手 | 同梱（Nix・Docker） | 別途（ビルドスクリプト・.deb） | 別途（ビルドスクリプト） | | 商用ツール | プラグインで可 | 不可 | 可 | | オープンPDK | sky130・gf180mcu・ihp-sg13g2（β） | sky130・gf180mcu・nangate45・asap7・ihp-sg13g2 | sky130・gf180mcu・asap7 | 表は[LibreLane公式FAQ](https://librelane.readthedocs.io/en/latest/faq.html)の比較表をもとに、設定の形式とツールの入手方法を補ったものです。研究用の先端ノード（asap7など）で実験するならORFS、sky130やgf180mcuのシャトルへ出す設計ならOpenLane 1の資産とシャトル向けテンプレートを引き継げるLibreLane、という分け方になります。 ## LibreLaneのインストール方法の選び方 LibreLaneはYosysやOpenROADなどのツール群を同梱した環境ごと配布されます。Linuxでの最小要件は2.0GHz以上の4コアCPUとメモリ8GiB、推奨は第6世代Intel Core以降またはAMD Ryzen 1000シリーズ以降とメモリ16GiBで、主な対象OSはUbuntu 22.04以降です。 | 方法 | 対応環境 | 向いている人 | | -------- | ------------------------- | -------------------------- | | Nix（推奨） | Linux・macOS（x86-64・ARM64） | macOSで性能を出したい人、ツールを差し替えたい人 | | AppImage | Linux・WSL2 | 1ファイルで手早く始めたい人 | | Docker | Windows・macOS・Linux | OpenLane 1からDocker環境を持ち越す人 | ### Nixでのインストール Nixを公式インストーラーで入れる際に、FOSSi Foundationのバイナリキャッシュと`nix-command`・`flakes`を有効にします。`apt`で入るNixは古いことが多いため使わないよう[公式のインストール手順](https://librelane.readthedocs.io/en/latest/installation/index.html)が警告しています。初回の`nix-shell`はキャッシュからのダウンロードに10分前後かかります。 ``` curl --proto '=https' --tlsv1.2 -fsSL https://artifacts.nixos.org/nix-installer | sh -s -- install --no-confirm --extra-conf " extra-substituters = https://nix-cache.fossi-foundation.org extra-trusted-public-keys = nix-cache.fossi-foundation.org:3+K59iFwXqKsL7BNu6Guy0v+uTlwsxYQxjspXzqLYQs= extra-experimental-features = nix-command flakes " # ターミナルを開き直してから git clone --branch 3.0.17 https://github.com/librelane/librelane nix-shell librelane/shell.nix librelane --smoke-test ``` ### Dockerでのインストール DockerではLibreLane本体だけをpipで入れ（システムのPythonへ直接入れられない環境（PEP 668）では、venvを作って有効化してから入れます）、実行時に`--dockerized`を付けるとツール入りのコンテナが起動します。マウントされるのはホームフォルダ、PDKルート、カレントディレクトリの3か所で、それ以外の場所にある設計データは`--docker-mount`で追加します。`--dockerized`は、`--docker-mount`などコンテナ用のオプションを除くすべてのオプションより前に置きます（`--docker-mount`は`--dockerized`より前）。 ``` python3 -m pip install librelane==3.0.17 librelane --dockerized --smoke-test librelane --docker-mount /data/designs --dockerized /data/designs/spm/config.yaml ``` NixとDockerのコード例は、この記事で確かめた3.0.17に版を固定しています。新しい版を使うときは`--branch 3.0.17`や`==3.0.17`を外してください。 ### WindowsでのWSL2の準備 Windowsでは、どの方法でもWSL2を経由します。ツール群がLinux前提で作られており、Windowsへの移植は各ツールの動作保証まで含めると現実的でないため、と公式FAQは説明しています。公式手順が求めるのはWSL1ではなくWSL2で、AppImageを使う場合の最小要件はWindows 10 バージョン2004（ビルド19041）以降です。PowerShellで`wsl --install -d Ubuntu`を実行し、`wsl --list --verbose`のVERSION列が2になっていることを確かめてから進めます。`systemd`は2023年半ば以降に入れたWSL2なら既定で有効ですが、それより前の環境では無効のことがあるため、`/etc/wsl.conf`の設定を確かめてから進めます。WSL側の設定全般は[WSLで開発環境を構築する手順](/tech/details/17354/)が参考になります。 LinuxやWSLで`warning: setlocale: cannot change locale (en_US.UTF-8)`が出る場合は、LibreLaneがアメリカ英語のUTF-8ロケールだけを使うためです。Ubuntuなら`sudo dpkg-reconfigure locales`で`en_US.UTF-8`を有効にして`sudo locale-gen`を実行し、必要に応じて`export LOCALE_ARCHIVE=/usr/lib/locale/locale-archive`を設定してからLibreLaneの環境に入ります。 ### 同梱ツールの版の確認 3.0.17からは、GitHubの各リリースに同梱ツールの版を並べた`tool_versions.txt`が添付されます。[3.0.17のリリース](https://github.com/librelane/librelane/releases/tag/3.0.17)に付いた一覧の主な行は次のとおりで、ツール環境はNixOS 25.11を土台にしています。 | ツール | 3.0.17の版 | 役割 | | --------- | -------------------- | ----------- | | Yosys | 0.62 | 論理合成 | | OpenROAD | 2026-02-17（dcf36133） | 配置配線・STA | | OpenSTA | 2026-02-14 | タイミング解析 | | KLayout | 0.30.7 | GDSII出力・DRC | | Magic | 8.3.623 | GDSII出力・DRC | | Netgen | 1.5.316 | LVS | | Verilator | 5.044 | Lint | pipでLibreLaneだけを入れてツールを自前で用意する方法もありますが、公式の手動インストールガイドは「ツールを持ち込むことは勧めない」と冒頭で警告し、版の不一致による不安定さを理由に挙げています。一覧には「+ 2 patches」のようにLibreLane側で当てたパッチの数も書かれており、版番号を揃えただけでは同じツールになりません。どうしても自前で揃えるなら、版・コミット・適用パッチまで合わせるのが前提です。 ## 最初の実行：smoke testと例題spm `librelane --smoke-test`は結果を残さない動作確認です。続けて`librelane --run-example spm`を実行すると、例題のspm（直列・並列乗算器）がカレントディレクトリへコピーされ、Classicフローが最後まで走ります。PDKを指定しなければsky130Aが使われ、未導入ならCielが自動でダウンロードします。 LibreLane 3.0.17に同梱されたspmの設定ファイルは次のとおりです。 ``` # Basics DESIGN_NAME: spm VERILOG_FILES: dir::src/*.v CLOCK_PERIOD: 10 CLOCK_PORT: clk PNR_SDC_FILE: dir::src/impl.sdc SIGNOFF_SDC_FILE: dir::src/signoff.sdc # PDN PDN_VOFFSET: 5 PDN_HOFFSET: 5 PDN_VWIDTH: 2 PDN_HWIDTH: 2 PDN_VPITCH: 30 PDN_HPITCH: 30 PDN_SKIPTRIM: true # Pin Order IO_PIN_ORDER_CFG: dir::pin_order.cfg # Technology-Specific Configs pdk::sky130*: FP_CORE_UTIL: 45 CLOCK_PERIOD: 10.0 scl::sky130_fd_sc_hs: CLOCK_PERIOD: 8 scl::sky130_fd_sc_ls: MAX_FANOUT_CONSTRAINT: 5 pdk::gf180mcu*: CLOCK_PERIOD: 24.0 FP_CORE_UTIL: 38 MAX_FANOUT_CONSTRAINT: 4 PL_TARGET_DENSITY: 0.5 ``` まず書くのは`DESIGN_NAME`（トップモジュール名）と`VERILOG_FILES`で、同期回路なら`CLOCK_PORT`と`CLOCK_PERIOD`（ns）も指定します。`CLOCK_PERIOD`を省くと既定の10.0nsで、`CLOCK_PORT`は組み合わせ回路なら省略できる変数です。`dir::`は設計ディレクトリ（既定では設定ファイルのある場所）からの相対パスを表し、ワイルドカードも使えます。`pdk::sky130*:`のブロックは、PDKがsky130系のときだけ中の値で上書きする条件付き設定で、1つのファイルでsky130とgf180mcuの両方に対応できます。SystemVerilogで書いた設計は、3.0で加わった代替フロントエンドのSlang（`USE_SLANG`）で読み込めます。HDLの選び方そのものは[Verilog・VHDL・SystemVerilogの違いと判断表](/tech/details/18905/)で整理しています。 ### 実行タグと設定の一時上書き 自分の設計は設定ファイルを直接渡して実行します。PDKは設定ファイル、`--pdk`、環境変数`PDK`、既定のsky130Aの順に優先されます。 ``` librelane config.yaml librelane --pdk gf180mcuD --run-tag gf180_try1 config.yaml librelane --pdk gf180mcuD --run-tag gf180_try1 --overwrite -c CLOCK_PERIOD=30 config.yaml librelane --last-run --flow OpenInKLayout config.yaml ``` 実行タグを付けなければ`runs/RUN_2026-11-11_10-30-00`のような日時のフォルダが作られます。既存のタグを指定すると、そのフォルダの続きに工程が追記され、`--overwrite`を付けたときだけ中身を消してやり直します。`-c KEY=VALUE`はその実行だけ設定変数を上書きするオプションです。`--help`は値をJSONで書くよう説明していますが、3.0.17の実装は`=`の右側を文字列のまま受け取って変数の型へ変換するため、`CLOCK_PORT="clk"`と書くと引用符まで値に入ります。文字列は`CLOCK_PORT=clk`のように引用符なしで渡してください。4行目は、直近の実行結果をKLayoutで開くための1工程だけのフローです。なお3.0からは、`~`で始まるパスを引数に渡すとエラーになります。シェルが展開できずに引用符付きの`~`が残る事故を防ぐためで、絶対パスで書き直せば通ります。 ## Classicフローの工程と出力ファイル LibreLane 3.0.17を導入して`Flow.factory`を調べると、Classicは80工程でした。Checker系の検査工程を除くと、主な流れは次のとおりです。 | 段階 | 主な工程ID | ツール | | ---------- | --------------------------------------------------- | -------------------- | | Lint | Verilator.Lint | Verilator | | 論理合成 | Yosys.Synthesis | Yosys | | フロアプラン・電源網 | OpenROAD.Floorplan、OpenROAD.GeneratePDN | OpenROAD | | 配置 | OpenROAD.GlobalPlacement、OpenROAD.DetailedPlacement | OpenROAD | | クロックツリー合成 | OpenROAD.CTS | OpenROAD | | 配線 | OpenROAD.GlobalRouting、OpenROAD.DetailedRouting | OpenROAD | | 寄生抽出・STA | OpenROAD.RCX、OpenROAD.STAPostPNR | OpenROAD・OpenSTA | | GDSII出力 | Magic.StreamOut、KLayout.StreamOut、KLayout.XOR | Magic・KLayout | | DRC・LVS | Magic.DRC、KLayout.DRC、Netgen.LVS | Magic・KLayout・Netgen | GDSIIをMagicとKLayoutの両方で書き出し、KLayout.XORで両者の差分を取るのが特徴です。2つのツールの出力が食い違えば、Checker.XORの段階で検出されます。 ### 実行フォルダの読み方 結果は`runs/<実行タグ>/`の下に出ます。最終成果物は`final`に、工程ごとの出力は`01-verilator-lint`のような連番フォルダに分かれ、各工程は自分のフォルダにしか書き込みません。最初に見るファイルは次の4つです。 - `final/metrics.csv`・`final/metrics.json`：面積・タイミング・DRC違反数などの集計。OpenLane 1の`report.csv`から行と列が入れ替わっています。 - `*-openroad-stapostpnr/summary.rpt`：全コーナーのタイミングをまとめた表。 - `resolved.json`：既定値・PDK・コマンドライン上書きを反映した最終設定。そのまま`librelane`へ渡せば同じ条件で再実行できます。 - `error.log`・`warning.log`：エラーと警告の一覧。 ### 途中工程からの再実行 配線だけやり直したい場合は、工程IDを指定して範囲を絞ります。`--from`・`--to`で開始・終了工程、`--only`で1工程だけ、`--skip`で除外します。特定工程の直後の状態から別のフローを始めるときは、その工程フォルダの`state_out.json`を`--with-initial-state`で渡します。 ``` librelane --last-run --from OpenROAD.GlobalRouting config.yaml librelane --with-initial-state runs/RUN_TAG/*-openroad-detailedrouting/state_out.json --flow OpenInKLayout config.yaml ``` 同じタグで再実行すると連番が続きから振られるため、工程フォルダの番号は実行の履歴によって変わります。例で`*`を使っているのはそのためです。 ## ClassicとChipの使い分け：シャトル別のテンプレート LibreLane 3.0で加わったChipフローは、チップ全体（トップレベル）をテープアウトするためのフローです。[3.0のリリース告知](https://fossi-foundation.org/librelane/blog/2026-03-25-website%5Frelease%5F3-0)は、Classicを「Tiny TapeoutやCaravelのような大きなチップに組み込むマクロを作るためのフロー」、Chipを「トップレベルのピンを作らず、パッドリングを生成するフロー」と位置づけています。3.0.17で両フローの工程を比べると、Chipだけにある工程は7つ、Classicだけにある工程は4つでした。 | 区分 | 工程ID | | ------------ | ------------------------------------------------ | | Chipだけ（7） | OpenROAD.PadRing、KLayout.SealRing、KLayout.Filler | | | KLayout.Density、Checker.KLayoutDensity | | | KLayout.Antenna、Checker.KLayoutAntenna | | Classicだけ（4） | OpenROAD.IOPlacement、Odb.CustomIOPlacement | | | Magic.WriteLEF、Odb.CheckDesignAntennaProperties | Classicだけにあるのは、ブロックの外周にI/Oピンを並べる工程と、上位設計から参照するLEFを書き出す工程です。Chipはその代わりに、パッドリング、チップ外周のシールリング、金属密度を満たすフィラーとその検査を行います。どちらを使うかは、提出先のシャトルとテンプレートで決まります。 | 提出先 | PDK | フロー | 出発点 | | -------------------- | ------------------------- | ------- | ------------------------------------- | | Tiny Tapeout | シャトルごとに指定 | Classic | Tiny Tapeoutのテンプレート | | ChipFoundry（Caravel） | sky130 | Classic | caravel\_user\_project | | IHPのシャトル | ihp-sg13g2・ihp-sg13cmos5l | Chip | IHP-GmbHのLibreLaneテンプレート | | wafer.space | gf180mcu | Chip | wafer-space/gf180mcu-project-template | IHPと[wafer.spaceのテンプレート](https://github.com/wafer-space/gf180mcu-project-template)は、3.0の告知が「Chipフローでトップレベルのテープアウトを可能にした」例として挙げたものです。テンプレートはLibreLaneの版やPDKの版を固定しているので、自分で入れた最新版より、テンプレートのNix環境を使う方が提出時の食い違いを避けられます。逆に、Tiny Tapeoutのタイルのような部分設計にChipフローを使うと、不要なパッドリング工程が走るうえ上位へ渡すLEFが出ません。 ## フローの拡張：設定ファイルとPythonによる工程の差し替え OpenLane 1との最大の違いは、フローがPythonのクラスとして公開されている点です。工程（Step）は入力の状態（State）と設定（Config）を受け取って新しい状態を返す単位で、フロー（Flow）はStepの並べ方を決めます。3.0.17に登録済みのフローは、Classic・Chip・VHDLClassic・Optimizing・SynthesisExplorationと、GUIで開くためのOpenInKLayout・OpenInOpenROAD・OpenInMagicの8つです。フロー名の一覧は`librelane --help`の`-f, --flow`の選択肢に出ます（3.0.17に`--list-flows`というオプションはありません）。 ### 設定ファイルのsubstituting\_stepsによる差し替え 工程を足したり外したりするだけなら、Pythonを書かずに設定ファイルの`meta`で指定できます。3.0.17に同梱された例題`hold_eco_demo`は、詳細配線の後にECOバッファを挿入し、もう一度詳細配線を走らせる構成をこう書いています。 ``` meta: flow: Classic substituting_steps: "+OpenROAD.DetailedRouting": "Odb.InsertECOBuffers" "+Odb.InsertECOBuffers": "OpenROAD.DetailedRouting" ``` キーの頭の`+`はその工程の後ろへ、`-`は前へ挿入する指定で、値に`null`を置くと削除になります。3.0.17のClassicにこの差し替えを当てると、工程数は80から82に増えました。ワイルドカードも使え、`["OpenROAD.STAMidPNR*", null]`なら配置配線途中のSTA工程4つがまとめて外れて76工程になります。2つ目の行が1つ目で挿入した`Odb.InsertECOBuffers`を参照できるのは、3.0で置換のたびに工程IDを付け直すようになったためで、2.x系では連鎖した差し替えが失敗していました。 ### PythonのFlowクラスによる差し替え 同じことをPythonで書くなら、サブクラスで`Substitutions`を指定します。次の例はKLayoutのDRCと、その結果を判定するChecker工程を外したフローです。 ``` from librelane.flows import Flow Classic = Flow.factory.get("Classic") class ClassicNoKLayoutDRC(Classic): Substitutions = [ ("KLayout.DRC", None), ("Checker.KLayoutDRC", None), ] print(len(Classic.Steps), len(ClassicNoKLayoutDRC.Steps)) ``` LibreLane 3.0.17で実行すると`80 78`と出力され、2工程が外れたことを確認できます。3.0から`Substitutions`はクラス定義の時点で消費されるようになり、インスタンスごとに差し替える2.x系の書き方は使えません。 独自の判断を挟むフローも、Flowクラスを継承して書けます。組み込みのOptimizingフローがその例で、論理合成を3つの戦略（AREA 0・AREA 2・DELAY 1）で並行して試してセル面積が最小の結果を選び、コア使用率99%で配置を試みて失敗したら40%でやり直します。3.0では独自のファイル形式（DesignFormat）を登録できるようになり、FPGAファブリックを組み立てるFABulousのプラグインや、開発中のテスト容易化設計（DFT）フローDifettoがこの仕組みで作られています。 ## SRAMなどのマクロを組み込む設定 SRAMのように、別途レイアウト済みのブロック（ハードマクロ）を組み込むときは、設定の`MACROS`にマクロ名をキーとして各ファイルを登録します。`gds`と`lef`は必須で、どちらかが空だとエラーになります。タイミング解析に使う`lib`や`spef`は、コーナー名のワイルドカードをキーにした辞書で渡します。 ``` "MACROS": { "aes_example": { "instances": { "mprj": { "location": [10, 20], "orientation": "N" } }, "gds": ["dir::./gds/aes_example.gds.gz"], "lef": ["dir::./lef/aes_example.lef"], "nl": ["dir::./gl/aes_example.v"], "spef": { "min_*": ["dir::./spef/multicorner/aes_example.min.spef.gz"], "nom_*": ["dir::./spef/multicorner/aes_example.nom.spef.gz"], "max_*": ["dir::./spef/multicorner/aes_example.max.spef.gz"] } } } ``` つまずきやすいのはインスタンス名です。`instances`のキーはモジュール名ではなくVerilog上のインスタンス名で、配列なら`spm_inst[0]`のようにエスケープせずに書きます。`location`はマイクロメートル単位の配置座標（省略可）、`orientation`は`N`などの向きです。電源の接続は、Verilogで`USE_POWER_PINS`を使わない場合に`PDN_MACRO_CONNECTIONS`で手動指定します。マクロの周囲に標準セルを置かない余白は`FP_MACRO_HORIZONTAL_HALO`・`FP_MACRO_VERTICAL_HALO`で決めます。 Classicフローは、GDS・LEF・Verilogヘッダー・LIB・SPEFをgzip圧縮したまま指定することにおおむね対応しています。マクロのファイルが大きいリポジトリでは、圧縮して置くとサイズを抑えられます。 ## OpenLane 2の設定をLibreLane 3.0へ移すときの変更点 OpenLane 2.x（PyPIの`openlane`）からの移行では、パッケージとコマンドを`librelane`に、Pythonの`import`を`librelane`に替えます。設定変数の改名は多いものの、3.0.17で確かめると旧名は非推奨の別名として残っており、たとえば`FP_PDN_VPITCH`は`PDN_VPITCH`、`FP_PIN_ORDER_CFG`は`IO_PIN_ORDER_CFG`として読み込まれます。ただし別名が効くのは設定ファイルの中だけで、`librelane --help`は`-c`での上書きには非推奨の旧名を使えないと明記しています。古い手順書の`-c FP_PDN_VPITCH=…`は新しい名前に書き換えてください。名前ではなく挙動が変わった点は次のとおりです。 | 変更（3.0.0） | 影響 | | ------------------------------------------- | -------------------------------- | | HOLD\_VIOLATION\_CORNERSの既定が全コーナー | 一部コーナーのホールド違反でも停止 | | DEDUPLICATE\_CORNERSの既定がFalse | リサイザー工程でのコーナー重複除去が止まり実行時間が延びる | | 詳細配線後のアンテナ修正を既定で有効 | DIODE\_CELLがあれば配線結果が変わる | | PDN\_OBSTRUCTIONSなどをタプルのリストへ | Tcl風の文字列指定は書き直し | | DRT\_MIN\_LAYER・DRT\_MAX\_LAYERを削除 | RT\_MIN\_LAYER・RT\_MAX\_LAYERで指定 | | KLAYOUT\_CONFLICT\_RESOLUTIONの既定がRenameCell | マクロのセル名衝突時の扱いが変わる | | Python 3.10以上が必須 | Nix利用者は影響なし | 移行で最初に引っかかりやすいのはホールド違反の扱いです。2.x系で最後まで通っていた設計が、3.0では一部のコーナーのホールド違反を理由に止まることがあります。判定対象のコーナーを絞って通すより、`summary.rpt`で違反の出たコーナーを特定し、そのコーナーの個別レポート（`checks.rpt`など）で経路を確かめて、修正してから進めるべきです。どうしても従来どおり典型コーナーだけで判定する場合は、[公式の変更履歴](https://github.com/librelane/librelane/blob/3.0.17/Changelog.md)が示すとおり`HOLD_VIOLATION_CORNERS`を`["*tt*"]`に設定します。実行時間が気になる場合は`DEDUPLICATE_CORNERS`を`true`にすれば、2.x系ではリサイザー工程だけで行っていたコーナーの重複除去が、コーナーを扱う工程のうちSTA以外のすべてで行われます（STAは常に全コーナーで走ります）。公式の変更履歴も、多くの場合は有効にして問題ないとしています。 Nixで独自の開発シェルを組んでいた場合は、`createOpenLaneShell`が`pkgs.librelane-shell`の`.override`へ置き換わった点も書き換えが必要です。3.0.1から3.0.17までの更新は工程の不具合修正とツールの差し替えが中心ですが、3.0系の中でも変数の入れ替えはあります。3.0.3で未使用の`SYNTH_MUX_MAP`・`SYNTH_MUX4_MAP`が削除され、多重駆動のネットがLintの警告からエラーに格上げされ（`LINTER_ERROR_ON_MULTIDRIVEN`で無効化）、3.0.9で`KLAYOUT_DRC_OPTIONS`が`KLAYOUT_DRC_DEFINES`に置き換わりました。版を上げる前に、自分の設定が使う変数を変更履歴で検索してください。 ## LibreLaneを使う前に確認したい制約 LibreLaneの公式FAQは、Classicフローを「さらなるシリコン検証待ちのベータ」と位置づけています。公式FAQが挙げるシリコン実績は、Tiny Tapeoutの3.5以降の全シャトルとEfabless社内の複数のテープアウトで、Google MPWのほぼ全設計で使われたOpenLane 1ほどの蓄積はありません。そのうえで、次の条件に当てはまるなら導入を見送るか、別の手段と並行させるのが妥当です。 - **過去にOpenLane 1でテープアウトした設計を同一条件で作り直す**：結果の再現が目的なので、OpenLane 1の当時の版を使います。公式もOpenLane 1を旧設計の再テープアウト用と説明しています。 - **オープンPDK以外の自社PDKで、短期間にテープアウトしたい**：PDKルートにLibreLane用の設定ファイル（`libs.tech/librelane/config.tcl`と標準セルごとの`config.tcl`）を自作する必要があり、公式はIHP Open PDKの設定を複製して改変する方法を勧めています。 - **メモリ8GiB未満の環境で使う**：公式の最小要件を下回ります。規模の大きい設計を扱うなら、推奨の16GiBを確保してから始めてください。 PDKはsky130A（既定・5層メタル）とsky130B（ReRAM層付き）、gf180mcuD（gf180mcu系の既定）が中心で、ihp-sg13g2は3.0でKLayoutのDRC・LVSに対応したものの、公式FAQの比較表ではベータ扱いです。PDKの保存先は`--pdk-root`、環境変数`PDK_ROOT`、ホームの`.ciel`の順に決まります。FPGAで試作してからASICへ進むかを検討している段階なら、[FPGA設計の流れと期間・体制の見積り方](/tech/details/16844/)で工程の違いを先に押さえておくと判断しやすくなります。 ## よくある質問 ### OpenLane 2とLibreLaneは同じものですか？ 同じソフトウェアの系譜です。OpenLane 2の原作者がEfablessの事業停止後にフォークして改称したのがLibreLaneで、最初の版は2.4.0（2025年8月18日）です。3.0.0（2026年3月25日）は改称後2度目のメジャー版で、一部の既定値と変数名が変わっています。 ### PyPIのopenlaneパッケージは今も使えますか？ インストールはできますが、[PyPIのopenlane](https://pypi.org/project/openlane/)の正式版は2025年2月21日公開の2.3.10が最後で、以降の不具合修正やツールの更新は入りません。新しく始めるなら`librelane`を使ってください。 ### OpenLaneとOpenROADは何が違いますか？ OpenROADは配置・配線・タイミング解析などを行う個別のツールで、OpenLane（現LibreLane）はOpenROADにYosys・Magic・KLayout・Netgenなどを組み合わせて、RTLからGDSIIまでを自動で通すフローです。 ### Windowsで動かせますか？ WSL2を使えば動きます。WSL2上でAppImageかNixを使う方法と、DockerでLibreLaneのコンテナを起動する方法があります。Windowsネイティブには対応しておらず、WSL1も対象外です。 ### GDSIIとは何ですか？ 半導体のマスク製造に渡すレイアウトデータの標準形式です。LibreLaneではClassicフローの終盤でMagicとKLayoutがそれぞれGDSIIを書き出し、`final`フォルダに最終版が保存されます。 ## 関連記事 - [FPGAとは？LUTと配線で回路を組む仕組みとCPU・ASIC・CPLDとの違い](/tech/details/9296/) - [FPGA設計の流れ｜7工程の進め方とソフト開発との違い・期間と体制の見積り方](/tech/details/16844/) - [FPGA開発言語の選び方｜Verilog・VHDL・SystemVerilogの違いと判断表](/tech/details/18905/) - [RISC-VとArm・x86の違いを比較｜ライセンス・命令長・OS対応で選ぶ【2026年】](/tech/details/7617/) - [WSLで開発環境を構築する手順｜.wslconfig調整とDocker連携・肥大化の対処](/tech/details/17354/) --- 出典: [OpenLane2とは？後継LibreLane 3.0の導入・使い方と移行手順【2026年11月】]()（株式会社一創）