FPGAの検証に対するテストベンチの考察（Design and Verification LANDSCAPE　2022-Vol2）

2023/05/12

はじめに

FPGAの検証において、テストベンチやテストスティミュラスの作成は大きな課題である。図1.は2020年にワールドワイド規模で行われたWilson Research Groupによる市場調査の一部であり、「検証において最も大きな課題は何か？」という設問における解答の分布を示したものである。

図1. WRG : 2020 Functional Verification Study - 検証の最大の課題

2012年から2020年に至る5回のすべての調査で、「デザインを検証する充分なテストの作成」という課題が圧倒的である。図1.のグラフはFPGA開発プロジェクトが母集団だが、この傾向はASICプロジェクトでも本質的には変わらない。

検証の生産性

図1.において最も多かった課題である「デザインを検証する充分なテストの作成」について、検証の生産性の課題に照らし合わせて考えてみる。そこで図2.の設計生産性のギャップと検証のギャップについて見てみる。

図2. 設計生産性のギャップと検証のギャップ

図2.のグラフは主に1990年代にさまざまな論文や記事、講演スライドで引用されたものである。微細化技術の進化により使用可能なシリコン規模が増大するものの、それを活かしきれるだけの設計能力が追従するか、あるいは設計したデザインを検証する能力が追従するかという問題を提起している。このグラフから学ぶべきことは、青い線の「設計能力」は、赤い線の「使用可能なシリコン」にかなり追従しているということであろう。少なくとも緑の線の「検証能力」と比べると、かなり追従できていることが表現されている。「設計能力」の追従性を押し上げている有力な要因は設計資産の再利用の促進、標準規格（USBやPCIe、Ethernet、DDRなど）に基づく設計IPの流通がある。また1990年代後半以降はAMBAなどのバスが出現し、バスファブリックを中心としたバスベースによる設計容易化も寄与している。

その一方で「検証能力」について見ると、1990年代には検証労力を資産として再利用するための標準的な手法が存在しなかった。しかし2000年代に入るとIEEE Std. 1850 - PSLやIEEE Std. 1800 – SystemVerilog、IEEE Std. 1800.2 – UVMなどの標準化が進んだことで、検証を自動化し、そして検証に費やした労力を高価値かつ低リスクの検証資産として活用する動きが加速している。

検証資産と再利用性について

検証資産となり得る候補を列挙すると、そこにはテストベンチ、テストシナリオ、アサーション、カバレッジ定義などさまざまなものがある。この中で検証資産化が比較的容易で再利用しやすいものは、アサーションとカバレッジであろう。

アサーションはデザイン中のさまざまな部分に直接記述したり、あるいはアサーションを記述した外部ファイルをデザインにバインドしたりすることで使用する。例えばブロック間のハンドシェイクやインタフェースのプロトコルをプロパティで記述し、それをアサーションとしてバインドすることで、シミュレーションを実行するたびにプロトコルが守られているかどうかをチェックする。テストベンチに依存せず、デザインに対しても局所的な記述であるため、検証資産として再利用することが容易であり、設計資産とアサーションを併せて再利用することも多い。
Design and Verification LANDSCAPE　2021-Vol1　アサーション検証のすすめ〜パート2 – アサーション再利用
で解説されているため、併せて参照していただきたい。

またカバレッジ定義とはツールが自動的に収集可能なコードカバレッジではなく、ユーザ定義の機能カバレッジを指す。IEEE Std. 1800 – SystemVerilogではCover Group / Cover Point / Cover Binと階層的にモデル化し、それぞれが取り得る値やシーケンスが何回活性化されたかをカウントする仕組みをモデリングすることができる。プロトコルが取り得るコマンドの中で一度も実行されたことのないコマンドはないか、などの抜け漏れを知ることができるし、検証に対する統計的な情報を得ることもできる。このカバレッジ定義はテストベンチの一部として、極めて再利用性が高い。また機能カバレッジはテストベンチの一部として活用されることが多い。

