改訂版EDA用語辞典とは・著者一覧

 論理シミュレーションは,論理回路の機能やタイミングを検証するための技術である。論理シミュレーションを実行するEDAツールを論理シミュレータと呼ぶ。論理シミュレータを使うには,次の情報を入力する(図1)。検証対象の論理回路の情報(設計データ),検証対象回路への入力信号データ(シミュレーション・パターン),シミュレーションの制御情報(シミュレーションの終了時刻やモニターする信号名など)である。

図1 論理シミュレータの入出力
出典はJEITA。

 これらの入力情報から,論理シミュレータは,対象回路の応答信号を出力する。この応答信号と,設計時に想定していた応答信号(期待値)とを比較したり,応答信号を波形でグラフィカルに表示して確認することで,期待した動作をする論理回路が設計できているかどうかを判定できる。

複数の設計抽象度で使われる

 論理シミュレータは,複数の設計レベル(抽象度)で使われる。すなわち,(1)システム・レベル(2)RTL(register transfer level)(3)ゲート・レベルである(図2)。

 (1)のシステム・レベルの設計では,まず,システムの機能仕様を解釈して,C言語やC++などのプログラミング言語を使ってシステムの動作をモデリングする。その後,論理シミュレータを使って,システムの機能仕様の正しさを確認したり,システム全体をハードウェアとソフトウェアに分割した際の動作や概略性能を確認する。なお,文字や数字など任意のデータ・タイプを使って高位で機能を確認する論理シミュレータを,特に,システム・レベル・シミュレータと呼ぶこともある。

図2 論理設計の抽象レベル
出典はJEITA。

 (2)のRTLや(3)のゲート・レベルでは,ハードウェア設計を行う。RTL,ゲート・レベルでモデリングする際,データ・タイプは「0」/「1」/「X」などの論理値になる。

 (2)のRTLでは,ハードウェアの機能を,レジスタおよび,レジスタ間の論理演算でモデリングする。論理演算は,論理演算式と条件分岐やループなどの制御文を使って表す。RTL設計の検証は,クロック・サイクルごとの論理動作をシミュレーションすることで,実行する。RTLで使う論理シミュレータをRTLシミュレータと呼ぶこともある。

 (3)のゲート・レベルでは,ANDやNAND,OR,NOR,NOTなどの論理演算素子と,フリップフロップ(D,RS,JK,MS)などの順序演算素子の組み合わせで,論理回路をモデリングする。そして,回路の論理動作だけでなく,各素子や配線で生じる遅延も考慮した論理シミュレーションを行い,論理動作と共にタイミングも検証する。このような論理素子レベルの論理シミュレータを特にゲートレベル・シミュレータと呼ぶことがある。

 市販の論理シミュレータは,上記の三つのレベルをすべてカバーしたり,二つをカバーしている場合,どれか一つだけ扱える製品など,さまざまなものがある。なお,RTLとゲート・レベルでは,「0」/「1」の論理値を基本に処理しているので,両レベル間のインタフェースは容易に取れる。しかし,システム・レベルでは,抽象度の高いデータ・モデルを使うため,「0」/「1」の論理値との間でデータ変換する仕組みが必要になる。

主に三つの用途

 ここまでは設計の抽象度という視点で論理シミュレータの役割を見てきたが,次に用途という視点で論じる。論理シミュレータには,主に三つの用途がある。すなわち,(a)機能検証(b)タイミング検証(c)テスト・パターンの検証である。以下では,それぞれの用途やそこでの課題を見ていく。

 (a)の機能検証では,検証対象の論理回路が,期待した論理機能を持っているか(あるいは,期待通りの論理動作をするか)どうかを確認する。外部入力数と内部レジスタ数の合計がnの論理回路があり,論理動作として「0」または「1」の2値を取る場合,すべての論理動作を網羅するには2nのシミュレーション・パターンが必要となる。これでは,現実的な時間でシミュレーションが終了しない。

 そこで,実際に論理回路が使われる状況(ユース・ケース)を想定して,そのケースに対応したシミュレーション・パターンだけで論理シミュレーションを実施する。しかし,LSIの大規模化と機能の複合化により,ユース・ケースが急増していることから,シミュレーション時間の短縮のために,さまざまな高速化の手法が開発され(後述),またハードウェアを利用したエミューレション技術やアクセラレーション技術が適用される場合もある。

 また,検証品質を確保するためには網羅的にユース・ケースを用意することが必要であるが,ユース・ケースのシミュレーションだけでは検証漏れが発生することが多い。このため,検証のカバレッジを定量化する仕組み(検証カバレッジ)や,検証できたかどうかを確認するアサーションの技術(アサーション・ベース検証),シミュレーション・パターンを効率的に作成するための技術などが,新たな検証技術として提案されている。

