概要

ポータブル・スティミュラス標準（PSS）は、テスト・インテントとテスト動作の仕様を定め、テスト用信号入力を様々なターゲット・プラットフォームに再利用できるように作成された、最新の工業規格です。PSSの導入は、システム・オン・チップ（SoC）の検証と妥当性を確認するための従来アプローチに変化をもたらし、多くの利点を提供しますが、同時にいくつかの課題も生み出します。本稿では、SystemCベースの性能分析から汎用的なPSSベースのトラフィック・ジェネレータによる検証と妥当性確認に至るまで、相互接続（Interconnect）バス・ファブリックのライフ・サイクルに関わるこれらのプロセスの変化について検討します。

はじめに

検証のための手法と技術は、設計要求が複雑になり始めてから絶えず発展を続けてきました。ポータブル・スティミュラス標準（PSS）はこの発展のプロセスに最近加わった標準で、テストのポータビリティ（移植性）に関わる課題を解決するために作られたものです。この新しいPSSに従えば、種々のターゲット・プラットフォーム上で再利用できるようにテスト・インテントを作成することができます。PSSベースの検証手法は、ポータビリティと共に、テストの視覚的表現や制約の設定、データフローに基づくランダム化、テスト品質の向上といった面からさらなる価値を提供します。PSSベースの手法を採用する場合は、SoCの検証と妥当性確認のプロセスに応じてその後のプロセスを変更する必要があるので、その影響を理解することが重要です。本稿では、SystemCベースの性能分析から始まり検証と妥当性確認に至るまでの相互接続バス・ファブリックのケース・スタディを行うことによって、これらのプロセス変更の詳細を検討します。

詳細

設計の複雑化に伴い、SystemCベース・モデリング、アーキテクチャの検討、高位合成といったプロセスの変化が、従来の設計フローや統合化フローと共に、一般的になりつつあります。更に、これらのプロセスの変化によって、システムの設計条件が守られているかどうかをチェックする必要性が新たに生じます。これらのプロセスに関わる様々なチームは、異なる種類のプラットフォームや言語を使用して、これらの変化に対応しています。しかしこのような違いがあるにも関わらす、連続する各プロセスの基本的仕様は同じであるため、同様の作業を何度も繰り返すという結果を招いています。

アーキテクチャ開発チームは、SystemCベースやTLMベースのモデリングを使用して、アーキテクチャの検討やソフトウェア開発のための仮想プラットフォームを作成します。コンポーネント設計チームは、ブロック・レベルでVerilogコンポーネントを設計し、手動プロセスまたは自動プロセスによってそれらを統合してシステムを作成します。IPレベルの検証はUVMベース検証を使用して行うのが通常ですが、システム・レベルでは、CベースのアプローチとUVMベースのアプローチを組み合わせて使用します。UVM環境では、IPレベルからシステム・レベルまで容易にチェッカーを再利用することができますが、多くの場合、テスト・スティミュラスはトップ・レベルのUVM環境で使用できるように書き直されたり、チップ・レベルのプロセッサ上で実行するためにCに書き直されたりします。テスト・プラットフォームには新たなテストが必要であり、評価用ボード上でテストを行う場合も新たなテストが必要です。したがって、ブロックの起動／設定動作や基本モード動作を検証するテストを作成する作業は、実際のシリコン・テストでも繰り返されます。更に、ソフトウェア・チームには、顧客のインターフェース用にソフトウェア・ドライバを記述するという別の作業もあります。

異なる言語や手法を用い、いくつかのチームでこれらの作業を繰り返すことは、誤ったバグ・レポートを頻繁に発生させ、市場投入までの時間が大幅に延びてしまう結果となります。プロジェクト全体を通じて、テスト記述者全員が共通の言語を使え、単純な機能検証テストの大部分を水平方向にも垂直方向にもシームレスに再利用できる、より優れたソリューションが必要です。この従来とは異なるアプローチこそ、PSSベースの検証手法が提供するものです。

