論理シミュレーションとは、シミュレーションソフトウェアを使用してデジタル回路とハードウェア記述言語の動作を予測することです。[ 1 ] [ 2 ]シミュレーションは、トランジスタレベル、ゲートレベル、レジスタ転送レベル(RTL)、電子システムレベル(ESL)、または動作レベルなど、さまざまなレベルの物理的抽象化で実行できます。
論理シミュレーションは、ハードウェア設計における検証プロセスの一部として使用されることがある。[ 3 ]
シミュレーションは、デザインで使用される言語や記号と同じものを用いて構築されているため、ユーザーにとって馴染みのある外観と操作感を提供できるという利点があります。ユーザーがデザインと直接対話できるため、シミュレーションはデザイナーがデザインに関するフィードバックを得るための自然な方法となります。
設計のデバッグと検証に必要な労力は、設計の成熟度に比例します。つまり、設計の初期段階では、バグや不具合は通常すぐに発見されます。しかし、設計が成熟するにつれて、シミュレーションの実行にはより多くの時間とリソースが必要となり、エラーの発見にも次第に時間がかかるようになります。これは、現代のシステム向けコンポーネントのシミュレーションにおいて特に問題となります。シミュレーションにおいて、1クロックサイクルで状態が変化するコンポーネントは、シミュレーションに複数のクロックサイクルを要するからです。
この問題に対する簡潔なアプローチとしては、代わりにフィールドプログラマブルゲートアレイ(FPGA)上で回路をエミュレートする方法が考えられます。シミュレーションの代替手段として形式検証も検討できますが、形式証明が常に可能または都合が良いとは限りません。
論理シミュレーションを高速化する有望な方法の一つは、分散並列計算を利用することである。[ 4 ]
シミュレーションの徹底度を評価するために、コードカバレッジ[ 5 ]、 機能カバレッジ、有限状態機械(FSM)カバレッジ、その他多くの指標を評価するためのツールが存在する[ 6 ] 。
イベントシミュレーションでは、信号が一箇所から別の場所に伝わるのに必要な遅延時間など、単純なタイミング情報を設計に含めることができます。シミュレーション中は、信号の変化がイベントとして追跡されます。特定の時間に変化が発生すると、一定の遅延後にイベントが発生します。イベントは発生する時間順に並べられ、特定の時間のすべてのイベントが処理されると、シミュレーション時間は次の予定されたイベントの時間まで進みます。イベントシミュレーションの実行速度は、処理されるイベントの数(モデル内のアクティビティの量)に依存します。[ 7 ]
イベントシミュレーションは信号タイミングに関するフィードバックをある程度提供できるものの、静的タイミング解析の代替となるものではない。
サイクルシミュレーションでは、遅延を指定することはできません。サイクル精度モデルが使用され、すべてのゲートが各サイクルで評価されます。そのため、サイクルシミュレーションは、モデルの動作状況に関わらず、一定の速度で実行されます。最適化された実装では、入力が変化していないゲートの評価をスキップすることで、モデルの動作が少ない場合にシミュレーションを高速化できます。イベントシミュレーションと比較すると、サイクルシミュレーションは一般的に高速で、スケーラビリティに優れ、ハードウェアアクセラレーションやエミュレーションに適しています。
しかし、チップ設計のトレンドは、回路内のアクティビティ係数の低減(クロックゲーティングやパワーゲーティングなどの技術により、消費電力の削減を目指してこれらの技術がより一般的に使用されるようになっているため)により、イベントシミュレーションが相対的に性能を向上させていることを示している。このような場合、イベントシミュレーションは必要なイベントのみをシミュレートするため、パフォーマンスはサイクルシミュレーションに比べて不利ではなくなる可能性がある。イベントシミュレーションには、非同期ロジックや不整合クロックなど、サイクルシミュレーションでは扱いにくい設計機能を扱うことができるという柔軟性も利点がある。これらの考慮事項から、ほとんどすべての商用ロジックシミュレータは、主にサイクルベースの技術に依存している場合でも、イベントベースの機能を備えている。[ 8 ]
{{cite conference}}: CS1 maint: 複数の名前: 著者リスト (リンク){{cite conference}}: CS1 maint: 複数の名前: 著者リスト (リンク)