連載：テスト生成と再利用性を高めるポータブル・スティミュラスその４

連載：テスト生成と再利用性を高めるポータブル・スティミュラスその４

アクセレラ標準のポータブル・スティミュラスに関する紹介の第4回目は、テスト空間をモデル化をするためのPSS記述におけるリソースの考え方、トップレベルへの構成の仕方、ターゲット・プラットフォーム上で実行される実行セマンティクスなどについて紹介する。なおこの連載の最終回となる。

今回も前回と同じく図1.のチップレベル構成を前提とする。赤外線センサを持ち、LTE受信した画像やカメラからの画像をディスプレイ表示することが可能なシステムである。

図1. システムのチップ構成例

PSSにおけるリソース指定

前回はテストインテントを表現するための構成要素としてとアクション、アクティビティ・グラフとデータフロー・オブジェクトを紹介したが、もう１つの構成要素がリソースである。リソースでは実際にシステムで使用可能なリソース上で実行される所望のシナリオを生成させる制約を指定する。例えばDMAがテスト対象のシステム内に存在する場合、DMAチャネルが1つの場合と2つの場合とではリーガルなテスト空間が異なり、PSSツールがスケジューリングするシナリオも異なる。

図2. リソースとそれに関連するPSS構文

図2.に、リソースに関連するPSSの構文を示す。PSSにおけるリソースは、特別な意味を持つstructタイプである。リソースは複数存在する可能性があるため、アクションに割り当てることのできる同じタイプのリソースを一つないし複数個プールしておく。図2.でのsizeはプールされるリソースの個数であり、デフォルトでは1である。このようにプールすることでPSSツールは同時にいくつまでのリソースが使えるかをスケジューリングすることができる。またリソースは複数存在させることができるため、宣言とともに特別なinstance_idというビルトインの属性が付与され、指定したプール内のリソースごとに一意的な識別が可能である。

リソースのロックとシェア

アクションが特定リソースへの排他的アクセスを必要とする場合、リソースをロックすることができる。または共通のリソースを複数のアクションでシェアすることもできる。図3.はリソースのロックやシェアに関するPSS構文の例を示したものである。

図3. リソースのロック／シェアに関するPSS構文

ここではまずchannel_rというリソースを定義し、そのリソースを2つ、channel_pという名称でプールしている。そして、このプールに対していかなるアクションともバインドできることを＊で示している。locking_chan_aというアクションではchannel_rリソースをロックし、sharing_chan_aというアクションではchannel_rリソースをシェアしている。

図4.に、locking_chanというアクションのパラレル実行の考察のための図を示す。

図4. チャネルをロックするアクションの並列動作

基本的なルールとして、1つのリソースを2つ以上のアクションが同時にロックすることはできない。処理が終わりリソースが解放されるまでロックは継続される。図4.では同じリソースをロックするlocking_chanアクションが２つパラレル実行されるが、リソース・プールにはチャネル・リソースが2つプールされているため、このグラフは問題なく成立する。ただし、それぞれのアクションがロックしているリソースのinstance_id フィールドの値は異なる。またこの状態で3つめのアクションはリソースをロックすることはできない。

図5. 2つのチャネルのシェアと1つのチャネルのロックの並列動作

図5.では、同じチャネル・リソースをシェアする2つのアクションおよび1つのチャネル・リソースをロックするアクションがパラレルで実行される様子を示す。リソースのシェアとは、複数のアクションが同一インスタンスのリソースを共有することを示す。図5.においてはsharing_chan_1が2つ存在するが、この際付与されるリソースのinstance_idは同一である。またlocking_chan_2は異なるinstance_idとしてロックし、アクションがリソースを占有する形になる。図5.の状態で新たなsharing_chan_1のアクションが追加されたとしても、それは問題とはならない。

ここで図1.のシステムチップ例を用いて、LTEから受信した画像データをDMAコントロールによってメモリに格納後にディスプレイ表示するテストシナリオと、メモリに格納されたデータをDMAコントローラによってLTE送出するテストシナリオが同時に発生し得るかどうかを見てみる。図6.はこの2つのテストをパラレルで実行するグラフである。

図6. tiff_rcv_display_testとtiff_sendout_testのパラレル実行グラフ

このグラフが示すようにstr2memアクションとmem2strアクションの両方がchan_pチャネルをロックしている。もしチャネルが1つしかプールされていなければ、このテストは成立しないシナリオとなる。チャネルが2つ以上プールされていれば、異なるstream_idが付与され、それぞれがロック可能であるため、このテストは成立する。

このようにアクションによるリソースのロック指定やシェア指定は、PSSツールがリーガルなテストシナリオを生成する際の制約になるばかりでなく、スケジューリングが不可能なリソース競合などを、テストシナリオ生成前にチェックできることも期待される。

コンポーネント化

