Technology Reports 2006

テストベンチに関する議論

はじめに

様々なリサーチの報告にあるように、機能検証における問題がSoCリスピン(マスク設計のやり直し)の主な原因となっています。設計の規模や複雑さが 増す中で、機能検証には全工程に要するリソースの70%以上を費やしているにも関わらず、機能検証の問題が原因でリスピンが発生する傾向は、ますます増え ています。ここでは検証の問題に対し、どのようなテストベンチを構築すべきかについて議論します。

検証とは何か

まず、そもそも検証とは何かという定義をします。図1はおおまかな検証フローです。仕様書は、自然言語による説明やス プレッドシート、タイミングダイアグラム、ブロックダイアグラムなどから構成されます。この仕様について実現の可能性や仕様そのものに矛盾が無いことを確 認するために、ハイレベルの動作モデルを作成します。通常はC / C ++、あるいはSystemCによる高い抽象度でモデリングを行います。アンタイム、もしくはタイムドのトランザクションレベルの抽象度を用いるのが一般 的です。

続いてRTLを記述します。このRTL記述はインプリメンテーションとも言われます。RTLは信頼できる論 理合成ツールと同期設計技術の普及により、今日の設計者が考慮する最も詳細な記述レベルと言えます。レジスタ、ワイヤ、クロックなどのハードウェア的かつ インプリメンテーション的な要素と、組み合わせ表現や制御論理など一般的な手続き型のプログラミング言語にも似たソフトウェア的かつ、スペックから部分引 用が可能な要素から構成されます。

次のレベルがゲートレベルになります。ここはスペック的な要素は無く、インプリメンテーションが支配的です。このように抽象度を下げ フォームを変えるたびに、インプリメンテーションが支配的になります。そしてフォームを変える前後での比較(検証)をしています。幸いにも、RTLとゲー トレベルの間の比較については、論理合成技術やATPG、アイソモーフィズムなどのアルゴリズムを併用した等価性検証技術が一般的になっています。つまり 「機能検証とはスペックとRTLインプリメンテーションとの比較」と定義することができます。

機能検証におけるテストベンチ

機能検証の定義が、スペックとRTLインプリメンテーションの比較であるならば、テストベンチは、この定義上の比較を サポートするものでなくてはなりません。すなわちテストベンチはスペックからくる「設計の意図」を盛り込むことができなくてはなりません。設計の意図が盛 り込まれた検証は、スペックとRTLインプリメンテーションとの直接的な比較ではないにしても、シミュレーションというツールを介して得られるDUTの振 る舞いは、RTLが意図されたとおりにインプリメントされているかどうかを含意します。

テストベンチは純粋にソフトウェアの世界に属するものです。テストベンチの要素はデータ構造とアルゴリズムという面で、一般的なソフトウェアに非常に類 似します。テストベンチの役割はハードウェアであるDUTの制御、ハードウェアからの応答およびその解析であり、ハードウェア寄りであると言えます。しか し構成要素と処理内容の大半はソフトウェアに類するものとなります。その理由は以下のとおりです。

  1. スティミュラス生成と結果の収集、解析には、タイミング、レジスタ、ワイヤ、あるいは他のハードウェア的な要素を必要としない
  2. テストベンチは論理合成の対象とはならず、従って論理合成が必要なデザインに求められる制限に制約されることがない

このことから、RTL機能検証に用いられるテストベンチの抽象度は、RTLよりも高い抽象度で動作させることができます。

テストベンチの抽象度

RTL抽象度のDUTを検証するためのテストベンチについて、抽象度を検討してみます。検討するにあたって考慮すべき ことは以下の二点です。

  1. 図1の検証フローにおいてスペックに一番近い抽象度
  2. スペックから来る「設計の意図」が盛り込めること

現在、SoCアーキテクチャ検討やハードウェア・ソフトウェア協調検証などで一般的に使用されている抽象度がトランザ クションレベルであること、OSCIによりTLM 1.0規格が標準化されていることなどを考えると、RTL機能検証に適したテストベンチの抽象度は、トランザクションレベルであると言えます。このトラン ザクションレベルと、RTL抽象度のDUT間でのコミュニケーションは、抽象度を変換するための「トランザクタ」を介して行われます。RTL抽象度の DUT、トランザクタ、そしてトランザクションレベルの検証コンポーネントにより構成されるテストベンチの例を図2に示します。

テストベンチを構成するコンポーネント

シミュレーションを用いて機能検証をする際に、重要且つ非常に基本的な二つの命題があります。それは「正しく動いている か」そして「検証は終了したか」という問いです。図3において「正しく動いているか」という問いに対して「NO」という回答が得られたならば、それは設計 上のバグです。デザインを修正して検証するというイタレーションになります。仮に「YES」と答えられた場合、その次に来る問いが「検証は終了したか」で す。これはテストの網羅性に対する問い、つまりカバレッジが充分あるかという問いです。この問いに対する回答が「NO」ならばカバレッジが充分でないこと を示し、テストシナリオを追加する、もしくは修正して検証するというイタレーションになります。

仮に「YES」と答えることができれば、それは検証の終了を意味します。

テストベンチは常にこの二つの命題に対する解が得られる手段を提供していなくてはなりません。図2のテストベンチ構築例 では、「正しく動いているか」に対する手段が「スコアボード」であり、「検証は終了したか」に対する手段が「カバレッジコレクタ」です。どちらも「解析用 コンポーネント」と呼ばれるもので、膨大なピンレベルでの動きからトランザクションに抽象化されたデータを取り込み、データから意味ある情報へと変換しま す。意味ある情報は解析の直接的な対象であり、設計の意図を盛り込んだシナリオ生成へフィードバックを戻す仕組みが構築できる ことになります。

テストベンチを構築するための戦略

図2で示したテストベンチ構成例は、前述の基本的な、しかし極めて重要な二つの問いに対して回答することができるための仕組みです。これらの問いに対し て回答するには情報の解析が必要です。データを収集し、意味ある情報へと変換し、そしてそれを解析して未カバーの領域に対してテストシナリオを方向付けさ せるための仕組みです。アドホック的なアプローチでないことは一目瞭然です。と同時にテストベンチの生産性を高めるためには、なるべく少ない行数で実現 し、しかも再利用性を高める工夫も必要です。例えば、デザインへの依存性、テストベンチへの依存性、プロトコルへの依存性などに分類することで、少しでも 再利用性を高めることができます。

図3.検証イタレーション(図をクリックすると拡大表示します)図3.検証イタレーション(図をクリックすると拡大表示します)

まとめ

これまで議論してきたように、テストベンチはスペックから来る設計の意図を盛り込むことができるトランザクションレベルが適切であり、その構成には 「正しく動いているか」と「検証は終了したか」という問いに対応する解析手段が必要です。そしてテストベンチの構築はアドホック的なアプローチでは難し く、少ないコード数で再利用性を高める工夫も必要となります。メンター・グラフィックスでは、このようなコンセプトに基づいたテストベンチ構築の手法を、 SystemCとSystem Verilog、それぞれの言語で「クックブック」というキットにまとめました。特にテストベンチ構築の労力を軽減する一番の方法は、すでに動作が確認さ れているテストベンチを修正し、自分の検証環境に当てはめて行くアプローチです。「クックブック」はオープンソース形式で配布されているため、すべてソー スコードで確認することができます