アサーション検証のすすめ〜パート2 – アサーション再利用（Design and Verification LANDSCAPE　2021-Vol1）

2021/08/16

: 【3/15開催＊10万ページビュー記念特別無償開催＊】ModelSimウェビナー～一連の操作を学ぶ入門編～

Jay. K

「Design and Verification Landscape 2020Vol4 – アサーション検証のすすめ〜パート１」では、アサーション検証のメリットを中心に解説を行なった。特に目視で行われているチェックをアサーションに置き換える事で実現できる検証効率の向上を推奨した。もちろん設計毎に目視チェックの部分に対してアサーションを記述する事になるが、その中には再利用できるアサーションもある。そこで再利用を念頭に置いたアサーションを記述することにより、さらに生産性の高いアサーション検証が行えることになる。本稿ではアサーションの再利用性を高めることに主眼を置いて考察と解説を行う。

アサーション再利用のメリット

近年の設計では全てが新規設計ということは非常に珍しい。設計は基本的なコアを残しつつ、新しいインタフェースの追加、高速メモリへの置き換え、低消費電力版など、過去のデザインを再利用しながら新規設計を行っている。同様にアサーションにおいてもすべてを新規で記述するのではなく、再利用を考慮することは大きな意味がある。それによって単にアサーション記述の重複を避けるだけでなく、実績あるアサーションを活用することができる。

再利用性の高いアサーションには以下のようなメリットが挙げられる

同じ内容のアサーションをスクラッチで記述する必要がない（重複が避けられる）
過去の実績があり、記述の均質化につながる
- 再利用時の記述変更は限定的で、信号名やサイクル数の置き換えなどに限られる
新規設計箇所や仕様変更箇所に注力できる

アサーションのパターン化

パターンとはソフトウエア工学で使用されている手法であり、繰り返し起こる事象の特徴を抽出して形式化し、文書化、モデル化したものを指す。同様の考え方はアサーション記述に対しても有効である。実際の回路動作や構成、構造にも類似性が存在していており、特徴的なパターンを抽出しアサーションの再利用に活かす事が可能である。

アサーション・パターンの文書化

例えば、通信系のアプリケーションで行うべきチェックの１つに、タイムアウトがある。タイムアウトが起こる状況は、ホスト側が転送リクエストを出しているにも限らず、通信相手側のデッドロックなどが原因で指定サイクル内にアクノレッジが返されず、その結果バス占有が発生し、通信パフォーマンスの低下を招いてしまう。あるいは特定の状況下で動作しない可能性もある。その際のタイムアウトをチェックするアサーションについて、その課題や、そのアサーションを作成した動機などを含めて文書化した例を下記に示す。

パターン名	タイムアウト
課題・動機	通信相手側のデッドロックなどが原因で、決められたサイクル内にアクノレッジが返されず、バス占有してしまうような問題の検出
パターン
考察・補足	指定されたタイムアウトが100サイクルであれば、リクエスト発行の次のサイクルから、最大でも99サイクル経過した次のサイクルにはアクノレッジが返されなければいけない。サイクル指定には幅があり、99サイクルよりも早くアクノレッジが返される分には問題ない。

アサーションは通常、プロジェクト単位でアーカイブされるが、文書化し複数プロジェクトで共有することは、組織としての導入を推進する上で効果的である。またアサーション・ファイルも併せて管理しておけば再利用性が高まる。さらにこのようなパターンが少しずつでも増えていくことを考えれば、検索キーワードを列挙、記載することも有効である。またアサーション・パターンの文書をチーム内でレビューし、記述の一貫性を調整し、補足事項を追加し、品質や使い勝手を高めていくことも有効である。

コンポーネント・アサーション

コンポーネント・アサーションとはデザインを構成している比較的大きな論理機能を単位としたアサーションである。考え方はパターンと同じであるが、大きな違いは複数のアサーションで構成される点である。以下のようなFIFOの論理機能を考えた場合、アサーション再利用の単位が大きく、デザイン記述を再利用するのに併せてアサーション記述を再利用することが期待できる。

またコンポーネント・アサーションについても文書化が有効である。文書化する際にはブロック図やポート名、ポートの意味や属性、コンポーネントの概要説明、機能仕様、プロパティ名、アサーション名、アサーション記述などを包含すると良い。ここではそのすべては記載しないが、理解の助けとなる重要な項目について解説する。