PSSは、1つのテスト・ソースから様々なプラットフォームをターゲットとするテストを自動的に作成することを可能にする、新しいテスト記述言語を定義します。水平方向での再利用（シミュレーション、エミュレーション、ボード・レベル、テスタなど）に加えて、この新しい言語は垂直方向での再利用も可能にします。IPレベルで開発されたテストは、より容易にSoCレベルで統合し、再利用することができます。ポータブル・スティミュラスは、ターゲット・プラットフォームの種類に全く左右されない、より高い抽象化層で機能します。この場合のターゲット・プラットフォームとしては、UVMベースの検証環境、C/C++ベースとSoCベースの環境、CベースおよびPython^®ベースのポストシリコン検証プラットフォームなどを挙げることができます。

PSSベースのアプリケーションを使用すれば、テスト・インテントを様々なレベルで検証するのに使用できる、汎用的なアプリケーションを容易に作成することができます。このアプリケーションは、マルチプロセッサSoCに相互接続バス・ファブリックを使用する際にも使用できます。機能と性能は、様々なレベルで検証し評価する必要があります。

相互接続バス・ファブリックはSoCの具体的な条件に従って慎重に選ぶ必要があるので、早い段階で性能を分析することが求められますが、これはシステム・モデル（通常はC/SystemC）を使って行うことができます。この場合は、そのシステム・モデルを検証することのできるテストを作成しなければなりません。その構成を選択してRTLを作成したら、それをIPレベルで検証する必要があります。このためには、UVMベースの検証と検証用のUVMシーケンスが必要です。その後作成したRTLをシステム・レベルでSoC内に組み込み、それをSoCレベルで検証します。これは通常、検証と妥当性確認のためのテストをC/C++でコーディングすることによって行われます。

こうしたすべての検証アプリケーションは、PSSベースの手法を使って再利用可能なテストを作成することにより操作できます。これを実現するために作成されたのが汎用トラフィック・ジェネレータ用のPSSモデルで、様々な数のマスタに対して様々なパターンの読出しと書込みを作成することができます。このトラフィック・ジェネレータは、高速のマスタと低速のマスタをエミュレートできるように、各マスタへの分配が異なるトラフィックを作成できます。

また、どのマスタがどの周波数でトラフィックを生成するかを個別に制御したり、バックツーバック・トランザクションや遅延トランザクションを生成することも可能です。PSSベースのトラフィック・ジェネレータを使用した場合のプロセス・フローを図1に示します。紫のブロックは汎用スレーブとマスタを持つ相互接続バスを表し、緑のブロックは、バス上のトランザクションを駆動するRTLまたは動作モデルを表します。PSSベースのトラフィック・ジェネレータ（ピンク色のブロック）はこれらのブロックを統合して制御し、トランザクションの駆動と収集を行います。トラフィック・ジェネレータは様々なトラフィック生成条件に対応して、SystemCベースのアプリケーション、UVM、Cベースのテストなど、種々のターゲット用にテストを作成します。各プロセスには、統合化やテスト作成に関して異なる対応が求められますが、これについては以降のセクションで説明します。

相互接続バスのSystemCベース性能分析

相互接続バスの性能分析は、システムの性能と電力を定量的に測定するために、SoC開発サイクルのできるだけ早い段階から行います。相互接続バスの性能判定は、広範なアプリケーション、プラットフォーム、および相互接続構成（トポロジ、特性、構成など）について行う必要があります。そのためには、条件を収集して仕様を作成し、その仕様に基づいて性能、電力、面積に関する条件を満たすまとまりのある設計をすることが求められます。これは、設計の全期間にわたって反復されるプロセスです。プロセスを繰り返す場合、その都度仕様を取りまとめ、設計チームと開発チームに通知する必要があります。

これは、定められたSoC仕様を表すSystemCベースのTLMモデルを使って行われます。このモデルを使用すれば、システムの動作を正確に予測することができます。SystemCモデルを作成するためのツールの構成設定から始まるこのフローを、図2に示します。これらのモデルはツール・キットの一部であり、設計上の必要性に応じて構成を設定することができます。このツールを使用すれば、AMBAのマスタやスレーブ、クロック・ジェネレータ、スティミュラスなどのための正確なサイクルのモデルや、近似サイクルのモデルを作成することが可能です。モデルができたら、手動、または自動化された動作指示スクリプトを使用してこのレベルでトラフィック・パターンを記述し、仕様を実際のシミュレーションに変換して結果を収集する必要があります。モデルはその後、性能の定量化を支援する特別なシミュレータを使ってシシミュレーションされます。

