あなたの作ったテストベンチのバグ検出能力を高める方法 ―― ミューテーション法を利用した検証環境の品質改善

George Bakewell

tag: 半導体

技術解説 2010年3月18日

ディジタルLSIの開発において,機能検証の工数が増加し続けている.機能検証に要する期間が伸びている一方で,設計者や検証エンジニアなどが作成した検証環境のバグ検出能力について定量的に議論されることは少ない.ここでは,「機能検証環境の品質改善」という考え方と,それを実現するミューテンション法に基づくテスト技術について解説する.(編集部)

 

 最先端のチップの開発では,設計と同等以上の複雑さを持つ検証作業が実施されており,そこでは種々の高度な検証ツールが使用されています.こうした既存のツールは,スティミュラス(シミュレーション・パターン)の自動生成やカバレッジ(網羅率)解析などの機能が充実している一方で,テストベンチの品質が「どの程度良いのか」は示してくれません.例えば,バグの影響が観測可能な出力ポートに伝播しているかどうか,またバグによって引き起こされる間違った操作を確実に検出できているかどうかを評価できません.結果として,「どの部分の検証に労力をかけるか」,「どのように検証環境を改善するか」,「大部分の潜在的なバグを検出できるだけの堅牢さを備えているか」,「どの時点で検証が完了した,と判断するか」といった決断は,不完全なデータや「直感」に頼ることになります.

 ここでは,シミュレーション・ベースの環境を使い,機能検証の品質を測定したり改善したりするテスト技術について説明していきます.ここで説明する手法は,「ミューテーション法に基づくテスト技術」と呼んでいます.

 

1.既存の機能検証が抱える課題

●機能検証環境の良し悪しを評価する手法がない

 一般的な設計プロジェクトにおいて,機能検証には膨大な時間とリソースが必要になります.チップの回路規模と複雑さは増大し続けており,システムが完全に仕様を満たしているかどうかを判断する際に,専任の検証エンジニアのチームに頼らざるを得ない状況になっています.

 検証エンジニアは,検証を自動化し,検証環境の品質を向上させるために,専用のツールや手法を導入しています.にもかかわらず,依然として機能的な論理エラーがプロジェクトの遅延や設計手戻り(re-spin)の大きな原因となっています.この大きな理由として,検証環境の品質に関する二つの指標,すなわち「バグの影響を観測可能なポイントへ伝播する能力」と「誤った状態を観測し,そこからバグを検出する能力」を解析したり,測定したりすることができていない,ということが挙げられます.

 後述するコード・カバレッジや機能カバレッジのような既存の手法は,これらの二つの問題には対応していません.カバレッジのスコアが優れていても,機能エラーの検出漏れは存在します.

●機能検証環境は四つの要素から構成される

 検証環境の品質の問題について考える前に,既存の機能検証技術についておさらいしておきましょう.

 (シミュレーション・ベースの)ダイナミックな機能検証技術は非常に専門的な領域で,複雑になってきている機能間の相互作用を検証するために,専用のツールや手法,測定メトリックスなどを導入しています.プロジェクトの観点では,機能検証の主要な目的は,コストのかかるチップの再設計(手戻り)の回数を抑え,与えられた時間やリソースで,適切な品質の製品を市場に出荷することです.

 プロジェクトの開始時点でシステムの仕様が決まっていれば,機能検証のテストプランを作成できます.このテストプランをもとに検証環境を構築します.この検証環境は適切なスティミュラス(シミュレーション・パターン)を生成し,設計したものの動作が期待どおりであるかどうかを検証できなければなりません.このように検証環境には,設計が仕様通りに動作することを確認できることが求められます.

 一般に,機能検証環境は以下の四つの要素から構成されます(図1).

(1) 検証すべき機能を定義するテストプラン(Testplan)
(2) 設計したものを動かし,定義された機能をテストできるようにするスティミュラス(Stimuli)
(3) リファレンス・モデル(Reference Model)などの期待される動作の記述
(4) 観測された動作と期待される動作の差をチェックする比較機能(Compare)


