Technology Reports 2007

第二の生産性革命 アルゴリズミックなテストベンチ合成

はじめに

  あなたが7年間の長期休暇でヒマラヤを旅して帰ってきたばかりでなければ、機能検証の穴が設計の遅れ、プロジェクト・コスト・オーバー、ハードウェアのリスピン、ファームウェアのパッチ、納品後の返品が開発マネージャの不眠症の主な原因であることを間違いなく耳にしたことがあるでしょう。またこれらの問題については多数のトレンド、データ、分析、仮説が存在します。今日RTLデザインはより複雑で大規模になっています。もちろんデザインが複雑、大規模になれば、エラーの数も増えることが予想されます。デザインを改版する度に、より多くの機能エラーを検出、デバッグしなければなりません。しかし、現実には設計の自動化と設計生産性に、機能検証の生産性が追従していないのではないでしょうか。興味深い現象は、設計者と検証エンジニアの割合が逆転していることです。1990年代初頭においては、2~3人の設計者に対して1人の検証エンジニアで足りていることが珍しくありませんでした。今やほとんどその状態が逆転しています。

  なぜ半導体の統合と設計生産性はムーアの法則に追従しているのに機能検証は遅れているように見えるのでしょうか?検証技術の進化により、機能テストが設計の複雑性についていけると思うはずです。設計の自動化と検証の自動化の方法に違いはあったのでしょうか?

設計生産性の劇的向上

<p>  1990年代初め、設計入力手法に飛躍的変化が生じました。回路図入力手法は継続して改良され続けましたが、論理合成の出現により10倍以上の革命的 な設計生産性の向上がもたらされました。この飛躍は次の3つの要素(抽象化、標準化、自動化)の組み合わせにより実現されました。まず、デザインを表現す る抽象度がゲートやネットリストからRTLへと上がりました。また、RTLは全てのハードウェア設計者とツール設計者が利用できる標準言語によって実現さ れました。さらに非常に時間のかかる作業(RTLからゲート/ネットリストへの変換)がコンピュータで実行されるアルゴリズムで自動化されました。設計者 は、意図する動作のRTL記述に集中し、回路構造の実装はコンピュータ・アルゴリズムに任せることにより生産性は大幅に向上しました。また、標準RTLモ ジュールから特定のプロセスあるいは実装へのリターゲットが可能になったことで、設計IPの再利用が現実のものとなりました。実際、より高い抽象度と標準 記述言語、コンピュータ・アルゴリズムによる自動化の組み合わせにより設計生産性があまりにも劇的に向上したため、業界は設計入力に再び同じような革命的 進化を起こそうと必死になっています。まだ明確に定義されているとは言い難いものの、E S L(Electronic System Level)設計はさらに高い抽象度での設計を可能にする為に、ツールベンダーはこの次なるステップを実現するべくコンピュータ・アルゴリズムを使った自 動化に多大な投資を行っています。</p>