モデリング用や分析用のツールを使用したとしても、多数の設計候補をテストするにはかなりの時間がかかります。スクリプトを使用してトラフィックを生成すれば、一定数のトラフィック・パターンを利用できますが、あらゆるケースを想定したシナリオの作成という点では依然問題が残ります。その上、シミュレーションに時間がかかるので、シミュレーションの最後に分析を行うと、予想数値を得るための試行回数が増加します。設計および性能のモデリング機能全般に関わる仕様の扱いに費やされる時間と合わせると、単一のソースから始まる、より自動化されたフローが必要なことがわかります。PSSベースの手法は、これらの課題を解決するための効果的な方法です。

PSSベースのツールのランダム化メカニズムは、最初にDUTのハイ・レベル状態間の規則に沿った遷移を抽象化して記述し、この状態空間を通じる経路をカバーするために必要な最小限のテストのセットを自動的に列挙します。PSSベースのツールは、与えられた状態空間内で各種条件がどれだけの範囲でカバーされているのかを測定できる、カバレッジ・メカニズムを備えています。これにより、生成されたスティミュラスの実行前でもカバレッジを測定することが可能になるので、プロセスに要する時間を短縮することができます。また、PSSベースのカバレッジによって検討経路を表示できるほか、グラフの最大長さをカバーできるようにテストを作成することができます。したがって、通常の制約付きランダム検証よりもはるかに少ないサイクル数で、より広いカバレッジを実現することが可能です。

PSSベースのツールはテスト・インテントを視覚的に表すことも可能なので、生成可能なシナリオを、よりわかりやすく視覚化することができます。この機能により、特定のテスト条件をカバーするためのディレクテッド・テストに関する詳しい検討を容易に行うことができます。また、一定の条件セットに制約を設けることも可能なので、特定の機能セット用の制約付きランダム・シナリオを作成できます。PSSベースの手法を導入した場合も図2に示すフローは基本的に同じですが、トレース作成フローは大きく変わります。

トラフィック・ジェネレータの中心となるのは、種々のトラフィック・パターンを生成するアルゴリズムが組み込まれた、汎用的なPSSモデルです。これは、スティミュラスとテスト・シナリオを1つにまとめて表したものです。このモデルは、トラフィックを生成し得る複数の順列のうち1つを含むテストを作成するために、いくつかの構成を採ることが可能です。モデルは、以下の3つの部分で構成されています。

• 実行ブロック：実行ブロックは、PSSベース・ラッパーのターゲット・プラットフォームに使われる外部コードのステートメントです。SystemC側のアプリケーションに関しては、基礎となる環境に対して種々の読出しと書込みを行うカスタム・コードがあります。また、UVM SV部分に関しては、ツール付属のマクロ（トランシーバー生成）によって得られるロジックを持っています。このマクロは、PLIベースのシステム呼び出しによって、SV環境との間で変換と連携を行います。更に、変換されてC側と連動し、様々なプラットフォームにシームレスに再利用できる部分（C生成）もあります。
• PSSモデル：これは全体的な仕様のセットに基づく実際のユースケース・モデルで、一連の動作を実行するためのよりハイ・レベルなシーケンスと同等の機能の集合で構成されています。トラフィック・ジェネレータには種々のアルゴリズムのセットが含まれており、これらは、シンプルな動作や複合的な動作を含む様々な形態で表されます。これらの機能は、最終的には実行ブロックから機能を呼び出してSV側のコマンドを実行します。
• PSS構成：汎用的なモデルを使って特定のテストを作成するには、具体的な情報が必要です。この情報は検証に関係するもので、例えばAMBAマスタやスレーブの数、マスタ・タイプ、送信元と送信先のアドレス、アクセス・タイプ、平均帯域幅、バースト・サイズ、データ・サイズ、周波数、帯域幅などの条件があります。この情報は、テスト・インテントを正しく表すために、仕様から導き出す必要があります。

