設計検証（DRC・LVS）とは

設計検証とは、ウェーハを流す前に、レイアウトが正しいかを机上で確かめる工程です。 代表的な2つがDRCとLVSで、DRCは「この形は作れるか」を、LVSは「この形は設計した回路そのものか」を確かめます。

定義・解説

論理合成を経て、配置と配線が済むと、チップのレイアウトが出来上がります。層ごとの図形が重なった、巨大な図面です。

この図面には、2種類の間違いが入り得ます。製造の寸法ルールに反する形になっているという間違いと、意図した回路とずれているという間違いです。性質が異なるので、確かめ方も2種類あります。

電子情報通信学会の公開知識ベース『知識の森』は、両者を別の項目として書き分けています。

DRCについては、入力されたマスクパターンが設計ルールに違反するかどうかを検証するとしています。具体的には、マスクパターンの情報を図形データに変換し、図形演算によって、最小幅、最小間隔などのテクノロジごとに設定された設計ルールの条件に合うかをチェックすると書いています。

LVSについては、マスクパターンとネットリストを入力とし、その両者において同じ素子間の結線が実現できているかを検証するとしています。手順としては、マスクパターンの情報からトランジスタ領域と等電位の結線関係を抽出し、ネットリストもトランジスタレベルの結線情報に展開して、両者を比較することにより検証を行う、という流れが示されています。

入力の違いが、性質の違いを表しています

この2つの記述を比べると、入力の数が異なることに気づきます。

DRC ── 入力はマスクパターンだけです。図形が寸法のきまりを守っているかを確かめます
LVS ── 入力はマスクパターンとネットリストの2つです。図面から結線を復元し、回路図側の結線と比べます

DRCは、レイアウト1つだけで判定条件に当てはめられます。形そのものを、決められた寸法と照らすだけだからです。LVSは比べる相手が要ります。正解にあたる回路の情報があって初めて、一致しているかを言えるからです。

判定条件の中身も具体的です。国内EDAベンダのジーダットは、製品ページでDRCの検証機能としてSPACE、WIDTH、ENC、INC、OVERLAP、各種SELECTを挙げています。間隔、幅、囲み、内包、重なりであり、図形どうしの位置関係を機械的に測って合否を返していることが分かります。同ページは、LVS側の入力についても、Spice/CDLやAsca-Advancedの回路データから直接結線情報を読み込むとしています。

ベンダの分類でも、この2つは別の枠に入っています。シーメンスEDAジャパンは公式ページで、DRCの製品を物理検証として位置づけ、LVS（レイアウト対回路図）検証はCalibre回路検証ツールスイートに含めています。物理を確かめる側と、回路を確かめる側という切り分けです。

2つの検査は、別のものを確かめています

DRCはレイアウトだけを見て寸法のきまりと照らします。LVSはレイアウトから結線を復元し、回路図側と照らし合わせます。入力の数の違いが、性質の違いを表しています。

作る前に確かめる理由

半導体でこの工程が重いのは、やり直しの費用が大きいからです。

フォトマスクを作り、ウェーハを流し、できてから間違いが見つかれば、そこまでの工程がまるごと無駄になります。だから流す前に、机上で確かめきる必要があります。

シーメンスEDAジャパンは、この最終検証をサインオフと呼び、自社のソリューションが設計から製造までを迅速に進められるように、すべてのサインオフ要件に対応するとしています。要件と呼ばれているとおり、これは通過して初めて次へ進める関門です。

途中で何度も回すか、製造へ渡す直前に一度回すか

使い方には二層あります。

日本ケイデンス・デザイン・システムズの日本語データシートは、従来のDRC使用モデルではレイアウト（すなわちGDSII）を出力してからDRC実行を起動するとしています。一区切りついてからまとめて回す形です。この進め方だと、指摘が出るころには原因になった編集から時間が経っており、どこで入り込んだ間違いかをたどる作業が増えます。

これに対し、編集のたびに回す使い方も示されています。同データシートは、インタラクティブモードでは同社製品がすべての編集に対してリアルタイムにサインオフ・ルールチェック（DRC）を提供するとし、レイアウト設計者は各編集を終えた時点で、サインオフレベルのDRCデッキを使ってDRCを実行できるとしています。

