Hardware Emulationの性能を最大化するために着目すべきポイント
1.はじめに
昨今のSoC(System On Chip)開発は、微細化技術の進化により、チップに搭載可能な回路規模が増加し続けています。これは、多種多様なニーズに対応する製品機能をSoCに集約する助けとなっていますが、一方で、SoCの複雑性の増加と共にSoCの品質を確保するための検証工数も爆発的に増加しています。
また、SoCを含むシステムとして考えると、更新し続ける通信及び映像等の規格への追従や、膨大なソフトウェア(以降、SW)を組み合わせてシステムとしてSoCの品質を保証するには、従来の論理検証だけでは不十分となっており、SoC外部の周辺モデルやSWと組み合わせて動作させる検証シナリオが必要になっています。そして、このような大規模なシステム全体を動作させる検証シナリオは、シミュレーションでは長大な時間がかかります。
ケイデンスでは、このような検証パタンの増加及び長時間化の対策の1つとして、エミュレータの活用を提案しています。エミュレータの活用により、テストの実行時間を短縮し、製品開発のタイトなスケジュールの中で、大量かつ長大な検証を可能にします。
しかし、エミュレータを利用しても、エミュレータの性能を十分に活かす適切な検証環境を構築しなければ、検証効率を劇的に向上させるメリットを享受することはできません。
そこで、本稿では、実行時間の短縮にフォーカスし、シミュレーション環境をエミュレータに移植する際に、エミュレータの性能を最大化するために着目すべきポイントを紹介します。
以下のような方に理解して頂きたい内容です。
- エミュレータを使ってシミュレーション環境を高速化したい方
- エミュレータを使っているが使いこなせていないと感じている方
- エミュレータを使いこなせていると考えている方(再確認の目的)
2.シミュレーション環境をエミュレータに移植した場合に何が起きるか
まず、シミュレーション環境にあまり手を加えることなくエミュレータに移植すると、どのような特長を持ったエミュレーション環境になるかについて説明します。
一般的なシミュレーション環境は、検証対象であるデザイン(DUT:Design under Test)と、DUTを検証する為の仮想環境であるテストベンチ、に分けることができます。デザインは、最終的に回路に実装されるため、論理合成が可能であり、エミュレータへ実装できます。一方、テストベンチは、DUTの制御や観測を行うための論理が実装されており、論理合成可能なHDL記述と論理合成できない様々な記述が混在しています。
この説明では、環境構築の手間を最小限に抑え、シミュレーション環境からエミュレータで実行する環境を作ることを前提に、DUTをエミュレータに実装し、テストベンチをシミュレータ側に配置します。
このように環境を構築すると、図1のエミュレータとシミュレータが共存する環境ができます。エミュレータに実装したDUTと、シミュレータ上で動作するテストベンチが信号レベルで接続された環境です。このような環境は一般的に、SBA:Signal Based Accelerationと呼ばれます。
図 1 エミュレータとシミュレータが共存するSBA環境
この図1のSBA環境では、シミュレーション環境からエミュレータに移植したことによる実行時間短縮の効果は、元々のDUTとテストベンチの構成や検証シナリオに応じて異なります。
例えば、DUT内部の処理が非常に重い (演算量が多い、イベントが多数発生している)、もしくはDUTとテストベンチのやり取りが少ない環境や検証シナリオの場合は、図1のようなエミュレータの利用方法でも、エミュレーション環境での実行時間は、シミュレーションの実行時間よりも大幅に短縮されます。
一方で、効果が少ないケースもあります。例えば、DUTの処理が軽い(回路規模が小さい、検証シナリオが短い)、もしくはDUTとテストベンチの信号接続が多く、信号が頻繁に変化している場合は、シミュレーションと実行時間が変わらないか、場合によっては遅くなってしまうこともあります。このようなケースでは、何故、エミュレータの実行速度が上がらないのか、次の章で説明します。
3.シミュレータとエミュレータの実行時間の違い
エミュレータで実行速度が上がらないケースで何が起きているかを知って頂くために、まずは、シミュレーション環境とエミュレーション環境のそれぞれの実行時間の要素の違いについて説明します。
シミュレーションの実行時間は、図2のようなイメージになります。
図 2 シミュレーション時間の要素
この図はあくまで処理フローを表すイメージです。横軸が実行時間で、緑がテストベンチの処理、オレンジがDUTの処理を表しています。処理の流れは以下です。
① テストの先頭では、テストベンチが動作
② DUTが動作
③ DUTが動作した後、テストベンチ側の処理が発生
このように、DUTの処理とテストベンチの処理が繰り返される形となります。実際には、シミュレータでは、DUTとテストベンチが分け隔てなく動作しているため、マルチスレッドが可能なインフラ環境では、DUTとテストベンチの処理が並列実行される期間も発生することがあります。ここでお伝えしたい点は、シミュレータでは、DUTとテストベンチの処理に境界はなく、処理が連続している点です。
一方、エミュレーション環境での実行時間は、図3のようなイメージになります。
図 3 エミュレーション時間の要素
図3はエミュレーションの時間の要素とその処理の順番を表すイメージ図です。テストベンチの処理はシミュレータが行います。DUTの処理はエミュレータが行います。シミュレーションと異なる点として、テストベンチの処理と、DUTの処理の境界に、シミュレータとエミュレータの同期があります。処理の流れは以下です。
このように、エミュレーション環境では、シミュレータで動作する部分と、エミュレータで動作する部分のやり取りに、同期が発生します。
図2と図3のそれぞれのテストベンチの処理時間/DUTの処理時間/シミュレータとエミュレータの同期時間をそれぞれ加算して比較すると、図4のようになります。
図 4 シミュレーションとエミュレーションの実行時間の比較(1)
エミュレーション環境では、エミュレータによりDUTの実行速度が上がり、DUTの処理時間は短縮されます。一方で、シミュレータとエミュレータの同期時間が追加されます。
2章で前述した、DUTをエミュレータに実装し、テストベンチをシミュレータで実行する構成で、しっかり効果が出るケースは、例えば実行時間の割合が図5のような場合です。
図 5 シミュレーションとエミュレーションの実行時間の比較(2)
テストベンチの処理とDUTの処理の時間の割合に着目すると、テストベンチの処理時間が少なく、DUTの処理時間の割合が多い場合に、図5のような効果を得ることができます。また、シミュレータとエミュレータの同期時間が短い、つまり同期の発生回数が少ない場合も、同様の効果を得ることができます。
シミュレーション環境のエミュレータへの移植においては、テストベンチの処理時間と、シミュレータとエミュレータの同期時間の2つを減らすことが、エミュレーション実行時間の短縮につながります。
4.シミュレーション環境からエミュレーション環境への移植で注意すべきポイント
シミュレーション環境に手を加えることで、テストベンチの処理時間と、シミュレータとエミュレータの同期時間を減らし、実行時間を短縮する方法をご紹介します。
シミュレーション環境をエミュレータに移植して高速化を目指す際に、注意すべきポイントは、主に2つあります。
- テストベンチの処理を極力エミュレータに持って行く
- シミュレータとエミュレータの同期の回数を減らす
この2つポイントを押さえるために、シミュレーション環境で実施する修正は、以下になります。
- クロック生成をエミュレータ側に移動
- テストベンチの処理をエミュレータ側に移動
- シミュレータとエミュレータの境界をトランザクションレベルに変更
以下、それぞれの内容について説明いたします。
4-1.クロックをエミュレータ側に移動
シミュレーション側のテストベンチで生成したクロックがエミュレータ側のDUTに接続していると、クロックの変化に応じて同期が発生します。クロックのエッジ毎に発生する同期は、実行時間への影響が非常に大きいため、クロック生成はエミュレータ側に持って行くと効果的です。手順は以下になります。
- DUTの上位にもう一つ、エミュレータに実装するテストベンチの階層を作成 (以降、Emu階層)
- テストベンチ上のクロック生成記述を、モジュールとしてEmu階層にインスタンス
図6は上記手順を図示したものです。
図 6 エミュレーション性能を最大化した効果
クロックをモジュール化し、Emu階層にインスタンスすると、クロックモジュールとDUTのやり取りはエミュレータ上で行われるため、同期は発生しません。そのため、同期回数を大幅に削減することができます。
弊社では、クロックの仕様を定義したファイルから、エミュレータ上にクロックモジュールを生成するユーティリティを提供可能です。このユーティリティを用いることで、非同期クロックが多数存在する複雑なクロック構成でも容易にモジュール化して利用することができます(ご興味のある方は是非、お問合せ下さい)。
4-2.テストベンチの処理をエミュレータ側に移動
一般的にテストベンチには、DUTを制御する機能やDUTやテストベンチの挙動を観測するデバッグ機能がtaskやfunctionとして作られます。テストベンチの処理時間短縮のために、これらのtaskやfunctionを、極力エミュレータに持って行く方法を説明します。手順は以下になります。
- テストベンチ上に存在する処理を論理合成可能な処理と論理合成できない処理に分類
- 分類した論理合成可能な処理を、Emu階層にインスタンス
図7は上記手順の一例を図示したものです。テストベンチにA/B/X/Yの4つのtaskがあった場合、その記述を確認して論理合成可能か不可能かで分類します。例えば、task X/Yが合成可能な記述だった場合、作成したDUTの上位にあるEmu階層にtask X/Yを移動することでtask X/Yはエミュレータで実行させることができます。
task X/YとDUTの処理が、エミュレータで実行されると、その分、実行速度の向上につながります。
図 7 合成可能なものをエミュレータ側に
弊社のエミュレータでは、ビヘイビア記述で書かれたモデルは多くの場合で合成可能なだけでなく、SVA(SystemVerilog Asssertion)のアサーションやファンクションカバレッジ等も記述により合成可能です。ビヘイビア記述で書かれたモジュールやSVAのアサーションを、一度、Emu階層にインスタンスしてコンパイルをお試し頂くと、合成可能な記述との切り分けを容易に行うことができます。アサーションカバレッジは、シミュレーション実行で取得した結果と、エミュレーション実行で取得した結果をマージすることも可能です。
また、デバッグの為に使用する$displayや$fdisplayの記述も、同様にEmu階層に含めることができます。これらのシステムタスクは弊社独自のGFIFOと呼ばれる機能を使用することで、エミュレータの実行を遅らせることなく、標準出力への表示やログファイルへの出力を実現します。
4-3.シミュレータとエミュレータの境界をトランザクションに変更
シミュレータとエミュレータの境界を、信号レベルのやり取りから、トランザクションレベルのやり取りに変えることで、同期の発生回数を削減し、同期時間を短縮することができます。DUTとテストベンチの間の制御信号やデータ、アドレス・データの信号等をクロック・サイクルでやり取りするのではなく、以下の手法を用いて、ひとかたまりのデータとして受け渡しすることで、同期回数を削減します。
- DPI-CによるC/C++とのやりとり
- taskやfunctionの相互呼び出し
- SCE-MI DMIによるメモリの読み書き
- SCE-MI Pipeによるデータ転送
このように環境を構築しますと、図8のように、テストベンチとEmu階層の間をトランザクションレベルでやり取りする環境ができます。トランザクションを利用したエミュレーション環境は、一般的にTBA:Transaction Based Accelerationと呼ばれます。
図 8 SBAからTBAへの変更
SBAからTBAに変えることで、同期回数を削減し、エミュレータの実行時間をさらに短縮することができます。SBAからTBAへの書き換えについて、弊社では各種TBAインターフェース技術の蓄積があり、お客様のニーズにより最適なテストベンチ構成の提案やトレーニングが可能です。
また、弊社ではエミュレータに実装可能な、各種のインターフェース規格のモデル(AVIP:Accelerated Verification IP)を用意しております。AVIPは、DUTの対向となる動作を実現し、インターフェースプロトコルの妥当性確認を行うことができます。また、AVIPは、エミュレータ側に実装する部分と、シミュレータ側に配置する部分と、その間のデータのやり取りを高速に行うように最適に設計されたインターフェースを有します。そのため、テストベンチとEmu階層を、AVIPを介して接続することで、SBAからTBAへの変更と、テストベンチとEmu階層の間の高速なデータのやり取りを実現することができます。
5.まとめ
ここまでの説明をまとめますと、図9のようになります。
図 9 エミュレーション性能最大化のための対策まとめ
これらの改善を加えることで、図10の様にエミュレーション環境での実行時間の短縮効果を最大化することができます。
図 10 エミュレーション性能を最大化した効果
検証環境構築の初期段階で、シミュレーション環境をエミュレータへ移植することを視野に入れ、よりテストベンチの処理が少なく、シミュレータとエミュレータの同期の発生が少ない検証環境を考えて頂くことが重要になります。
これまで説明してきたようなポイントに注意して、エミュレータの性能を最大化する検証環境を構築することにより、シミュレーションでは諦めていた長時間の検証シナリオの実行が可能になる為、劇的な検証効率の向上につなげることができます。
本稿に記載の内容に興味を持たれた方は、弊社営業までご連絡頂ければと存じます。
フィールドエンジニアリング&サービス本部
システム&ベリフィケーション リードAE
冨田 裕信
Archive
2023 Issues
2022 Issues
2021 Issues
2020 Issues