テストベンチやテストシナリオについて見てみるとIEEE Std. 1800.2 – UVMが世界中のFPGAプロジェクトの50%以上において採用されており、主流となっている。特にテストベンチについては再利用性が極めて高く、さまざまな検証IPを活用するためのインフラとなっている。図3.にUVMのテストベンチ例を示す。

図3. UVMのテストベンチ例

UVMではテストベンチが構造化されており、それぞれのコンポーネントの役割や接続方法、同期のメカニズムが標準化されている。MonitorとDriver、Coverageを中心とした検証コンポーネントはエージェントと呼ばれ、特定プロトコルで定義されるコマンドなどの抽象度（トランザクションレベル）でテストを駆動したり、また対象デザインの反応を監視したりすることができる。これが検証IP（VIP）の基本的な機能になる。
UVMと検証IPについては Design and Verification LANDSCAPE　2021-Vol2　検証資産の再利用 – Verification IP
で解説されており、併せて参照していただきたい。

ここで改めてテストベンチとテストシナリオについて考えてみると、テストベンチはテストをする環境であり構造である。検証をどのように行うか、つまり「How」に相当する。多くは検証IPを準備することで構築することが可能である。一方でテストシナリオは、テストベンチを介してデザインを活性化し、何をテストするのか、つまり「What」に相当する。図4.にUVMを用いたIPブロックの検証構成と、複数のIPブロックによるクラスタを検証する際の検証構成について示す。

図4. UVMによるIPブロック検証とクラスタ検証

UVMではUVM Sequenceによってテストシーケンスを表現する。UVM Sequenceが検証IPを介して検証対象を駆動する。図4.の左側に示されるブロック検証では至って単純であるが、図4.の右側にある複数ブロックから構成されるクラスタを検証する際には、複数のUVM Sequenceを束ねるUVM Virtual Sequenceが必要になる。この例ではIP2に用いる検証IPはパッシブモードと呼ばれる使い方をしており、駆動はせずに観測のみを行っている。UVM SequenceやUVM Virtual Sequenceの部分はテストシナリオであるが、検証IPがプロトコル固有であるのに対して、テストシナリオはデザイン固有となる。検証対象により多くの設計IPが含まれるようになると、それに合わせてUVM Virtual Sequenceによるテストシナリオは非常に複雑になる。図5.を見ると、そのテストシナリオ指定がスケールしないことが分かるであろう。図5.ではすべての設計IPはBUF IFを介して設計されているが、すべての設計IPの状態を考慮したUVM Virtual Sequenceを記述することはまず不可能であり、またせっかくCコードでデザインが駆動できるにも関わらず、UVMとCコードは完全に乖離している。

図5. UVMによるマルチコアSoCの検証環境

つまり検証の「How」は再利用できるのだが、「What」に関する仕様が複雑化してしまう。またこのレベルになるとシミュレーションのみではなくFPGAプロトタイピングやFPGAボードも用いるプロジェクトが多くなるが、その環境もUVMとはまったく乖離しており、ほぼ何も再利用することなく、ゼロから検証環境を作り直すことになる。

テストシナリオに関する新標準

半導体設計のプリシリコンにおける設計と検証のための標準化団体であるAccellera Systems Initiativeではテストシナリオのスケーラビリティの課題を解決すべくPortable Stimulus Working Groupを2015年に組織化し、標準化を推進している。標準の名称は「Portable Test and Stimulus Standard」であり、PSSと呼ばれている。

PSSではテストシナリオ自体を再利用するのではなく、PSSツールがテストシナリオを自動生成する。そのPSSツールへの入力はテストインテントであり、テストインテントを一度定義すると、PSSツールはUVM環境用のテストシナリオ、SoC向けのCコードとそれに同期するUVMテストシナリオ、あるいはFPGAプロトタイピング用のテストシナリオなどを生成することができる。ここで簡単にPSSの考え方について見てみる。