ジーダットの同製品ページも、設計途中で検証と修正作業が自在に実行でき、サインオフツールによる最終検証の負荷を大幅に軽減するとしており、同じ二層構造を示しています。手前で細かく潰しておき、最後に全体で通す順序です。

計算量が、そのまま日程になります

この検査は、机上作業でありながら計算資源を大量に使います。

理由も公開されています。電子情報通信学会の同知識ベースは、テクノロジの微細化とともに、設計ルールはテクノロジが進むごとに複雑化してきており、計算時間の増加が問題視され、計算を分散させるなどの高速化が実現されているとしています。

規模感も公開されています。以下は、日本ケイデンス・デザイン・システムズが自社製品の資料として示している値です。同社の別のデータシートは、現在のフルチップDRCターンアラウンドタイムが、通常100〜200CPUで数日掛かっているとしています。そして自社製品について、最大960のCPUでほぼリニアなスケーラビリティを実証し、サインオフの計算時間を短縮すると述べています。同データシートには、成熟したノードで少なくとも15％、先進的なノードで50％以上の生産性向上、数百のCPUで最大10倍といった数値も並びます。

それでも、机上のチェックのために数百台の計算機を数日回すという水準であることは、複数の記述から共通して読み取れます。

手前で細かく、最後に全体で

編集のたびに手前で潰し、最後に全体を通します。世代が進むほどルールが複雑になり、確かめる作業そのものが長くなります。

見つけることより、直すことのほうが重い

検査を回すこと自体より、出てきた指摘に対処するほうが時間を食います。

日本ケイデンス・デザイン・システムズのデータシートは、冒頭で、設計者はデザインルールチェック（DRC）とレイアウト対スケマティック（LVS）のデバッグに多くの時間を費やすとしています。そして、とくにLVSについて、複雑なLVSミスマッチの原因を特定することは非常に時間がかかるとも述べています。

理由は、LVSの出力の性質にあります。一致しなかったという結果は分かっても、どこがどうずれてそうなったのかを知るには、図面から復元した結線と回路図側の結線を突き合わせ、その差の原因をたどる作業が要ります。

同データシートは、その帰結も書いています。見積りを超えたデバッグ時間は、スケジュールの遅れを引き起こし、製品収益の損失につながるとしています。

ルールを定めるのは、工場の側

最後に、この検査が誰の基準で行われるかを確かめます。

DRCが照らす設計ルールも、LVSが使う規則ファイルも、ファウンドリの側が定めます。PDKの記事で見たとおり、これらはファウンドリから渡される一式の中に入っています。

シーメンスEDAジャパンも、ファウンドリ、ICデザインハウス、業界標準化団体との緊密な連携により、Calibreが最先端ICに求められる要件を満たすとしており、道具の側が製造側の基準に合わせにいく構図が読み取れます。

作れるかどうかを定めるのは工場であり、設計側はその基準に照らして自分の図面を確かめます。設計検証は、水平分業における設計と製造の接点そのものです。

よくある質問（FAQ）

DRCとは何ですか？

電子情報通信学会の公開知識ベースは、DRCでは入力されたマスクパターンが設計ルールに違反するかどうかを検証するとし、マスクパターンを図形データへ変換したうえで図形演算を行い、最小幅、最小間隔などテクノロジごとに設定された設計ルールの条件に合うかをチェックすると書いています。

LVSとは何ですか？

同知識ベースは、LVSではマスクパターンとネットリストを入力とし、その両者において同じ素子間の結線が実現できているかを検証するとしています。

2つの差はどこにありますか？

別のものです。同知識ベースでは、DRCの入力がマスクパターンのみであるのに対し、LVSの入力はマスクパターンとネットリストの2つと書き分けられています。シーメンスEDAジャパンの分類でも、DRCは物理検証、LVSは回路検証という別のカテゴリへ振り分けられています。

DRCを通れば安心ですか？

DRCが確かめているのは、形が製造ルールを満たすかどうかだけです。設計した回路と一致しているかはLVSの担当で、両方を通って初めて、作れて、かつ意図どおりということになります。

どのくらい時間がかかるのですか？

日本ケイデンス・デザイン・システムズの日本語データシートは、現在のフルチップDRCターンアラウンドタイムが通常100〜200CPUで数日掛かっているとしています。これは同社が自社製品の資料の中で示した値です。

