組み込みシステム検証のためのCテストケースの自動化

システムオンチップ（SoC）設計がさらに複雑になるにつれて、システムレベルの検証用の数千行のコードを含むテストスイートは、古風な趣のある古い学校であり、格言に反する効果のない実践である「自動いつでも可能なとき。"これは、製造前にデバイス全体を検証するためにSoCの組み込みプロセッサで実行されるCテストに特に当てはまります。

可能な場合に検証テストの構成を自動化すると、SoC開発の多くのフェーズの生産性が向上することが示されています。たとえば、Universal Verification Methodology（UVM）テストベンチの制約付きランダム手法では、特定のシナリオに向けられたランダム化されたテストベクトルを利用して、カバレッジを拡大します。これらによりハードウェアブロックレベルでの検証効率が向上しましたが、設計は依然として刺激、チェック、カバレッジコードが別々に記述されたブラックボックスとして認識されており、大きなブロックでは面倒でエラーが発生しやすいタスクです。

プロセッサのテストコードをI / Oトランザクションと組み合わせる必要があるため、この方法をシステムレベルに拡張することは困難です。これは、エミュレータやプロトタイピングシステムで実行されることがよくあります。 SoCを適切に検証するには、プロセッサ自体を実行する必要があります。 UVMおよびその他の制約付きランダムアプローチは、プロセッサで実行されているコードを考慮していません。実際、SoCでUVMを使用するには、プロセッサを取り外してSoCバスへの仮想入力と出力に置き換えることが多く、サブシステムからプロセッサを差し引いたものを検証できます。

SoC検証エンジニアは、制約付きランダムテストベンチの制限を認識し、SoC設計の完全な実行には制限がありますが、シミュレーションとハードウェアエミュレーションの両方でプロセッサ上で実行するCテストを手書きするように促します。これらの検証プラットフォームのパフォーマンスは、完全なオペレーティングシステム（OS）を実行するには十分ではないため、これらのテストは「ベアメタル」を実行します。これにより、構成作業にかなりのオーバーヘッドが追加されます。特にOSサービスを使用せずに手書きのテストを実行することは、複数のスレッドを利用してマルチコアプロセッサ間で調整された方法で実行されることは珍しいことです。その結果、並行操作やコヒーレンシなどのSoC動作の側面が最小限に検証されます。

Cテストの自動生成

もちろん、自動生成されたCテストは、エンジニアリングリソースをより効率的に使用します。また、カバレッジが向上します。生成されたCテストケースは、手書きのテストよりも多くのSoCの機能を実行でき、想像しがたい複雑なコーナーケースを探します。マルチスレッド、マルチプロセッサのテストケースでは、設計内のすべての並列パスを実行して、同時実行性を検証できます。メモリセグメント間でデータを移動してコヒーレンシアルゴリズムにストレスを与え、データをチップの入力に送信したり、出力から読み取ったりする必要がある場合は、I / Oトランザクションと調整できます。これの全体的な効果は、システムの機能範囲を拡大することであり、通常、特徴的にはるかに低い数値から90％を超えます。

Test Suite Synthesisとして知られるテスト生成ソフトウェアは、意図された設計動作をキャプチャする、理解しやすいグラフベースのシナリオモデルを使用します。これらのモデルは、ネイティブC ++を使用したAccelleraPortable Stimulus Standardを使用して記述したり、視覚的に記述したりできます。シナリオモデルは、設計仕様の一部を説明するためにホワイトボードに描画される可能性のある従来のチップデータフロー図に似ているため、SoC開発の自然な一部として設計または検証エンジニアによって作成されます。

これらのモデルには、本質的に刺激、チェック、カバレッジの詳細、およびデバッグ情報が含まれており、設計のあらゆる側面にストレスを与える高品質のセルフチェックCテストケースを生成するために必要なすべてのものをジェネレーターに提供します。これらは階層的でモジュール式であるため、ブロックレベルで開発されたテストは、完全なSoCモデルの一部として完全に再利用でき、さまざまなチームやプロジェクト間で簡単に共有できます。最後に、インテントの単一モデルを合成ツールで分解して、スレッドとI / Oポート間で同時テストを提供し、すべてを同期させることができます。

テストスイートの合成の利点

テストスイート合成の重要な利点の1つは、インテントモデルでカバレッジ目標を事前に定義できることです。インテントが指定されると、ツールはそれを分析して、生成される可能性のあるテストの数と、達成される機能的インテントの範囲を理解できます。