図1 機能検証の四つの要素

 

 もしバグを「期待とは異なる設計の動作」と定義するならば,検証環境(Verification Environment)は,どの機能が検証されるべきかを計画(Testplan)し,スティミュラス(Stimuli)によってその機能を活性化し,観測ポイントまで伝播させて,この動作が期待したもの(Reference Model)とは異なることを検出(Compare)しなければなりません.検証環境の品質は,このような要求を満たせるかどうかによって評価されます.もし,検出能力があまりにも不十分であれば,いくら機能の活性化を完全に行っても意味がありません.同じように,もし,バグの影響が観測ポイントまで伝播しないのであれば,どれほど完全な検出機能を備えていても,バグを見つけられないことになります.

●コード・カバレッジや機能カバレッジでは対応できない

 機能検証でよく使われている指標として,コード・カバレッジと機能カバレッジがあります.ここではそれぞれの概要について説明します.

 コード・カバレッジは,スティミュラス(シミュレーション・パターン)の能力を測定するシンプルな方法で,設計のなかの論理がどの程度活性化(Activation)したかを測定します.具体的には,「(HDLコードの)すべての行の記述を実行したか」,「すべての信号をトグル('0'から'1'へ,'1'から'0'への変化)したか」,「すべてのパスを通過したか」,あるいはこれらに相当する個別の動作を測定します.

 これは必要条件(あなたがバグと関係したコードに「触れ」なければ,そのバグを検出することはできない,という意味で...)ではありますが,設計のすべての,あるいは大半の不具合を明らかにするのに十分であるとは言えません.コード・カバレッジが100%であっても,それは設計した機能が正しいことや完全に検証されたことを示すものではありません.

 コード・カバレッジは,検証環境によって設計した機能が実行されたかを示す指標です.しかし,伝播(Propagation)や検出(Detect)の能力に関する情報は提供してくれません(図2).コード・カバレッジは興味深い情報を提供してくれますが,「検証環境の品質」を測るという観点では適切な指標ではないのです.


図2 コード・カバレッジ

 

 機能カバレッジは,開発者が着目する「重要な機能」がスティミュラスによって実行されたかどうかを計測します.ここでいう「重要な機能」とは,内部状態の各ポイントやクリティカルな動作シーケンスなどを指します.機能カバレッジは重要な指標であり,これを利用すると,仕様書に定義されたすべての機能がスティミュラスによって実行されたかどうかを確認できます.

 ただし,機能カバレッジは主観的であり,もともと不完全な指標です.機能カバレッジによってチェックする内容(Assert)は,仕様や設計経験,検証工程における技術的な判断などをもとに,人間が決定します(図3).機能が仕様を満たしており,シーケンスが期待どおりの結果になっている(設計が正しく動作している)かどうかに焦点を当てた指標です.予期しない,もしくは適切でない動作をチェックする機能ではありません.その結果,スティミュラスが機能仕様に記述された動作を網羅しているかどうかを表現するためには良い指標であっても,コード・カバレッジと同じように,検証環境の品質や完成度を見積もるための良い指標とは言えません.


図3 機能カバレッジ

 

 

組み込みキャッチアップ

お知らせ 一覧を見る

電子書籍の最新刊! FPGAマガジン No.12『ARMコアFPGA×Linux初体験』好評発売中

FPGAマガジン No.11『性能UP! アルゴリズム×手仕上げHDL』好評発売中! PDF版もあります

PICK UP用語

EV(電気自動車)

関連記事

EnOcean

関連記事

Android

関連記事

ニュース 一覧を見る
Tech Villageブログ

渡辺のぼるのロボコン・プロモータ日記

2年ぶりのブログ更新w

2016年10月 9日

Hamana Project

Hamana-8最終打ち上げ報告(その2)

2012年6月26日