さまざまな高速化手法がある

 次に論理シミュレータの高速化について説明する。論理シミュレータは,論理モデル(論理演算素子,レジスタなど)と,論理モデル間を接続する配線(ワイヤー,バスなど)を,論理信号(0,1,X,Zなど)が伝搬することを計算機上で模擬するソフトウェアである。信号の変化をイベントと呼び,ある論理モデルAのイベントが配線で接続されている次段の論理モデルBの入力端子に伝わる(図3)。

図3 イベント・ドリブン方式の論理エミュレータの動作例
出典はJEITA。

 入力端子に信号変化があった論理モデルBは,その入力信号値に基づいた論理演算をして,その結果の信号値を出力する。この信号値が更新される前の値から変化(イベント発生)した場合は,配線を通して,その後段に接続している論理モデルにイベントを伝搬する,という処理を繰り返す。

 イベントの伝搬と論理モデル内の論理演算が論理シミュレータの主たる処理で,論理演算はイベントが引き起こすので,イベント数を最小化することがシミュレーションの高速化につながる。

 RTLレベル以上では,通常,遅延時間を扱わないため,クロック・サイクルごとにイベントを処理することで,遅延時間を扱うゲート・レベルに比べて大幅な高速化が可能である。

 また,論理モデルや信号モデルの抽象度を上げることで,さらに高速化が可能である。システム・レベル・シミュレーションでは,大きな機能処理を一つの論理モデルとしたり,信号を「0」/「1」ではなくトランザクションと呼ばれるひとかたまりのデータとして処理したりすること(トランザクション・レベル・モデリング)でも,シミュレーションの高速化が可能である。

 論理合成技術を利用して,設計した回路で,信号のモニター指定がない部分を論理縮退することで,配線や論理モデルを減らすことや,バス信号をビットごとではなく一つの信号として扱うことで,イベント伝搬処理を削減するなどの,高速化手法を採用している論理シミュレータもある。

 さらに,高速化の実現に,専用のハードウェアを利用する方法もある。論理エミュレータやハードウェア・アクセラレータが利用されている。

レイアウト結果を反映してタイミングの精度を向上

 次に(b)の用途のタイミング検証について説明する(図4)。論理シミュレータを使ってゲート・レベルの機能検証やタイミング検証が行えるように,半導体メーカーやシリコン・ファウンドリは,論理LSIの設計単位(セルやマクロセル)の情報をライブラリとして用意している。ライブラリには,セルやマクロセルの論理機能と,遅延の計算式(方法)が定義されている。

図4 タイミング検証
出典はJEITA。

 遅延の計算式は,二つの部分からなる。セルやマクロセルそのものの遅延(固有遅延)と,配線の遅延である。このうち,固有遅延は,製造プロセスを選べば一意に決まるが,配線遅延はレイアウト(配置配線)を行って,配線経路が決定するまで正確には分からない。

 このため,レイアウト前は過去の設計事例から割り出した「見込み配線長」を使って遅延計算する。レイアウト後には,配置情報と配線経路の情報を基に遅延時間を求める。その値を論理シミュレータに入力することで,正確な遅延時間に基づいた論理シミュレーションが実行できる。レイアウト後の遅延データを論理シミュレータに戻すことを「バック・アノテーション」と呼ぶ。その際,SDF(Standard Delay Format)と呼ぶ形式で,遅延データを表すのが一般的である。

 論理シミュレーションですべてのタイミングを検証するには,クリティカルなタイミングで信号変化をするテスト・データ(シミュレーション・パターン)を,タイミング検証が必要な個所すべてに対して用意する必要がある。しかし,これは現実的でない。

 そこで,通常は,網羅的なタイミング検証を,シミュレーション・パターンが不要なSTA(static timing analysis)ツールを使って実施する。STAでは,前段のレジスタ出力から次段のレジスタのデータ入力までデータ信号が到達する遅延時間をレジスタ間の組み合わせ論理について計算して求めて,クロックとデータ信号の相対関係からタイミング制約違反(タイミング・バイオレーション)を起こすかどうかをチェックしている。

テスト・パターンの有効性をチェック

 最後に(c)のテスト・パターンの検証の用途について説明する。設計した回路がLSIやFPGAなどに実装されたときには,そのチップが設計どおりに製造されていることをテストするためのテスト・パターンが必要である。半導体デバイスは,内部の信号状態を外部から直接観測することができないため,故障の存在が外部出力信号の差異として観測できる必要がある。

 テスト・パターンは,製造上の不良を回路の故障としてモデル化して論理シミュレーションを行いながら作っていく。入力したテスト・パターンが,故障した回路と正常な回路とで異なる出力信号を出せば,そのテスト・パターンは有効と分かる(図5)。このようにテスト・パターンをチェックする論理シミュレーションを,特に故障シミュレーションと呼ぶ。

図5 故障シミュレーション
出典はJEITA。

 ただし現在では,スキャン・テストという設計回路内にテスト用回路を埋め込むテスト容易化技術を利用しながら,テスト・パターン自動生成ツール(ATPG:automatic test pattern generator)で自動的にテスト・パターンを生成するのが一般的である。