図3はPSSベースのトラフィック・パターン生成フローを表しており、これは仕様の解析から始まります。Pythonベースのスクリプトがスプレッドシートに記述された仕様の特定の側面を解析し、汎用的なPSSモデルとPSS構成で読み出すことのできるフォーマットでデータを抽出します。このPSSモデルと構成は、更にPSSツールによって解析され、そのテスト・インテントが視覚的に表されます。テスト・インテントを視覚的に表したものの一部を図4に示します。図には、読出しまたは書込み動作、シングル・モードまたはBurst Mode^®、バス・サイズなどで表された条件が含まれており、これを制御することによって異なるタイプのトラフィック・パターンを生成することができます。検討する条件は紫の部分で示されていますが、青の部分は検討の対象外です。これにより、必要なトラフィックの様々な側面を可視化し制約することが容易になります。制約を追加しない場合は、PSSツールが構成をランダムに選択して、制約付きのランダム・テストを作成します。これは、ツールベースのカバレッジを収集し、コンポーネントの完全性を早い段階で解析できるポイントでもあります。ツールベースのカバレッジは、ツールが生成したテストにおいてテスト・インテントがどれだけ良好にカバーされているかの基準となります。図4は、PSSツールによって作成されたPSSベース・カバレッジの各部を表しています。ピンクのブロックはカバーされていない条件を表し、緑のブロックはカバーされた条件を表しています。ユーザはこれらの表示を見て、カバーされていない条件用のテストを作成することができます。

テストが作成されるとポストプロセシング・スクリプトが実行され、性能分析シミュレーション・ツールに使用できるトラフィック・パターンが、カスタム・フォーマットで作成されます。次のステップは、シミュレーションを実行して大量の未加工データを生成するためのトラフィックを作成することです。これらの未加工データは、結果を効果的に分析できるように、様々な基準と可視化方法で処理する必要があります。表1に、複数のパラメータを使って生成されたレポートの例をいくつか示します。これらのパラメータは、複数のマスタとスレーブを持つSoC用の相互接続バスの性能分析を計算するために考慮されたものです。この分析では、プラットフォームの仕様に基づき、1対1（マスタとスレーブ）および多対1のシミュレーション（「実験」と呼ばれる）を生成することができます。実験はプラットフォーム仕様に定めるクロック周波数とデータ幅の静的解析に基づいて作成され、その理論的な最大帯域幅まで動作するように設定されます。一般にPSSベースのトラフィックでは、特定のバス構成をターゲットとするランダム・シナリオを、より適切に配置することができます。また、テスト・インテントの視覚的な表現により、より適切な制約を作成可能となります。カバレッジを可視化できることはトラフィック・パターンの改善につながるので、所定のマスタ・スレーブ・システムで実現可能な最大限の帯域幅を、より少ない繰返し回数で実現することができます。

以上から、PSSベースの手法を採用することにより、シミュレーションで最大平均帯域幅に達するまでに必要な繰返しの回数を少なくでき、結果としてシミュレーション・サイクルと解析時間を短縮できることがわかります。

相互接続のアーキテクチャ性能モデルの作成に必要な作業を減らすと共に、統一された仕様だけに情報源を絞ることによって、再構成のためのあらゆる時間が大幅に短縮されます。このフローに従えば、多くの設計候補を検討してその中から1つを選び、タイミング・クロージャやRTLフローを完了させることができます。

相互接続バスのUVMベース検証

相互接続ファブリックの性能分析を行えば、性能、電力、面積に関して最適な構成を実現することができます。相互接続構成が固定されれば、それを使用して、設定変更可能な自動化フローにより、AMBA相互接続のRTLを作成できます。しかし、このフローでは、構成上の制約やソフトウェアの構造、仕様の解釈が手動で行われることなどからエラーが発生しやすいので、検証を行って作成プロセスに問題がないことを確認する必要があります。これは従来、業界標準のUVMに基づくアプローチを使用して行われてきました。