FIFOブロック図

入出力データ8ビットのシングルクロックで動作可能なシンプルなFIFOである。
その他の信号はデータ読出し用信号と書込み用信号、そしてFIFOが一杯になった時と空になった時のフラグ信号である。

FIFO動作仕様

◼ rst_nは非同期リセット、アクティブローでFIFOが初期化される
◼ readはアクティブハイで、data_outからそのサイクルに読出しが行われる
◼ writeはアクティブハイで、data_inからそのサイクルに書込みが行われる
◼ 書込み中はdata_inは変化してはならない
◼ FIFO内がいっぱいになるとfullとなり、この状態では書込み禁止（下記例１）
◼ FIFO内が空になるとemptyとなり、この状態では読出し禁止
◼ readとwriteは同時に発生してはならない（下記例２）

このFIFO動作仕様をベースにアサーション記述へと落とし込んでいく。以下に例を２つ示す。

例１　FIFO内がいっぱいになるとfullとなり、この状態では書込み禁止

上記例１では、fullになったサイクルでwriteが発生してはいけないというプロパティp_write_at_fullを定義し、このプロパティを用いてassert文でアサーション化している。full信号がアサートされている状態でwrite信号を監視し、write信号がアサートされていなければプロパティとしてはTRUEを返す。ただしfullがアサートされていない状態であればwrite信号を観測する必要がなく、実はこの状態でもプロパティとしてはTRUEを返す。これはVacuous Successと呼ばれ、「むなしい成功」を意味する。シミュレーションはテストパタンに依存するため、プロパティp_write_at_fullがフェイルしていない状態でも、そもそもfull信号がアサートされていない可能性も疑うべきである。そこで別のプロパティp_fullを定義し、coverによりfull信号が少なくとも一度はアサートされていることを確認している。

例 2　 readとwriteは同時に発生してはならない

例2ではアサーション記述の他、サンプル記述にassume文を使った記述をしている。本例のように関係する信号が入力信号だけの場合にはより効果を発揮する。assume文の動作や結果はassertと同じだが、Formal検証では入力制約として使われる。またシミュレーションでは入力パターンの人為的ミスや、他ブロックからの意図しない入力がされている事を明確に特定する事ができる。

VIP（Verification IP）

大手EDAベンダやIPベンダからは汎用的なインタフェースのVIPがリリースされている。例えばAXIやAHB、PCI Expressといったものである。通常は規格に対するコンプライアンスチェックが可能なテスト環境が提供されている。制約付きランダム検証の環境以外にも、アサーション記述が組込まれているものもある。
特に新しい規格の場合、VIP製品がバグフリーであることを期待するべきではない。VIPにおいてサポート体制が充実しているかどうかは、プロジェクトの成功を大きく左右する。バグ改修され改版されるタイミングが半年先では開発プロジェクトが終わってしまう。ベンダによってはサポートレベルを明確に定義しており、VIPが持つ複数の機能モードごとに、初のユーザ・ケースではサポート体制を厚く整えて対応してくれるところもある。もちろん実績ある場合には通常のサポート体制で充分である。VIPを使用する際には、あらかじめ問い合わせをして確認することをお勧めする。

まとめ

今回はアサーションの再利用について解説した。アサーションをパターン化し文書化することで、プロジェクトチーム内や組織内で共有することができ、再利用性を高めていくことができる。また設計資産として再利用するコンポーネントがある場合には、アサーションも併せてコンポーネント化することによって、より大きな機能単位での再利用性が高まる。このようなアサーションが蓄積されることにより、アサーションは検証資産となり、アサーション検証の精度が高まり、そして検証の労力が低減される。アサーションは個々のエンジニアが個別に導入するものではなく、組織として検証プロセスを成熟させる活動の一環として導入されるべきである。その際に再利用というのは重要なキーワードである。
また最後に触れたように、デザインで汎用的なインタフェースを使用しているのであれば、VIPを利用するのも検証効率を上げるのに有効である。これにはベンダのサポート体制がプロジェクト成功を大きく左右することを念頭において、導入することが重要である。