HOT TOPIX
連載：テスト生成と再利用性を高めるポータブル・スティミュラスその３
連載：テスト生成と再利用性を高めるポータブル・スティミュラスその３
EE Tech Focus合同会社 三橋 明城男
アクセレラ標準のポータブル・スティミュラスに関する紹介の第3回目は、スティミュラスの基本的な構成要素を考え、テスト空間をモデル化をするための要素、ポータブル・スティミュラス標準（以下PSS）として策定されている記述などについて紹介する。
標準化のアップデート
標準化はアクセレラのワーキング・グループ（PSS-WG）によって行われているが、同時にステークホルダーとなるエンドユーザを始めコンサルタント、トレーニング会社、EDAベンダ、IPベンダなど、業界を巻き込んだ議論を深め、多彩なフィードバックを得る活動も行なっている。それはDVConやDACにおけるチュートリアルや、言語仕様書の公開である。ドラフト版仕様書は2017年6月14日に「PSS Early Adopter, Portable Test and Stimulus Standard」、2018年2月28日に「PSS Early Adopter II, Portable Test and Stimulus Standard」としてリリースされ、議論の軸として用いられた。またつい先日のDACでは「PSS 1.0 Language Reference Manual」が公開され、2018年6月26日よりアクセレラのホームページからダウンロードが可能となっている。
これまでの議論の中にはポータブル・スティミュラスという名称そのものについての意見も大きく取りだたされた。実際ポータブル・スティミュラスはポータブルなスティミュラスを記述する言語ではない。もっとも1つの言語を定義し、それをシミュレーションやエミュレーション、FPGAプロトタイプなど異なるターゲット・プラットフォーム用に変換することは現実的ではない。PSSで提示しようとする手法は、テストインテントをより高い抽象度でモデル表現し、それをPSSツールが読込み、与えられたインテントが許容もしくは制約するリーガルなテスト空間を満たす複数のスティミュラスやソフトウェアコードを自動生成するフローである。生成されるスティミュラスはターゲット・プラットフォームごとにテンプレートが用意され、そこではUVMテスト環境をドライブしたり、あるいはマイクロプロセッサ上で実行されるコードとしてデザインを活性化する。なおPSSでは記述スタイルとして宣言型のDSL（Domain Specific Language）とC++のどちらの言語でも表現可能となっている。
テストインテントのモデリング
まずPSSの解説に使用するシステム例として、図1.のチップレベルの構成を使用する。赤外線センサを持ち、カメラで撮影した画像やLTE受信した画像をディスプレイに表示することが可能なシステムである。
図1. システムのチップ構成例
PSSではテストインテントを表現するための構成要素として大きく３つのオブジェクトが定義されている。それはアクション、データフロー、リソースである。
アクションはテストシナリオを構成する要素で、例えばDMA転送、LTEパケット送信、画像圧縮、エンクリプション、メモリコピーなど実際の振る舞いやオペレーションをカプセル化したモジュールを指す。モジュール単位での再利用が可能である。
アクションには通常データフローの入出力をデータタイプと共に定義し、他のアクションとのやり取りを適切に行うためのデータフロー要件を提示する。データフローには、データを記憶要素に保存し、後で取り出すことができるバッファ型と、データが生成されるに連れデータが使用・消費されるストリーム型などがある。
またアクションを実行するリソースを指定することもできる。例えばDMAチャネルが1つの場合と2つの場合とでは生成されるスティミュラス空間もスケジューリングも異なる。また特定のチャネルを他のリソースが使用できないようにロックする場合もある。
このようにデータフローやリソースのオブジェクトには、PSSツールがPSSモデルを読み込んで適切なスケジューリングを行うための制約としての役割がある。
図2. アクションの記述例
図2.はアクションの記述例である。DMAがパケットをストリーム型のデータフローとして入力し、バッファ型のデータフローとしてメモリに出力し、その際DMAチャネルを占有するという想定である。
アクティビティ・グラフ
アクションのコンテンツを表現するのがアクティビティ・グラフである。テストの例を図3.に示す。
図3. システムが画像を受信し表示するテスト例
このテストではltereceiveによりデータを受信し、それをstr2memによってメモリに書き込む。この際、データは受信しながら逐次メモリに書き込まれるため、データフローとしてはストリーム型となり、この2つのアクションは並列的に実行される。またメモリに蓄積されたデータはmem2memにより、ある一定量ごとにバッファ型のデータとして表示用のアドレスにコピーされ、そこからdisplayによって表示される。
このテストインテントをPSSのDSLで表現した部分的なコード例を図4.に示す。
図4. 図3.のテストを表現するPSS-DSL記述例
アクションは階層化が可能である。図4.の記述の中でdisplay_aというアクションは、実際にはdecode_a、stretch_a、render_aの3つのアクションによって構成されている。ここではdecodeの後にstretchが、そしてその後にrenderが順番に実行される。テスト・インテントの表現に際して、アクティビティ・グラフではさまざまな制御指示が可能である。その制御記述例を図5.に、その結果のグラフを図6.に示す。
図5. アクティビティ・グラフの制御記述例
図6. 図5.の記述に基づくテストシナリオ例
各キーワードの指示内容は以下のとおりである。
●sequence {a, b}
a →bの順番で実行される。これは明示的な指示であり、sequenceが無い場合には記述の順番で実行される。
●parallel {c, d}
cとdが並列で実行される。cとdとの間にデータフローが存在する場合もあるし独立して実行される場合もある。fork~joinのようなスケジューリングがされる。
●select {e, f}
eとfのどちらかがランダムに実行される。カバレッジ情報に基づいてPSSツールが生成することも想定される。
●schedule {g, h}
gとhのデータフロー関係やリソースなどの制約をもとに、PSSツールに可能なスケジューリングを任せる。g → h、h → gのシーケンス実行、gとhのパラレル実行など、データフローやリソースなど他の制約を満たす限り自動的にスケジュールされる。
特にschedule指示はPSSの強力な機能の1つであり、PSSツールが制約を満たしながらリーガルなテスト空間内のシナリオを自動生成してくれる恩恵を享受できる。またここに挙げた以外にも、foreach文やif〜else、repeat文など多彩な制御が記述可能である。
データフロー・オブジェクト
データフローを定義することで、実際にはPSSツールがリーガルなテスト空間を構成するための制約を定義する。図7.にはデータフローに関する記述例を示す。
図7. データフロー定義のコード記述例
データタイプとしてstruct - ストラクチャを、それを構成するフィールド要素とともに定義する。SystemVerilogと同じように、randによりランダム指定されたフィールドは、ストラクチャが使用されるたびにランダム化される。PSSのような高い抽象度ではランダム生成されるデータのコンテンツではなく、ストラクチャが重要となる。
続いて2種類のパケット、pixpkt_sとmempkt_bを、tiff_strをベースに拡張する形で定義する。前出のとおり、データフローにはストリーム型とバッファ型などがある。ストリーム型とはデータ・プロデューサがデータを生成するに連れ、データ・コンシューマがデータを消費するフローである。図3.においてltereceiveとstr2memはパラレル実行されるが、LTEが受信しながら同時にストリームをメモリに書き込むことを示す。これに対してバッファ型とはデータ・プロデューサがストレージ機能のある領域に一旦書き込み、それをデータ・コンシューマが読みに行くというフローである。図3.においてメモリに書き込んだデータはmem2memでメモリ内コピーが行われるが、これはシーケンシャルなフローでありバッファ型である。この記述を元にPSSツールがテストを自動生成すると、時間軸に対して図8.のような振る舞いが観測されることになる。
図8. ストリーム型とバッファ型のデータフロー
データフロー・オブジェクトは、テストシナリオを構成する要素として定義したアクションやアクティビティ・グラフに対して関連付けすることができる。図9.は、図3.のPSSテスト例に対してデータフロー・オブジェクトを関連付けている。
図9. アクションとデータフロー・オブジェクトをバインドしたPSSテスト例
PSSではどのアクションがどのデータフロー・オブジェクトを扱うかを、bindによって関連付けすることができる。しかしPSSによる最大の生産性は、明示的にバインドするのではなく、暗示的にPSSツールにバインドさせるところにある。複数のデータフロー・オブジェクトは宣言し、プールさせておくことができる。PSSツールはこのプールの中から該当するアクションで扱うことのできるデータフロー・オブジェクトを自動でバインドし、テストを生成させる。図2.ではstr2mem_aというアクションはpixpkt_sを入力とし、mempkt_bを出力することが定義されている。さらに各データフロー・オブジェクトはストリーム型かバッファ型かも定義されている。このルールから、PSSツールはテストシナリオを生成することができる。
さらに図3.のグラフからltereceive_aを削除してしまえば、LTEから受信した画像データではなく、カメラモジュールからの画像データや、CPUによってメモリから読み出した画像データを表示させるというテストをも、PSSツールに自動推定させることが可能である。
図9.にある明示的なバインドは、それはディレクテッド・ランダムテストとなり、ランダム化されるのは使用するパケットに限定される。もちろん、このシナリオをテストしたい場合はこれで良い。しかしPSSでは、テストしたい重要な項目を全体のシナリオの一部分として定義することで、あとはPSSツールが自動的に補完し生成してくれる。その際には、やみくもに生成するのではなく、指定されたアクションが扱えるデータフロー・オブジェクトのタイプや方向を制約とするため、リーガルなテスト空間を満たすテストが生成される。それはデータフロー・オブジェクトやアクションがランダム化されるシナリオであり、従来UVMで実現できていたトランザクション・レベルのランダムよりもはるかに抽象度が高いテスト生成手法である。
次回予告
次回は今回に引き続きテスト空間のモデル化を行うためのPSSトップレベルからの構成、リソースの概念、ターゲット・プラットフォームにおいて実行されるセマンティクスやテンプレートなどについて紹介する。
■筆者プロフィール：
三橋 明城男（みつはし・あきお）
EE Tech Focus合同会社 代表社長
半導体設計、組込みソフトウェア開発、米国EDAベンダにおけるエンジニアリング・マネージャー、マーケティング・ディレクターなどを経てEE Tech Focus合同会社を設立。現在はコンサルティングやマーケティング支援、海外の技術情報のキュレーションなどのビジネスを展開している。
｜ページの先頭へ｜