検証が遅れをとる

  1990年代半ば、デザインの複雑性に対応することを目標として新しい検証技術が登場しました。既存のシミュレーション・テストベンチはプログラム的な性質を備えており、これには経験のある検証エンジニアが設計仕様を洗い出し、テストケース・シナリオを想定し、手作業でテスト・シーケンスを記述してシミュレーションによりスティミュラスを与え、チェックする必要がありました。基本的な機能はダイレクテッド・テストベンチで検証可能ですが、それほど明白でないシナリオを特定し、テストすることは困難であり、通常はデザインを作成した人による支援がかなり必要です。テストが実行されるシナリオの数はダイレクテッド・テストを記述する検証エンジニアの数、または記述するのに費やす時間と線形に比例する傾向があります。多くの開発チームは、テストベンチの有効性は検証エンジニアのレベルに依存していることを学びました。しかし検証チームがいかに大規模あるいは経験豊富であっても、設計者が論理合成を使って同じRTLから複数の実装をアルゴリズミックに生成するようになると、検証はダイレクテッド・テストだけでついて行くことは出来なくなりました。そこで業界はどのように対応したのでしょうか?

  これに続いて生じた検証技術は、ダイレクテッド・テストをランダム・シーケンス生成で強化しようとしたことでした。コンセプトとして新しいアイデアであったこの手法は汎用シーケンス構造を構築し、次にコンピュータによって自動化されたランダム選択テクニックを使って従来よりも膨大な数のテストケースを生成しようとするものでした。確かに、ランダム・テストにより検証エンジニアが事前に想定していなかった多くのテスト・シーケンスを生成することができるようになり、デザインに含まれるより多くの機能をテストすることで機能カバレッジを高めることができました。しかし、純粋にランダムなシーケンスの選択は、デザインに意図された機能以外のテスト・シーケンスの生成や、同じ機能を繰り返し実行するテスト・シーケンスの生成に繋がります。これらの問題に対応するため、コンストレインツ・ランダム手法が開発されました。コンストレインツ・ランダムでは、シーケンス構造のフレームワークを作成した後、検証エンジニアは一連の代数制約を作成します。各代数制約は、一定の条件の下でランダム・ジェネレータが不正なパスを選択しないようにするものです。何回かシミュレーションを実行した後、検証エンジニアは対話式に制約の追加セットを作成していきます。これらの制約は、ランダム・ジェネレータが既に検証済みのパスを選択しないようにするためのものです。

  コンストレインツ・ランダム・テストはダイレクテッド・テストと比較して劇的な検証生産性向上をもたらすものの、その効果は革新的変化というよりは、前進的変化でした。それがなぜかを理解するには、論理合成が設計プロセスに革新的インパクトをもたらし得た3つの要素に対し、コンストレインツ・ランダム・テストがどのように対応していたかを見れば明らかです。前述の通り、これらは抽象度の引き上げ、標準言語の利用、そして時間のかかるタスクをコンピュータにより実行されるアルゴリズムで自動化する、という3点です。

  まず、抽象度はあまり変わりませんでした。そして設計の仕様からシーケンス構造のフレームワークへ手作業で変換する必要がありました。フレームワークの境界がはっきりしすぎている場合、ランダム生成は最も厳しいコーナーケース・シナリオを実行しない可能性があります。フレームワークの境界があいまいすぎる場合には、ランダム生成が不正なシーケンス生成を行わないようにするために多数の状況を考慮した代数制約が必要になります。コンストレインツ・ランダム・テストはダイレクテッド・テストよりも多数のテストベンチ・シーケンスを生成するものの、フレームワークの生成と代数制約の作成にはかなりの時間と手間がかかります。このため、一般的な制約付きランダム・テストの参考書ではこの手法にダイレクテッド・テストを加えることにより困難なコーナーケース・シナリオをカバーすることを勧めています。最近のコンストレインツ・ランダム・ツールセットでは、複数のテストベンチ・シーケンス生成テクニックを活用することを提唱しています。

  次に、初期のコンストレインツ・ランダム・テスト手法は標準言語ではなく、専用の記述言語に基づいて開発されたものでした。習得に時間がかかる専用テストベンチ言語はエキスパートの領域となり、設計の複雑性についていくことができませんでした。今日の最も複雑なバス・プロトコルおよびインタフェース仕様を、これらの専用テストベンチ言語に落とすことができる検証エンジニアは、検証エンジニア全体の中でも少数です。専用テストベンチ言語のもうひとつの問題は、シミュレーション時に必要なかなりの処理のオーバーヘッドです。オーバーヘッドを含まないダイレクテッド・テスティングのシミュレーション効率と比較して、5 0 %以上のテストベンチオーバーヘッドがかかることも珍しくありません。検証自動化ツールのベンダーはこの欠点に気づいており、最近のコンストレインツ・ランダム手法では標準言語を使用し、これらの欠点を克服しています。

  3番目に、手作業による検証開発からコンピュータが実行するアルゴリズムでの自動化の度合いも疑問です。設計仕様からのテストベンチ・プログラムの洗い出しはダイレクテッド・テスト・プログラム作成の手順と似ているところがあります。次に何をテストするかという判断はエンジニアからランダム・シーケンス選択プログラムに任されますが、検証対象の機能範囲についての定義は本質的に変わりません。また、「次に何をテストするか」の判断を自動化することによって節約される時間と手間は、シーケンス生成に制約を与えるための代数式を記述する時間によって相殺されてしまいます。更に、これらの判断に対するコントロールは検証エンジニアの手から遠く離れてしまうため、シーケンス生成を望ましい方向に進めるにはより多くの制約を記述するか、ダイレクテッド・テストを利用しなければなりません。また、コンストレインツ・ソルバーには確かに高度なアルゴリズムが含まれていますが、これらが必要なのはそのランダム性によるものです。この点に気づいた結果、最近のコンストレインツ・ソルバーは第一世代のものと比較して高度に最適化されており、より効率的なコンストレインツ・ランダム・テストを可能にしています。

検証の飛躍的前進

  設計と検証の生産性のギャップを埋めるためには、検証の能力と対応規模に対する画期的な進化が必要です。他社が既存のテクニックの追加的改良を続ける中、メンター・グラフィックスは設計生産性の進歩に対応できる非常に先進的な検証技術を開発しました。この技術は劇的な前進に必要とされる先の3つの条件をすべて満たしています。メンター・グラフィックスのアルゴリズミック・テストベンチ生成は、検証エンジニアが既存の設計仕様を既存の標準言語を使ってきわめて正確な宣言型の記述に変換し、テストベンチ・シーケンスの生成作業をコンピュータにより自動化されたヒューリスティックなアルゴリズムで自動化することを可能します。テストベンチ・シーケンスを記述する必要も、シーケンス・フレームワークを定義する必要もなく、代数制約も必要ありません。その代わりに、検証エンジニアは設計仕様を、仕様の意図を表現したルールベースの動作記述に置き換え、個別のスティミュラスやルール・チェックは「アクション・ライブラリ」として実装します。高度なヒューリスティック・アルゴリズムはこのルールベースの記述をトラバースし、シミュレーション中にアクション・ライブラリを使って自動的にテストベンチ・シーケンスを合成します。その効果は画期的で、仕様の洗い出しにかかる時間が短縮され、記述は標準言語に準拠し、論理合成が設計作成を自動化したのと同様にシーケンス生成が自動化されました。次にその仕組みを説明します。