システムのテストシナリオをPSSツールに生成させるにしても、例えばDMAコントローラが使用するアクション、データフロー・オブジェクト、リソース・オブジェクトなどはまとめておくと、再利用がしやすく理解しやすい。そのための単位がコンポーネントである。

図7.にトップであるpss_topとそこにまとめられたコンポーネントの記述を示す。DMAコントローラが扱うリソースや、str2mem、mem2str、mem2memなどのアクションがまとまっている様子が分かる。テストの対象となるシステム内の設計としてのDMACとは直接的な関係はないが、テストシナリオを構成する中でもDMACの振る舞いに関するものであり、コンポーネント化することには大きな意味合いがある。

図7. PSSコンポーネント記述例

DMACコンポーネントでは、dmachan_rとしてDMAチャネルをリソース指定し、チャネルを1つプールしている。bind文により、プールされたチャネル・リソースに対して、ワイルドカード（＊）を用いて、すべてのアクションがアクセスできることを指定している。

この例でも分かるように、コンポーネント化は階層的な記述が可能である。図7.の記述にはないが、pss_topの直下にもリソースやプールなどを記述することで、テストのトップで使用されるオブジェクトを指定できる。またSystemVerilogと同じように、名前空間の概念が適用されており、スコープ解決演算子 :: によって特定のコンポーネントが持つアクション、データフロー、リソースなどのオブジェクトにアクセスしたりバインドすることができる。例えばpss_topからはdmac_c::str2mem_aとすることで参照できる。

またpss_topではインスタンス化するコンポーネントの他、コンポーネントがアクセスするオブジェクトをプールし、バインドすることで、トップ下のコンポーネントとやり取りすることができる。

このようにコンポーネント化を行うことでPSSのモデリングを検討する際にもコンポーネント単位で注力することができ、そして他のコンポーネントと組み上げていくことで、ブロックレベルからシステムレベルのどの段階でもテストシナリオをPSSツールに生成させることができる。再利用性を高める面からも推奨される記述方法であると言える。

実行テンプレート

ここまでPSSモデリングについて説明してきたが、最終的にはターゲット・プラットフォームで実行が可能な実装へとマッピングしなくてはならない。アクションの階層においてリーフレベルに相当するところ部分である。この部分はこれまで示してきたようにPSSツールに自動生成させることはできない。CやSystemVerilog言語で動作を定義したターゲット・テンプレートを用意し、この実行コードをアクションに関連付ける。UVMであればシーケンスやバーチャル・シーケンスとの関連付けとなる。図8.ではSystemVerilogのターゲット・テンプレートの記述例を示している。

図8. ターゲット・テンプレート記述例

アクション記述の中で、execを使用する。これは前出のアクティビティ・グラフ記述と排他的であり、activityとexecを同時に持つことはできない。3つのダブルクォート """ に挟まれた記述はPSSではなく、この場合はSystemVerilogになる。shoot_imageの動作は外部SystemVerilogのファイルで定義されており、この先はSystemVerilogの世界となる。またexec body部分はCコードで記述することもできる。

SystemVerilogやCなど、PSSとは異なる言語に対して、PSSで使用しているフィールド値を渡す方法が図8.にある {{ ... }} という書式である。これは人の口髭に似ていることからMustacheテンプレートと呼ばれ、他の多くの言語で用いられている変数のエスケープと展開方法である。実際に実行されるSystemVerilogやCコードのpixpkt.size部分に、PSSで得られたフィールド値を渡して実行することができる。

これとは逆に、SystemVerilogやCで記述された定義をインポートしてからexecを実行する方法もある。この場合にはMustacheは使用することなく、PSS変数やフィールドをそのまま使用する。

まとめ

PSSでは、アクションやアクションが取り扱うデータタイプを定義し、部分的なテスト・インテントを記述すれば、プールされたデータフロー・オブジェクトやリソース・オブジェクトに対するバインディングを制約として、リーガルなテスト空間を満たすテストシナリオをPSSツールが自動生成してくれるという大きなメリットが得られる。今回扱うことのできなかった項目の中には、ステートフロー・オブジェクト、コンストレインツ、カバレッジ、パッケージなど、数多くのトピックがあるが、PSS標準がもたらす一番大きなメリット、導入のための概念はお伝えできたのではないかと思う。現在は言語仕様としてV1.0がリリースされている。是非アクセレラのホームページからダウンロードし、確認していただくことを推奨したい。

■筆者プロフィール：

三橋明城男（みつはし・あきお）

EE Tech Focus合同会社代表社長

半導体設計、組込みソフトウェア開発、米国EDAベンダにおけるエンジニアリング・マネージャー、マーケティング・ディレクターなどを経てEE Tech Focus合同会社を設立。現在はコンサルティングやマーケティング支援、海外の技術情報のキュレーションなどのビジネスを展開している。