相互接続バス検証のためのUVM環境を図5に示します。これは、カスタム構成された異なる種類のAMBA（AXI、AHB、APB）マスタとUVCスレーブで構成されており、マスタがDUTのスレーブに、スレーブがDUTのマスタに接続されます。環境は、その環境に合わせた汎用的な設定とすることができます。スコアボードはトランザクションを記録して、データに何らかの不整合があった場合はエラーを表示します。

テストには、基礎となるUVCとインターフェースの機能を制御するシーケンスと仮想シーケンスのセットが含まれています。テストは、ディレクテッド・テスト・ケースとランダム・テスト・ケースを使い、仕様から作成されたテスト・プランに従って行われます。機能的なカバレッジ・ポイントも、仕様を満たすことができるように、検証プランを考慮して作成されます。その後シミュレーションを実行してカバレッジ・データベースが作成され、コードと機能カバレッジが収集されます。このデータベースを分析して、カバレッジ・ホールの有無が確認されます。また、リグレッション・テストを実行して、レポートの生成と分析が行われます。このプロセスは、高品質の検証を実現するために、カバレッジで必要とされる目標に達するまで繰り返されます。

検証プランの一部としてのディレクテッド・テストと共に、UVMベースの手法は、カバレッジ目標を達成するためのランダム・テストに依存しています。この手法はランダム・スティミュラスから始め、カバレッジ目標に達するまで徐々に制約を厳しくしていきますが、これはランダム化を行うための単純な処理能力と、状態空間をカバーする計算サーバー・ファームに依存しています。コード・カバレッジはDUTコードの実行に関する定量的な尺度ですが、機能カバレッジは定性的な尺度です。通常、この品質は、検証プランの作成とカバレッジ・レポートを分析する人の努力と綿密さに左右されます。検証の品質を左右する他の要素として、効果的に自動化されたチェックがあります。スコアボードを使用するパケット比較とアサーションベースのチェックポイントを組み合わせれば、フロー後半で現れるポストシリコン・バグの数を知ることができます。UVMベースの検証手法は必要な要素をすべて備えており、高品質の検証を効果的に行うことができます。しかし、PSSベースの手法を導入すれば、その様々な機能によって更に検証フローを改善することができます。

PSSベース検証は、まず、設計仕様に従った検証プランを作成して検証環境をセットアップします。テスト・インテントは、ポータブル・スティミュラス・モデル、制約、および構成ファイルに関して設定されます。この基準に対応したツールは、これらに基づいて所定の検証環境に合わせたテストを作成し、グラフベースのカバレッジを収集することができます。このタイプのカバレッジを分析すれば、テストの制約と構成に関する欠陥を明らかにし、プロセスを再検討できます。

PSSベース・モデルを導入した場合の検証フローを図6に示します。ここでの重要な注意点は、PSSモデルはUVMベースの環境に代わるものではないということです。PSSはUVMに代わるものではなく、既存のUVMベース環境へのアドオンとしてUVMの能力を強化します。UVM検証環境は引き続きマスタUVCとスレーブUVCを保持します。これはSVと構成についても同様ですが、UVM SVインフラストラクチャ使用時は仮想シーケンスがバイパスされます。この環境はトップ・レベルUVMテストによって制御されますが、このテストは、UVC動作を制御するために仮想シーケンスを呼び出す一方で、PLIまたはDPIベースのシステム呼び出しにより、ポータブル・スティミュラスで作成されたフォーマットと連携して動作します。PSSモデルは、SystemCベースの性能モデリング・プロセスからすべて再利用されます。PSSベース・モデルから生成されたテスト・ロジックは、UVC間のすべての動作を制御します。生成されたテストを使ってIPレベルのシミュレーションが実行され、カバレッジが収集されます。

PSSベースとUVMベースの検証環境におけるリグレッション・テストの実行結果を表2に示します。UVMベースのアプローチを採用した場合は、最大限のカバレッジを実現するために実行する制約付きランダム・テストの回数（ウェーバー使用）が大幅に減ります。PSSベースの検証のランダム化メカニズムは、DUTのハイ・レベル状態間の規則に沿った遷移を抽象化して記述することから始まり、この状態空間を通過する経路をカバーするために必要な最小限のテストのセットを自動的に列挙します。グラフベースのカバレッジによって検討経路を表示できる他、グラフの最大長さをカバーできるようにテストを作成することができます。