図6. 圧縮伸長のエンジンへのテストフロー

図6.において楕円で示されているものは「action」と呼ばれるもので、動作を簡潔に記述するものである。また点線矢印で示されるものは「dataflow」と呼ばれる。以下に各actionについて説明する。

Comp/Decomp 画像の圧縮伸長エンジン
DMA Xfer DMAによる転送
mem copy プロセッサで実行されるメモリのコピー操作
UART receives UARTからのデータ受信
Modem receives Modemからのデータ受信

このactionとdataflowによるフローチャートでは、リーガルなテスト空間が定義される。このテスト空間を満たすようなテストシナリオを図7.に示す。

図7. リーガルなテスト空間を満たすテストシナリオ

ここでそれぞれのテストシナリオについて見てみる。

Test1 Modemが受信したデータをプロセッサが別メモリにコピーし圧縮／伸長する
Test2 UARTが受信したデータをDMA転送し圧縮／伸長する
Test2 Modemが受信したデータをDMA転送し圧縮／伸長する

それぞれのactionの定義は検証対象のハードウェアに依存する。ここではUARTやModemはもちろん、プロセッサやDMAチャンネル、圧縮／伸長エンジンがリソースとして存在する。例えばDMAチャンネルが２チャンネルあれば並列処理が可能となり、リーガルなテスト空間も異なるものとなる。UARTの処理がデータを一時保管するバッファタイプではなく、逐次処理しては出力するストリームタイプであれば、UART受信とDMA転送が並列に動作するようなテスト空間となる。このようにハードウェア上の制約をactionやdataflowと併せて定義することでテストインテントを構成する。そしてこれを入力とするツールフローは図8.のようになる。

図8. PSSツールによる検証フロー

この図にはフロー（１）とフロー（２）が存在する。（１）ではPSSツールによってテストシナリオが自動生成されるが、そのテストが参照する先はUARTやAXIなどのUVM検証IPである。その連携の仕方はPSSツールがオフラインでテストシナリオを生成し、生成したファイルをシミュレータに渡す方法と、PSSツールとシミュレータが同期しながらテスト生成とシミュレーションとを同時に進める方法がある。またフロー（２）ではUART部分についてはフロー（１）のテスト資産を再利用しながら、プロセッサに実行させるCコードを生成する。このプロセッサ上の実行はUVM実行と自動的に同期させることができる。

UVMの検証IPをドライブするUVM SequenceとCPUコアで実行するC-testとを分けて実行させる仕組みはPSSのプリミティブなactionに対するEXECブロックと呼ばれるところで指定する。この部分にFPGAボードで供給するテストシナリオのコードを指定すれば、一度テストインテントを記述すれば、そこからシミュレーション用のテストシナリオもFPGAボード用のテストシナリオも生成することが可能になる。

まとめ

設計生産性を上げるために設計IPの流通が大きく貢献してきた。それに続いて検証生産性を上げるべく検証労力が問題なく資産化できるためのメカニズムとしてUVMがIEEE標準化され、結果として検証IPが流通するようになってきた。検証IPは検証の「How」である部分として検証生産性向上への寄与が明らかになっている一方で、検証の「What」について検証生産性を向上させるべく、AccelleraではPSS標準化が進んでいる。言語仕様として「Portable Test and Stimulus Standard 2.0」がリリースされている。

PSSは先進的な企業では、すでに採用が始まっている。DVCon Japan 2022においてもSamsung Electronicsによる論文発表があった。PSSによって簡単に数多くのテストシナリオを生成させ、それを機械学習させることで特定の規則性を見出し、通常のテストシナリオでは困難なハードウェア機能の同時発生条件を簡単に作り出し、カバレッジを簡単に上げることに成功している。今後もPSS準拠の検証IPやさまざまなEXECインタフェースが開発され流通することが期待されている。