連載：テスト生成と再利用性を高めるポータブル・スティミュラスその２
連載：テスト生成と再利用性を高めるポータブル・スティミュラスその２
EE Tech Focus合同会社 三橋 明城男
アクセレラで標準化が進むポータブル・スティミュラスに関する紹介の第2回目は、UVMにおけるシーケンスやレジスタレイヤを用いたスティミュラス実現方法をレビューし、その延長線上にあり、ソフトウェアを含むより高い抽象度におけるテストインテントの表現や自動生成の概念について解説する。
UVMにおける抽象度とテストの再利用性
アクセレラ標準となるポータブル・スティミュラスには、テストインテント（何をテストするべきかの意図）を表現するための言語やテストのモデリング仕様が含まれている。またターゲットの検証プラットフォームはシミュレーションだけでなく、SystemC実装の仮想プラットフォームやFPGAプロトタイピングなども含まれる。その目的は既存のテスト手法を置き換えることではなく、むしろ延長線上に位置付けられる。そこでポータブル・スティミュラスの姿を正しく描くために、まずはシミュレーション検証手法として採用が進んでいるUVM（Universal Verification Methodology）についてレビューしておきたい。
図1.では、ブロック検証における3種類のケースを示しており、いずれのケースでもスレーブのインタフェースを持つBlockが検証対象である。
図1. UVMを用いたブロック検証
Case-Aはスレーブのインタフェース用のエージェントを用いて検証する様子を示している。エージェントは検証IPとして考えていただいて差し支えない。図2.にエージェントのコンポーネントを示す。
図2. UVMにおけるエージェントの構成例
エージェントや検証IPにはインタフェース固有のプロトコルに従うドライバやモニタ、モニタがピンレベルの動きを抽出しトランザクションとして解析を行うコンポーネント、またドライバとハンドシェイクをするシーケンサと呼ばれるコンポーネントが含まれる。このシーケンサが呼び出すシーケンスの例を図3.に示す。
図3. トランザクションレベルのシーケンス記述例
forループではランダムなトランザクションを10個生成し送出している。ランダム生成はstart_itemとfinish_itemの間で行われている。start_itemはドライバにリクエストを行い、ドライバ側はトランザクションが送信可能となったタイミングでレスポンスを返す。これはstart_itemの戻り値であり、シーケンサ側が待ちの状態となりハンドシェイクを実現する。finish_itemはランダム生成したトランザクションを送出する。スタート、トランザクション生成、フィニッシュは、ちょうどReady-Set-Goといった流れである。この同期化の仕組みがエージェントに備わっていることで、テスト記述者はforやifなどを用いたアルゴリズム記述に専念し、実際のピンレベルの動きはもちろん、トランザクションを送出するタイミングをも気にする必要はない。
ここで図１.に戻ると、Case-Bはバスを介した構成となっている。エージェントもマスタ用のものを使ってトランザクションを生成させるが、このエージェントが呼び出すシーケンスは、Case-Aで使用したシーケンスをそのまま利用することが可能である。同じシーケンスを用いて、スレーブからマスタへの変更や、異なるバスプロトコルへの対応が可能である。
さらにCase-Cでは、UVMで用意されているレジスタレイヤを使用して、さらに抽象度を上げている。この構成に対応するレジスタシーケンス例を図4.に示す。
図4. UVMのレジスタシーケンス例
図3.の記述に比べて記述量が少なくなっていることも確認しておきたい。start_itemやfinish_itemの代わりにwrite_regを用いて記述する。テスト記述者は具体的なプロトコルから独立した、単にレジスタに対するやりとり行うスティミュラスやレジスタシーケンスを記述しさえすれば良い。このレジスタレイヤは、もちろん、図1.のCase-Aに示すスレーブ用エージェントに対しても使用することが可能である。
CPUを含むシステムのテストへ
図5.では、プロセッサ上のソフトウェアを用いてランダムなトランザクションを10個送出し、バス接続するスレーブのブロックのテストとしている。究極的にはRTOSやベアメタルを搭載し、実際のソフトウェアコードを用いて検証することである。それもマルチコアや他のマスタブロックなどとスケジューリングしながらである。
図5. CPUとSWコードを用いたブロック検証
図5.にあるソフトウェアコードの記述量は、図3.にあるテストコードと比べると、記述量が格段に少ない。テストの抽象度を上げることで記述量が減り、流用性が高まる。それと同時にテストインテントの抽象度も上がっていく。その際には抽象度が低いピンレベルやトランザクションレベルの動きを懸念することなく、適切なレベルのテストインテントに専念することができる。
オランダの計算機科学者であるEdsger Dijkstra氏は1974年に執筆した「On the Role of Scientific Thought」の中で「separation of concerns」という表現を用いている。これには「懸念することを分離させて取り組む」といった意味合いがある。UVMはもちろん、ポータブル・スティミュラスも、この考えを実践するための手法を提供する。ポータブル・スティミュラスはテストインテントを1つの方法で表現し、そこからEDAツールによる自動生成により多様な再利用を可能にする。例えば多様なユーザ間での利用、つまりアーキテクト、機能検証、ソフトウェアテスト、ポストシリコン検証者などが使用できることを目指す。プロジェクト戦略に基づいて開発環境や検証環境をコンフィギュレーションし、さまざまな抽象度でのハードウェア／ソフトウェア統合や開発プロセスの最適化につながることが期待される。
グラフベースのアプローチ
テストインテントを表現する方法として、IBM、Breker Verification Systems、メンター・グラフィックスらによってグラフベースのアプローチが提案された。図6.にその概念を示す。
図6. グラフベースによるシナリオの表現
テストインテントをグラフベースで表現し、そこから以下のようなテストを自動生成しようというものである。
Init→A→B→E→F→H→
→Ａ→B→Ｅ→Ｇ→H→
→Ａ→Ｃ→E→F→H→
→Ａ→Ｃ→E→G→H→
→Ａ→D→E→F→H→
→Ａ→D→E→G→H→
Aの後はB、C、Dの3とおり、Eの後はF、Gの2とおりで、全部で6とおりのパスである。グラフベースのアプローチでは、テストシナリオやデータを用いてリーガルなテスト空間をモデル化する。実際にはデータに対する制約、シナリオの優先順位やランダム時発生の重み付け、データの生成側から消費側へのフロー、処理のパラレル化や処理終了への同期などを記述することでモデル化する。グラフ的な表現はEDAベンダが提供するツール内で例えばモデル化ツールや記述のビューワ機能、テストのデバッグ機能やカバレッジ解析機能として搭載される可能性もあるが、本稿ではあくまでも概念を示すもので、標準化の対象となるのは記述言語である。
図7. テストシナリオとテストベンチへのマッピング
グラフベース内の各シナリオは、それぞれのエージェントからシーケンスを介して呼ばれるバーチャル・シーケンスと同様の役割を果たす。図7.に示すように、DUTはテストベンチに置かれる。テストベンチにはまた、DUTを構成するコンポーネントに対応するエージェントを配置しコンフィギュレーションを行う。その各エージェントに対して、グラフベースの各テストシナリオが実行される。例えばSD-CARDから読み出したデータをDMAチャネルを介して、ビデオデコーダで処理するといった一連のシナリオが実行される。
ポータブル・スティミュラスをサポートするシミュレータやエミュレータ、FPGAボードにより、実装方法は異なるであろう。例えばシミュレーションがプラットフォームである場合、CPUに対してはmailboxを使うかも知れないし他のHW/SW協調検証の手法を使うかも知れない。エミュレータがプラットフォームである場合、SDカードの読み出し部分は、専用のポッドになるかも知れないし、Cの仮想モデルであるかも知れない。しかし重要なことは、1つのテストインテントが多様な状況で再利用できることである。
次回予告
次回はスティミュラスの基本的な構成要素を考え、テスト空間のモデル化をするための要件、ポータブル・スティミュラスとして新たに定義されている記述方法などについて紹介する。
■筆者プロフィール：
三橋 明城男（みつはし・あきお）
EE Tech Focus合同会社 代表社長
半導体設計、組込みソフトウェア開発、米国EDAベンダにおけるエンジニアリング・マネージャー、マーケティング・ディレクターなどを経てEE Tech Focus合同会社を設立。現在はコンサルティングやマーケティング支援、海外の技術情報のキュレーションなどのビジネスを展開している。