テスト品質は、ポータブル・スティミュラス検証法によって制御を改善できるもう1つの要素です。テストを視覚的に確認できるので、制御とデータの流れが理解しやすくなります。また、いくつかのツールには実行時にアクティブ・チェックを組み込めるので、チェックを効果的に自動化することができます。これをスコアボード・チェックおよびアサーションベースのチェックポイントと組み合わせれば、検証の品質が向上します。

ポータブル・スティミュラス法はより高い抽象化層で機能し、更に基礎となる検証プロセスと統合されます。このため、この検証方法はテスト作成やスティミュラス生成のプロセスを明らかに改善する一方で、基礎的なプロセスをオリジナルの形態で継承します。UVMベース環境と統合する場合は、検証コンポーネントの再利用による利点が得られると同時に、その複雑さが一定の範囲に止まります。同様に、UVMの場合同様、検証の品質は検証プランとカバレッジ・レポートの品質によって制限されます。

相互接続バスのSoC検証

相互接続がSoCの一部として統合されている場合は、システム内の様々なマスタおよびスレーブとの統合化をチェックすることが極めて重要です。通常、これはCベースのテストをプロセッサ上で実行し、相互接続バスの統合化をチェックすることによって行われます。IPレベルの汎用的なマスタは、マルチプロセッサ、DSP、DMAコントローラなどの特定のバス・マスタ、SPI、I²C、CANなどのシリアル・プロトコル・マスタ、およびその他多くのカスタム・マスタとカスタム・スレーブに変化します。これには、SoC内の様々なマスタとスレーブを制御するための特別なシーケンスあるいはマクロが必要です。これらのマクロやシーケンスには、通常、DMAコントローラやメモリなどのマスタからのトランザクション送受信を可能にするレジスタ・プログラミングが含まれています。このレベルでは制約付きのランダム化は行われないので、それぞれのシナリオを検討して記述する必要があります。再利用に関しては、IPレベルからのいくつかのUVMモニタを使用してプロトコルまたはスコアボードをモニタし、特定のポイントを対象にチェックすることができます。しかし、仕様の主要部分を含むテストやシーケンスを、異なる焦点でCに書き直す必要があります。

PSSベースの検証手法は、IPからSoCへのテストで再利用可能なように設計されています。SoCレベル検証におけるトラフィック・ジェネレータPSSモデルの再利用を図7に示します。IPレベルでコード化されたモデルは、SoC仕様に従い、様々なアドレス・マップに合わせて構成され、Cテストの生成に使用できます。グラフベースの制約付きランダム化によりIPレベルで記述された同じシーケンス・セットを再利用することができます。モデル内のほとんどのシーケンス（実行コード用部分を除く）は、プロセッサベース・アプリケーション用のモデルを記述する際に再利用できます。それでも、この場合の実行コードは、相互接続バス上でシングル・トランザクションやバースト・トランザクションを開始できるDMAやメモリ・コントローラなどの様々なマスタ用イネーブル・マクロとディスエーブル・マクロのすべてを含む、かなり複雑なものとなります。汎用マスタについては、SoC内の様々なマスタと統合できるように、すべて実行コードを書き直す必要があります。ツールによるランダム化を行えば、マスタとスレーブのトランザクションを複数組み合わせることができます。SoCレベルでの統合化チェック用にディレクテッド・テストを作成するための制約条件は、そのテストを視覚的な方法で表示することによって適切に管理できます。Cテストの作成後は、そのシステム固有の標準インフラストラクチャを使い、それらのテストをSoCセットアップと統合することができます。Cテストはその後にコンパイルされてプロセッサ上で実行され、トランザクションを生成します。