SoCの場合、これは何千ものテストに数えられる可能性があります。次に、テスト対象の意図を制限し、ツールを主要な領域に集中させることで、カバレッジの目標を設定できます。この機能により、テストを設定し、検証ツールを実行し、達成されたカバレッジを理解してから、テストを何度もリセットするという、従来のアプローチで発生する面倒な反復ループが回避されます。

有名な半導体企業によって開発された大規模なSoCに関する1つの典型的なプロジェクトでは、検証エンジニアはテスト構成時間を以前に必要だった手書きテストの20％に短縮しました。自動化テクノロジーにより、より厳密なテストケースが作成され、カバレッジが84％から97％に増加しました。さらに、モデルはポータブルです。

単一のモデルで、仮想プラットフォームのテストケース、レジスタ転送レベル（RTL）シミュレーション、エミュレーション、フィールドプログラマブルゲートアレイ（FPGA）プロトタイプ、またはポストシリコン検証中のラボ内の実際のチップを生成できます。

デバッグは、特にSoCレベルで、エンジニアにとってもう1つのタイムシンクです。テストケースで潜在的な設計バグが明らかになった場合、検証エンジニアは、どのテストがバグを引き起こしたかを理解して、その原因を突き止める必要があります。テストケースの失敗は、シナリオモデルの誤りが原因である可能性があるため、テストケースを、設計意図がキャプチャされたグラフに関連付けることができる必要があります。このプロセスは、バグが発見されたときに実行されたテストが見やすいように、簡単に分解できる高度にモジュール化された自己完結型のテストを作成します。

アプリケーションシナリオ

合成されたテストケースは、アプリケーションシナリオと呼ばれる現実的なユースケースを設計に使用できます。たとえば、図1に示すデジタルカメラSoCについて考えてみます。

クリックすると拡大画像が表示されます

図1：画像処理SoCの例。 （出典：Breker Verification Systems）

SoCブロックレベルのコンポーネントには、周辺機器とメモリの2つのプロセッサが含まれます。 SoCの簡単なグラフをブロック図の下に示します。グラフには、SoC検証プロセスで実行される可能性のある高レベルのパスが含まれています。たとえば、グラフの一番上のパスで表される1つの可能なシナリオは、SDカードからJPEG画像を読み取り、メモリ内の割り当てられた領域を介してフォトプロセッサに渡します。画像は、メモリ内の2番目のブロックに表示およびロードできる形式に処理されます。そこから、ディスプレイコントローラに渡されます。もちろん、これらの高レベルのブロックはそれぞれ階層的であり、プロセスの一部として多くのアクションと決定が実行されます。

合成ツールはランダム化されたテストを行い、それらを適切にスケジュールします。最も単純な形式では、図に示すように、テストは単一のスレッドにスケジュールされ、次のテストが続く場合があります。ただし、SoCにストレスを与えるテストケースの機能は、複数のスレッドと複数のプロセッサにまたがるアプリケーションのインターリーブに由来します。このツールは、設計に固有の同時実行性によってサポートされる限り多くのアプリケーションを並行して実行し、可能な限り曲がりくねった方法でメモリを割り当てます。これは、SoCメモリ全体に割り当てられたさまざまな領域を利用してテストが3つのスレッドに分散されている図の代替としても示されています。

もちろん、この例は、プロセスを明確にするために高レベルで提示されています。実際には、階層グラフは合成ツールによってフラット化され、多数のアクションと接続が作成されます。これらには、ソルバーアルゴリズムを介して実行する必要があるランダム化された決定も含まれます。グラフを歩くと、AI計画アルゴリズムが採用され、目的の出力を検査し、これに一致するように入力テストを最適化します。合成ツールには、メモリを割り当て、アドレスマップアクセスを提供し、割り込みを処理し、テスト構造を完了するために必要なその他のタスクを提供するOSのようなサービスが含まれています。次に、ストレージとその他のリソースが適切に割り当てられた状態で、テストがランダムにスケジュールされます。

結論

制約付きランダムテストベンチがブロック検証の手作業を排除したように、組み込みプロセッサベースのSoCの合成テストコンテンツは、システムレベルの検証作業を削減することが証明されています。さらに、このソリューションは現在、ブロックレベルおよびポストシリコン検証に適用されています。この例では、自動化されたCテストケースが「可能な限り自動化」という格言を適用し、検証スケジュールを短縮しながらカバレッジを劇的に改善します。