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で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へ移り、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（2025年8月18日）に引用された開発者の説明では、OpenLane 2は2024年2月にソフトローンチし、厳しいタイミング要件のシリコンで検証を終えた数日後に、Efablessが資金難で事業を停止しました。商標や名前空間をEfablessから引き継ぐのが難しく、OpenLane 1とは中身も大きく異なっていたため、プロジェクトはLibreLaneへ改称され、FOSSi Foundationの下で開発が続いています。

版の流れは、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は、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でも読み込めると公式の移行ガイドは説明しています。ただしTclの設定は扱いが不安定なのでJSONへの書き直しが推奨され、Tclで書いた対話スクリプトは動きません。移行ガイドは、途中で失敗しても前の工程までのメトリクスとレポートが残る点と、工程を指定して再実行できる点を移行の利点に挙げています。

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公式FAQの比較表をもとに、設定の形式とツールの入手方法を補ったものです。研究用の先端ノード（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でのインストール

Nixを公式インストーラーで入れる際に、FOSSi Foundationのバイナリキャッシュとnix-command・flakesを有効にします。aptで入るNixは古いことが多いため使わないよう公式のインストール手順が警告しています。初回の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で開発環境を構築する手順が参考になります。

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のリリースに付いた一覧の主な行は次のとおりで、ツール環境はNixOS 25.11を土台にしています。

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の違いと判断表で整理しています。

実行タグと設定の一時上書き

自分の設計は設定ファイルを直接渡して実行します。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系の検査工程を除くと、主な流れは次のとおりです。

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のリリース告知は、Classicを「Tiny TapeoutやCaravelのような大きなチップに組み込むマクロを作るためのフロー」、Chipを「トップレベルのピンを作らず、パッドリングを生成するフロー」と位置づけています。3.0.17で両フローの工程を比べると、Chipだけにある工程は7つ、Classicだけにある工程は4つでした。

Classicだけにあるのは、ブロックの外周にI/Oピンを並べる工程と、上位設計から参照するLEFを書き出す工程です。Chipはその代わりに、パッドリング、チップ外周のシールリング、金属密度を満たすフィラーとその検査を行います。どちらを使うかは、提出先のシャトルとテンプレートで決まります。

IHPとwafer.spaceのテンプレートは、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=…は新しい名前に書き換えてください。名前ではなく挙動が変わった点は次のとおりです。

移行で最初に引っかかりやすいのはホールド違反の扱いです。2.x系で最後まで通っていた設計が、3.0では一部のコーナーのホールド違反を理由に止まることがあります。判定対象のコーナーを絞って通すより、summary.rptで違反の出たコーナーを特定し、そのコーナーの個別レポート（checks.rptなど）で経路を確かめて、修正してから進めるべきです。どうしても従来どおり典型コーナーだけで判定する場合は、公式の変更履歴が示すとおり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設計の流れと期間・体制の見積り方で工程の違いを先に押さえておくと判断しやすくなります。

よくある質問

OpenLane 2とLibreLaneは同じものですか？

同じソフトウェアの系譜です。OpenLane 2の原作者がEfablessの事業停止後にフォークして改称したのがLibreLaneで、最初の版は2.4.0（2025年8月18日）です。3.0.0（2026年3月25日）は改称後2度目のメジャー版で、一部の既定値と変数名が変わっています。

PyPIのopenlaneパッケージは今も使えますか？

インストールはできますが、PyPIの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との違い
• FPGA設計の流れ｜7工程の進め方とソフト開発との違い・期間と体制の見積り方
• FPGA開発言語の選び方｜Verilog・VHDL・SystemVerilogの違いと判断表
• RISC-VとArm・x86の違いを比較｜ライセンス・命令長・OS対応で選ぶ【2026年】
• WSLで開発環境を構築する手順｜.wslconfig調整とDocker連携・肥大化の対処