News and Views 2015 Winter / Vol. 12: 上流設計&組込み

アサーションやカバレッジの系統立てられた記述前準備

はじめに

SystemVerilogがIEEE 1800として標準化されたのは2005年11月8日、今年で10年目を迎えることになります。アサーションや機能カバレッジなどは記述のテンプレート化をしたり、外部の検証コンサルティングなどからの支援を受けたりすることにより、設計者や検証エンジニアが参考にできる記述も増えてきています。

仕様書からいきなりRTL記述をしないのと同じように、アサーションやカバレッジでもいきなり記述を始めるのではなく、記述しやすくするための準備があると、後に再利用する際にもドキュメントとして残るため、価値が上がります。

ここではアサーションを例に、その記述プロセスを今一度確認してみたいと思います。

仕様プロパティ記述のプロセス

仕様プロパティを記述するための流れは以下のようになります。

  • 概要を自然言語で記述する
    • バスやインタフェースのキーとなる特徴を簡潔に記述する
    • 詳細は省いても良いが、主な機能や特性は記載する
  • インタフェースを定義する
    • フォーマルなプロパティを作成する際に参照する信号を一覧表にまとめる
    • レビューの際に要求仕様の完全性を測定するチェックリストとする
  • 要求項目について自然言語で表現する
    • バスやインタフェースについての仕様を自然言語で記述する
    • プロパティとマッピングするためにユニークなラベルを与える
  • チェックリストの要求仕様をアサーションに落とす
    • 自然言語で記載された要求仕様をアサーションにする
    • 理解しやすくするために他のモデリング記述を用いてもよい

ここではAPB(Advanced Peripheral Bus)を例に、バスインタフェースに関するアサーション記述までのプロセスを系統立てる手段について見てみます。上記のプロセスに従って説明します。

図1. バスインタフェースとその構成信号の定義図1. バスインタフェースとその構成信号の定義
図2. タイミングチャート(左: ライトオペレーション/右: リードオペレーション)図2. タイミングチャート(左: ライトオペレーション/右: リードオペレーション)
図3. バスオペレーションをコンセプト上のステートマシンとして表現図3. バスオペレーションをコンセプト上のステートマシンとして表現

APBインタフェースの仕様

図1は、ここで扱うバスインタフェースについて、マスターとスレーブの関係、および各インタフェースを構成する信号を定義したものです。また図2は、ライトオペレーションおよびリードオペレーションのタイミングチャートです。各信号の関係を時相的に表現するのに加え、各クロックサイクルでの信号の値の組合せによってどのような意味合いがあるのかを「state」として付け加えています。

このstateの値としてINACTIVE、START、ACTIVEなどが記載されていますが、これは実際の信号名ではなく、あくまでもバスインタフェースがどのような状態にあるかを示したステートです。このように分かりやすい名称をつけるのが良いでしょう。同時に、このステートは遷移することから、バスのオペレーションをコンセプト上のステートマシン化することが可能になります。それが図3です。このコンセプト上のステートマシンについて説明します。

  • brst_n == 0 でINACTIVEステートに初期化される
  • 転送を開始するにはSTARTステートに移動する
    • スレーブが選択される
    • STARTは1サイクルのみ、次のクロックエッジでACTIVEに遷移する
  • 実際の転送はACTIVEステートで行われる
    • benがアサートされる
    • ACTIVEは1サイクルのみ。続けて転送する場合は、スレーブが選択されたままのSTARTに戻る
    • 何も転送するデータがない場合にはスレーブが開放されINACTIVEに戻る
  • その他
    • START → ACTIVEへの遷移中、baddr、bwriteはステーブルでないといけない

要求仕様を自然言語で表現

バスオペレーションのプロパティを記述する前に、自然言語で抽出して表現します。この段階でプロパティ名を決めてしまいます。

バスの適切なステートとしては以下が挙げられます。

  • p_state_reset_inactive
    リセット後の初期ステートはINACTIVEステートとなる
  • p_valid_inactive_transition
    INACTIVEステートの後はINACTIVEが継続するかSTARTステートとなる
  • p_valid_start_transition
    STARTステートの後はACTIVEステートとなる
  • p_valid_active_transition
    ACTIVEステートの後はSTARTステートかINACTIVEステートとなる
  • p_no_error_state
    バスステートはERRORであってはならない

次にスレーブの適切なセレクトに関するプロパティについて列挙します。

  • p_bsel_mutex
    ステーブ選択信号は互いに排他的でなくてはならない
  • p_bselX_stable
    スレーブ選択信号はSTARTステートからACTIVEステートへの遷移において、ステーブルでなくてはならない

図4. コンセプト上のステートマシンに合わせて抽象化を行う図4. コンセプト上のステートマシンに合わせて抽象化を行う

続いてバスのアドレスについてのプロパティです。

  • p_baddr_stable
    アドレスはSTARTステートからACTIVEステートへの遷移中はステーブルでなくてはならない

バスのライト制御についてのプロパティです。

  • p_bwrite_stable
    bwrite制御信号はSTARTステートからACTIVEステートへの遷移において、ステーブルでなくてはならない

最後にバス転送するデータについてのプロパティです。

  • p_wdata_stable
    ライトオペレーション時、データはSTARTステートからACTIVEステートへの遷移において、ステーブルでなくてはならない

このように自然言語を使ってプロパティの項目を抽出することで、整理しやすく、また後で読み返しても分かりやすくなります。この段階でもプロパティの記述は可能ですが、ここでさらにコンセプト上のステートマシンに近づけるために抽象化を行います。その記述が図4です。

この抽象化を行うことで、プロパティ記述やアサーション記述の中でlocalparamの名称を用いて、より分かりやすい記述が可能になります。

図5. プロパティとそのアサーションの記述図5. プロパティとそのアサーションの記述

自然言語をアサーションに落とすだけ

ここまで準備が整えば、後は自然言語で抽出したプロパティをSVA記述に落とすだけです。何を記述すべきかの内容はすでに自然言語で分かっているので、この段階では、例えば含意演算子の当該サイクルが含まれるか含まれないかなど、自然言語では曖昧になりがちな部分の明確化に注意を払います。

各プロパティについては、上記のプロパティ名を使用します。プロパティを記述し、そのプロパティに対してassert構文でアサーション化するというスタイルで記載したものが図5になります。

まとめ

ハードウェアの実装前に要求仕様書があります。ハードウェアの実装記述を見てアサーションを記述するのではなく、あくまでも要求仕様からスタートすべきです。その際には、いきなりプロパティやアサーションの記述を始めるのではなく、多少面倒であっても、信号の定義やタイミングチャート、コンセプト上のステートマシンへの表現、そこから自然言語への落とし込みなどをプロセスとすると、抜け漏れのない記述ができます。またプロセス中のさまざまな段階をドキュメント化することで、第三者とのレビューにも使えますし、再利用される際にも価値が高まります。

このようなプロセスを支援するツールとして、代表的なものはExcelやWordなどもありますが、その他にもUMLのシーケンスダイアグラムを使ったり、あるいは分類分けする際にバブルダイアグラムを用いることも有効です。またボトムアップで組立てていく場合にはフリーでも入手可能なマインドマップのツールを用いることも有効です。そして、設計チームもしくは検証チームでレビューをしていくことが最も重要と言えるでしょう。

カバレッジの考え方と系統立てられた記述方法を
実践的な例題を用いて解説

今すぐダウンロード