Zynqベースの設計の協調シミュレーション

ザイリンクスのZynq7000やZynqUltraScale + MPSoCなどの異種システムオンチップ（SoC）デバイスは、高性能の処理システムと最先端のプログラマブルロジックを組み合わせたものです。この組み合わせにより、システムを設計して最適なソリューションを提供できます。ユーザーインターフェイス、通信、制御、およびシステム構成は、プロセッサシステム（PS）によってアドレス指定できます。一方、プログラマブルロジック（PL）を使用すると、低遅延で決定論的な機能と、画像処理や産業用アプリケーションで使用されるような並列性を活用する処理パイプラインを実装できます。

PSとPL間の通信は、いくつかのメモリマップドインターフェイスによって提供されます。これらのインターフェースは、Advanced eXtensible Interface（AXI）を使用して、各方向でマスター通信とスレーブ通信の両方を提供します。

図1. PSとPL間のAXIインターコネクトを示すZynqアーキテクチャ（出典：ザイリンクス）

設定および制御機能がPSによって実行される場合、PSからPLへの汎用AXIマスターインターフェイスが使用されます。これにより、ソフトウェア（SW）がレジスタを構成できるようになり、PL内のIPコアの望ましい動作が可能になります。より複雑な操作では、さらなる処理または通信のために、PLからPSメモリ空間に大量のデータを転送したい場合があります。これらの転送では、高性能のインターフェースを利用するため、構成と使用にはかなり複雑なソフトウェアが必要になります。

PSとPLの間の相互作用を検証することは、設計チームに課題を提示します。 2015年のEmbeddedMarkets Surveyは、エンジニアリングチームが直面する主要な設計上の課題の1つとしてデバッグを特定し、さらに改善されたデバッグツールの必要性を特定しました。バス機能モデルは最初に使用できますが、これらのモデルは単純化されていることが多く、開発されたSWドライバーとアプリケーションを同時に検証することはできません。全機能モデルが利用可能ですが、これらは法外に高価になる可能性があります。異種SoC設計を実装する場合、PL要素とPS要素の両方を可能な限り早い時点で一緒に検証できるようにする検証戦略が必要です。

従来、検証は最初、設計の各要素（機能ブロック）に対して個別に実行されていました。すべてのブロックを一緒に検証することは、最初のハードウェアが到着したときに行われます。 PSで実行するアプリケーションを開発するソフトウェアエンジニアリングチームは、Linuxカーネルにその使用をサポートするために必要なすべてのモジュールが含まれ、正しいデバイスツリーブロブがあることを確認する必要があります。これは通常、ハードウェア仮想化を実行する無料のオープンソースホスト型ハイパーバイザーであるQEMU（Quick Emulatorの略）を使用して検証されます。

一方、PL設計を正しく検証するために、ロジック検証チームは、アプリケーションソフトウェアによって発行されるようなコマンドを生成およびシーケンスして、ロジックが必要に応じて機能することを検証する必要があります。ただし、これらのアプローチはどちらも、ソフトウェアとハ​​ードウェアの実際の相互作用をキャプチャしないため、この相互作用に関連するエラーの検出が非常に困難になります。これにより、開発スケジュールが遅れ、開発プロセスの後半で発生した問題の対処と修正に常に費用がかかるため、開発コストが増加します。

中間ステップのように開発ボードを使用して、最終的なハードウェアが到着する前にHWとSWの相互作用を確認することができます。ただし、実際のハードウェアでのデバッグは複雑になる可能性があり、ハードウェアに追加のインストルメンテーションロジックを挿入する必要があります。インストルメンテーションロジックを含めるためにビットファイルを再生成する必要があるため、この挿入には追加の時間がかかります。もちろん、この実装の変更は、設計の基本的な動作にも影響を与える可能性があり、それによって問題をマスクしたり、デバッグビルドでのみ明らかになる新しい問題を導入したりします。

したがって、協調シミュレーションを使用してSWとHWの両方の設計を検証できることには、いくつかの重要な利点があります。開発サイクルの早い段階で実行でき、開発ハードウェアが到着するのを待つ必要がないため、デバッグのコストと影響を削減できます。さらに、このようなアプローチは、PSとPLの間のレジスターと相互作用に関してより多くの可視性を提供し、これらすべてがプロセスの早い段階でのバグの発見と除去に役立ちます。

ハードウェアとソフトウェアの協調シミュレーション

SWとHW間の協調シミュレーションには、SWシミュレーションエミュレーション環境と対話できるようにHW設計を検証するために使用されるロジックシミュレーションツールが必要です。

AldecのRiviera-PRO（2017.10）のリリースにより、Riviera-PROとQEMUの間にブリッジを提供することで、このHWとSWの協調シミュレーションが可能になり、LinuxベースのZynq開発用に開発されたソフトウェアの実行が可能になります。

>

図2.ハードウェアとソフトウェアの検証環境のブリッジング（出典：Aldec）

このブリッジは、SystemCトランザクションレベルモデリング（TLM）を使用して作成され、QEMUとRiviera-PRO間の通信チャネルを定義します。 SWとHWの同時検証は、ブリッジが双方向に情報を転送する機能によって容易になります。

この統合されたシミュレーション環境内で、エンジニアリングチームは、標準および高度なデバッグ方法を使用して、検証の進行中に発生する可能性のある問題に対処できます。 Riviera-PROの場合、これには、HDL内のブレークポイントの設定、データフローの調査、QEMUで実行されているSWアプリケーションによって実行されるコードカバレッジとパスの分析などの機能が含まれます。 QEMUの場合、SWチームはGnu DeBugger（GDB）を使用して、カーネルとドライバーの両方をインストルメント化し、ブレークポイントを使用してコードをステップスルーできます。

この協調シミュレーションアプローチには、ハードウェアシミュレーション環境内での可視性とデバッグ機能が向上するだけでなく、ターゲットハードウェア用に開発された同じLinuxカーネルをQEMU内で使用できるという利点があります。繰り返しになりますが、これにより、開発中のアプリケーションをサポートするために必要なすべてのパッケージと要素がカーネルに正しく含まれていることを早期に検証できます。

PWMの例

この協調シミュレーション環境を示すために、簡単な例を作成しました。この例では、IPコアをPL内に配置し、汎用AXIインターフェイスを介してZynqPSに接続します。レジスタスペースへのAXIアクセスによって有効にされると、IPコアはパルス幅変調（PWM）信号出力を生成します。 PWM信号の持続時間は、0〜100％の範囲で選択可能であり、IPコアのレジスタスペース内のレジスタによって再び定義されます。したがって、このコアの一般的な使用例では、IPコアを有効にして構成するためにZynqPSで実行されているソフトウェアが必要です。 IPコアを単独でシミュレートするだけでは、コアの目的の動作が適切に示されることはありません。 IPコアを正しく検証するには、Linuxオペレーティングシステムを実行しているときにPSからの出力パルス幅を有効にして実行できる必要があります。