図7にはPSSツールによるマルチコア・テストの作成も示されていますが、これを手動で記述するのは困難です。テスト・インテントは、その異なる部分を異なるコア上で実行するように設定できるので、興味深いシナリオを作成可能です。特に、複数のバス・マスタが存在するこのケースでは有効です。この機能セットにより、異なるマスタをプログラムすることが可能になります。グラフベースの制約付きランダム・テストをSoCレベルで再現でき、シナリオを実際に記録する必要のないことも大きな利点です。テストを作成して、異なるアドレス・マップを持つ同一IPの異なるインスタンスを検査することも可能になります。これと共に、異なるIPの異なる種類のPSSモデルをSoCレベルで組み合わせれば、手動コーディングでは難しい複雑なシナリオを作成することができます。

相互接続バスの妥当性確認

顧客の仕様、使いやすさ、および受け入れテストに関わる要求事項への適合性を確認するには、妥当性確認プロセスが必要です。従来、評価用ボードには、オリジナル仕様に基づいて手動で記述されたCベースのテストが必要とされてきました。このような作業の重複は、評価用ソフトウェアに対応するCテストが生成できるPSSベースのアプローチを使用することによって、大幅に減らすことができます。

PSSベースのアプローチによる妥当性確認プロセスを図8に示します。トラフィック・ジェネレータ用のPSSモデルは、SoC仕様に従い様々なアドレス・マップに合わせて構成され、Eval-Cテストの生成に使用できます。PSSツールを使用すれば、通常は複数コア用のテストを生成することができるので、特定のシナリオをテストすることも可能です。生成されたCテストはデバッガによってコンパイルされ、JTAGのようなインターフェースを備えた評価用ボードにコードがロードされます。テストは評価用ボード上で実行でき、結果はデバッガのインターフェース上で確認できます。グラフベースの制約付きランダム化によりSoCレベルで記述された同じシーケンス・セットは、すべて再利用可能です。これに加えて、テスト・インテントの視覚的表現と制約を適用できる機能は、ディレクテッド・シナリオの作成に有効です。これは、妥当性確認プロセスにおいてテストを作成するためのユニークかつ制御可能な方法です。従来、テストの作成はすべて手動で行われていました。

この場合も、シリコン検証固有の条件に従って実行コードを書き直す必要があります。DMAやメモリ・コントローラなど、バス上にある様々なマスタの制御に使われる妥当性確認用プラットフォームの基本的ソフトウェア・ドライバは、この種の用途に使用できます。生成されたCコードも、評価用プラットフォームにも受け入れ可能なフォーマットで統合する必要があります。通常このプロセスには、ヘッダを再利用することと、書き直された妥当性確認コードからファイルを取り込んで、生成された統合コードにそれらを再利用することが含まれます。コードはこの後コンパイルされ、このレベルでテストを適切に行うことができるようにターゲット・デバッガで実行されます。

PSSツールは、通常、ポストプロセシング・アプリケーションを使ってテスト実行結果を分析する機能を備えています。結果を生成するコードの特定セグメントを使い、結果を視覚的に分析し、テストの合否を示すことができます。従来のデバッグ機能は非常に限定的なものであるため、これは妥当性確認プロセスには特に有効です。

ポストシリコン・ベースのアプリケーションでは、まだトラフィック・ジェネレータ・モデル用のCテストを再利用していませんが、Cベースのテストを行うあらゆる評価用プラットフォームに使用できることについては確信があります。実際、ポストシリコン評価用ボードにSoCベースのPSSモデルを再利用するタイプのモデルには、他のプロセッサベースのアプリケーションにおいて実績があります。この再利用は、ポータブル・スティミュラスベースのアプローチだけに固有の応用例の1つです。

まとめ

PSSベースの汎用的なトラフィック・ジェネレータを使用すれば、SystemCベースの性能解析から検証および妥当性評価プロセスまで、相互接続バス用のテストを再利用することができます。それぞれのプロセスには、統合化とインフラストラクチャの開発が必要です。しかし、このプロセスが必要なのは一度だけで、その後の応用時には再利用が可能です。再利用と共に、PSSベースのアプローチは、特定のランダム化、テスト・インテントの視覚的表現、早期のカバレッジ分析といった利点を提供し、将来的な価値を高めます。汎用性を備えたアプリケーションを作成できるので、プラグアンドプレイ型のソリューションへの可能性が開け、検証および妥当性確認のプロセスを一層促進させることが可能となります。