メンター ModelSim DE は、検証に便利な機能を豊富に備えています。今回は、その検証機能の1つである アサーション・ベース検証 についてご紹介します。

デバッグ期間短縮と品質向上のために、ModelSim® DE に搭載された検証機能

 

【1】アサーション検証とは

【2】コードカバレッジとは

【3】波形比較とは

【4】エンハンスド・データフローとは

 
回路規模や設計の複雑さの増大により、FPGA 開発業務の中心は 設計 から 検証 に移っています。アサーション・ベース検証は、既に ASIC で多く利用されている検証手法で、FPGA 開発でもお勧めする検証手法の1つです。

従来のシミュレーション方法

 

図1.従来のシミュレーション方法

 

図1 は従来のシミュレーションによる検証手法です。対象となる回路の 入力ピンにテスト信号 を与え、出力ピンのふるまい で動作を確認します。回路内部の動作が見えないので、ブラックボックス検証 と言われています。

<< 従来のシミュレーション手法における問題 >>

回路規模が大きくなると、従来のシミュレーションによる検証ではいくつかの問題が発生します。

(1) 内部バグを見落とす可能性が高い!

論理段数が深くなったり クロック系統が複雑になると、信号経路が複雑になります。信号経路が複雑になると、回路内部で発生した誤信号が後段ブロックでマスクされて、誤信号が出力ピンまで伝播しないことがあります。出力ピンに誤信号が現れないと、論理シミュレーションでバグを見つけるのは困難です。

出力ピンの波形で検証するので、内部バグを発生できるテストベンチ(各ブロック検証用のテストベンチ)だけでなく、その信号を出力ピンまで伝播させるテストベンチが必要になります。

このような検証手法で開発した製品は、市場に出てから様々な信号の組み合せを試されると検証時には見つからなかったバグが発覚して問題になることがあります。

(2) デバッグ工数が増える!

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

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

アサーション・ベース検証(ABV)

それでは、アサーション・ベース検証では どうでしょう。

図2.アサーション・ベース検証


図2 はアサーション・ベース検証(ABV)による検証手法です。アサーション・ベース検証は、回路内部や I/F 部に内部信号のふるまいを定義して、回路が仕様通りに動作することを 自動的に監視 させる検証のことです。回路内部のふるまいを検証できるので、ホワイトボックス検証 と言われています。

FIFO のオーバーフローやアンダーフロー、ステートマシンの割り込みやリセット、アービトレーションの公平性などの誤動作しやすい箇所や、RTL 内にコメントを入れているような条件をアサーション制約で定義します。

皆さんは、結合テストで誤動作した自分のブロックを必死で解析したら、他の人が作成した前段ブロックのバグが原因だったことはありませんか?

このような無駄な解析作業を避けるために、各ブロックの入力部にアサーション制約を設けて入力信号を 自動監視 させると便利です。

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

(1) 自動検証で検証モレを防ぐ

・モニターピンによる内部検証と違ってアサーション・ベース検証は自動で監視します。
・目視による検証モレを防ぎ、検証工数を大幅に削減します。

(2) 出力ピンまで伝播しない内部バグを早期に発見できる

・内部バグの近くで監視するので、誤信号が出力ピンまで伝播しなくても内部バグを発見できます。

(3) 内部信号のふるまいを定義することで検証項目を明確化

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

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

(4) 不具合箇所の近くで検証するのでバグの探索が速い

・デバッグ工数の大半はバグの修正ではなく、バグの探索に費やされます。
論理シミュレーションや実機検証で不具合を発見したら、不具合信号の上流の懸念箇所にアサーション制約による をしかけて不具合の原因を早期に特定できます。

そして該当機能へはアサーション制約を設ける ことを社内の設計基準に追記します。

この作業の繰り返しが社内の設計品質を向上させるためにとても重要です。

<< 制約の書式は非常にシンプル >>

アサーション・ベース検証を行うには、内部動作のふるまい(機能の仕様)を定義する必要があります。アサーション制約の定義は従来の Verilog/VHDL でも使えますが SystemVerilog (SVA) や PSL (PropertySpecification Language) の専用言語を使うと記述をシンプルにできます。

例えば、「毎回 clk 信号の立ち上がりの度に req 信号がアクティブになったら、そのサイクルの 1サイクル後から3サイクル後に ack 信号が立ち上がる」というふるまいをSystemVerilog で記述すると下記になります。

property req_ack;
@(posedge clk) $rose(req) |-> ##[1:3] $rose(ack);
endpropertyas_req_ack:
assert property(req_ack);


<< アサーション・エラーの解析 >>

シンプルな書式は制約を作成する際には便利ですね、でもデバッグ時ではどのシンプルな記述のどの部分がエラーになっているのか分からないので不便です。そこで、ModelSim DE にはバグの解析に便利な機能(ATV)がついています。

この ATV はシンプルな制約を分割してデバッグする機能です。下図のように1行で定義した部分の何処にエラーがあるのか簡単に分かります。

 図3. ATVの例


上記内容についてのお問い合わせやご質問がございましたら、お気軽に弊社までご連絡ください。

 ModelSim の詳細はコチラ 

 

【1】アサーション検証とは

【2】コードカバレッジとは

【3】波形比較とは

【4】エンハンスド・データフローとは