Zynq SoC設計のための協調シミュレーション：ハードウェア・ソフトウェア検証を加速

Xilinx Zynq-7000とZynq UltraScale+ MPSoCのような異種システムオンチップ（SoC）デバイスは、高性能処理システムと最先端のプログラマブルロジックを融合します。この統合により、設計者はCPU駆動の制御とPLベースの低レイテンシパイプラインをバランスさせたシステムを構築でき、画像処理、産業オートメーション、リアルタイム信号処理に最適です。

PS-PL接続は、マスターとスレーブの両役割をサポートするメモリマップドAdvanced eXtensible Interface（AXI）リンクのスイート上に構築され、ARMコア上で実行されるソフトウェアとFPGAファブリック内のカスタムロジック間の堅牢な双方向通信を可能にします。

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

PSが設定や制御を担当する場合、プロセッサー上の汎用AXIマスターがPL IPコア内のレジスタに書き込み、その動作を制御します。データ集約型タスク（PLからPSメモリへのビデオフレームストリーミングなど）では、ハイパフォーマンスAXIインターフェースが使用され、DMA転送の設定とバッファコヒーレンシー管理により洗練されたソフトウェアが要求されます。

PS-PL相互作用の検証は悪名高い難しさがあります。2015年組み込み市場調査ではデバッグがトップ設計課題として挙げられ、より良い検証ツールの必要性が強調されました。バス機能モデルは初期の健全性チェックを提供できますが、実際のソフトウェアドライバーとアプリケーションを検証するために必要な深さに欠けることが多々あります。完全機能モデルは存在しますが、法外に高価な場合があります。

従来の検証ではフローを分割します：各ブロックを孤立して検証し、最初のハードウェア到着後に初めてPSとPLを結合。ソフトウェアチームは通常、Linuxカーネルが必要なドライバーとデバイスツリーエントリを持つかをQEMU（ARMアーキテクチャをエミュレートするオープンソースハイパーバイザー）で実行して確認。逆にロジックチームは、ソフトウェア開始トランザクションを模倣するコマンドシーケンスでPL機能を確認します。

両アプローチとも真のPS-PLハンドシェイクを見逃すため、微妙な統合バグを発見するのが困難で、サイクル後半での修正コストが高くなります。開発ボードで一時しのぎはできますが、実ハードウェアでのデバッグは計装ロジック挿入、ビットストリーム再生成、動作ドリフトのリスクを伴います。

ハードウェアとソフトウェアの協調シミュレーションは積極的な解決策を提供します：量産ボード存在前に同時検証を可能にし、デバッグ時間とコストを劇的に削減。また、レジスタ状態とドメイン間トラフィックへの完全な可視性を設計者に与え、欠陥検出を加速します。

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

協調シミュレーションには、ロジックシミュレーターがソフトウェアエミュレーションプラットフォームと通信する必要があります。AldecのRiviera-PRO（2017.10）が、Riviera-PROをQEMUに接続するブリッジを導入し、LinuxベースのZynqソフトウェアをHDLと同じシミュレーションサイクル内で実行可能にしました。

図2. HWとSW検証環境の橋渡し（出典：Aldec）

このブリッジはSystemCトランザクションレベルモデリング（TLM）を活用し、QEMUとRiviera-PRO間のAXIチャネルを公開、双方向データ交換を可能にします。エンジニアは、Riviera-PRO内でHDLブレークポイント、データフロートレーシング、コードカバレッジ分析などの高度なデバッグ技術を使用し、ソフトウェア側ではGDBでQEMU内のカーネルとドライバーコードをステップ実行できます。

ターゲットデバイスで実行される同じLinuxカーネルがQEMUで実行されるため、開発者は必要なすべてのモジュールと設定ファイルが存在することを早期に確認でき、後期段階のサプライズを減らせます。

PWM例

ワークフローを説明するため、PLに配置され汎用AXIインターフェース経由でPSに接続されたPWM IPコアを考えます。ソフトウェアがレジスタを設定し、デューティサイクルを0%～100%に設定してコアをトリガーします。コア単体の検証ではPS開始制御パスを見逃します；完全な協調シミュレーションにより、Linuxアプリケーション実行時にパルス幅が正しく生成されることを保証します。