RTL シミュレーションによる課題に対して注目されているのが、アサーション・ベース検証（ABV）です。

アサーション・ベース検証は、回路内部やインターフェース部に内部信号の振る舞いを予め定義しておき、回路が仕様どおりに動作することを自動的に監視させる検証のことです。回路内部の振る舞いを検証できるので、ホワイト・ボックス検証とも言われています。FIFO のオバーフローやアンダーフロー、ステートマシンの割り込みやリセット、アービトレーションの公平性などの誤動作しやすい箇所や、RTL 内のコメントを入れているような条件をアサーション制約で定義します。

結合テストで誤動作した自分のブロックを必死で解析したら、他の人が作成した前段ブロックのバグが原因だったと言う事を過去に経験したことはないでしょうか。このような無駄な解析作業を避けるために、各ブロックの入力部にアサーション制約を設けて入力信号を自動監視させると便利です。

品質向上と検証工数削減に有効なアサーション・ベース検証の特徴をまとめます。

（１）自動検証で検証漏れを防ぐ

モニターピンによる内部検証と違って、アサーション・ベース検証は自動で監視します。

アサーションで期待動作を記述するため、期待動作と異なる結果が出た場合、シミュレーターがエラーとして表示します。ツールがエラーを出すたため、目視による検証漏れを防ぎ、検証工数を大幅に削減できます。

（２）デバッグ工数の増加

運よく出荷前の実機検証で不具合を発見できても、論理段数や分岐数、クロック数が多い回路でバグを探索するデバッグ作業は大変です。その理由は、不具合現象が見つかったポイント（出力ピン）とその原因となった不具合箇所は時間と場所が異なるのと、論理設計時の信号の流れとデバッグ時の信号解析の流れは逆方向 になるからです。

特に、FPGA の実機検証でバグが見つかると、修正のたびに長時間のコンパイル作業が必要になるので、開発遅延につながります。メイン機能は修正の簡単なシミュレーターで検証し、コーナー・バグやシステムの検証は高速な FPGA を使った実機で検証されることをお勧めします。

（３）内部信号の振る舞いを定義することで検証項目を明確化

検証項目が明確でないと、信号の振る舞いとなるアサーション制約をどこに定義すべきか迷います。アサーション制約を導入する作業は面倒に感じますが、実はこの作業が最も重要です。

（４）不具合箇所の近くで検証するので、バグの探索が速い

デバッグ工数の大半はバグの修正ではなく、バグの探索に費やされます。

論理シミュレーションや実機検証で不具合を発見したら、不具合信号の上流の懸念箇所にアサーション制約による罠を仕掛けて、不具合の原因を早期に特定できます。該当機能へはアサーション機能を設けることを、社内の設計基準に追記します。この作業の繰り返しが社内の設計品質を向上させるためにとても重要です。

アサーション・ベース検証を導入すると検証を意識して設計するので、社内の設計品質が向上するだけでなく、デバッグ工数が大幅に少なくなります。