なぜそんなに重いのですか？

電子情報通信学会の同知識ベースは、テクノロジの微細化とともに設計ルールがテクノロジが進むごとに複雑化してきており、計算時間の増加が問題視され、計算を分散させるなどの高速化が実現されているとしています。

ルールは誰が定めるのですか？

製造側です。DRCやLVSの規則ファイルはPDKの一部としてファウンドリから提供されます。シーメンスEDAジャパンも、ファウンドリ、ICデザインハウス、業界標準化団体との緊密な連携により要件を満たすと述べています。

比較・違いを学ぶ

PDKとは ── 検証の規則ファイルが入っている一式
EDAとは ── これらの検査を担う道具の総称

出典

この記事の事実は、誰でも読める公開資料を根拠とし、各URLの到達可否をこちらで実測しています。したがって、リンク先が移動または消滅した場合は、その旨をこのページへ反映します。

電子情報通信学会『知識の森』10群1編3章「集積回路設計」公開PDF（2026年8月30日にリンク生存を実測、200、application/pdf）── DRCでは入力されたマスクパターンが設計ルールに違反するかどうかを検証すること、マスクパターンの情報が図形データに変換され図形演算により最小幅・最小間隔などテクノロジごとに設定された設計ルールの条件に合うかをチェックすること、LVSではマスクパターンとネットリストを入力としその両者において同じ素子間の結線が実現できているかを検証すること、マスクパターンからトランジスタ領域と等電位の結線関係を抽出しネットリストもトランジスタレベルの結線情報に展開して両者を比較すること、テクノロジの微細化とともに設計ルールが複雑化し計算時間の増加が問題視され計算の分散などによる高速化が実現されていること
日本ケイデンス・デザイン・システムズ日本語データシート「Cadence Physical Verification System」公開PDF（2026年8月30日にリンク生存を実測、200、application/pdf）── DRCの日本語表記がデザインルールチェック、LVSがレイアウト対スケマティックであること、設計者がDRCとLVSのデバッグに多くの時間を費やすこと、従来のDRC使用モデルではレイアウト（GDSII）を出力してからDRC実行を起動すること、インタラクティブモードではすべての編集に対してリアルタイムにサインオフ・ルールチェックを提供すること、各編集を完了するときにサインオフレベルのDRCデッキを使用してDRCを実行できること、複雑なLVSミスマッチの原因を特定することが非常に時間がかかること、見積りを超えたデバッグ時間がスケジュールの遅れを引き起こし製品収益の損失につながること
日本ケイデンス・デザイン・システムズ日本語データシート「Pegasus Verification System」公開PDF（2026年8月30日にリンク生存を実測、200、application/pdf）── 先端ノードで複雑なDRCルールが劇的に増加していること、現在のフルチップDRCターンアラウンドタイムが通常100〜200CPUで数日掛かっていること、同社製品が最大960のCPUでほぼリニアなスケーラビリティを実証したとしていること、成熟したノードで少なくとも15％・先進的なノードで50％以上の生産性向上および数百のCPUで最大10倍という性能向上を主張していること（いずれも同社が自社製品の資料として示す値であり、出どころは同社1社です）
シーメンスEDAジャパン「Calibre設計ソリューション」公式ページ（2026年8月30日にリンク生存を実測、200）── LVSの日本語表記がレイアウト対回路図であること、同社の分類でLVSが回路検証ツールスイートに含まれること、Calibre設計ソリューションがすべてのサインオフ要件に対応するとしていること、ファウンドリ・ICデザインハウス・業界標準化団体との緊密な連携により最先端ICに求められる要件を満たすとしていること
ジーダット「SX-Meister iDRC / iLVS」公式製品ページ（2026年8月30日にリンク生存を実測、200）── DRCの検証機能としてSPACE、WIDTH、ENC、INC、OVERLAP、各種SELECTが挙げられていること、レイアウト設計中に検証可能なリアルタイムDRC機能があること、Spice/CDLなどの回路データより直接結線情報を読み込みLVS検証が可能であること、設計途中で検証と修正作業が実行でき、サインオフツールによる最終検証の負荷を軽減すること