DDRメモリは、ここ数年で一般的に使用されるようになってきました。DDRメモリは、データバスにメモリ・コントローラの信号とDDRメモリの信号が互いのクロックで行き来し、しかもReadとWriteではデータの位相が90度ずれるため、ロジック・アナライザでメモリ・トランザクションをモニタすることは至難の業でした。さらに、BGAが主流の現在ではプロービングすること自体非常に困難です。
このためDDRメモリの実装上のトラブルに関しては、基板のシグナル・インテグリティだけをチェックして、問題がなければ、後はメモリ・ベンダ、コントローラ・ベンダにトラブルの切り分けを依頼するケースが多かったと思います。ところが最近ではFPGAへのDDRメモリ・コントローラIPの実装、より高速なDDRメモリの採用、外部I/Oの増設によるメモリ・トランザクションの増加などによりDDR周辺のトラブルが後を絶ちません。通常のメモリ・アクセスでは問題が発生しないのに、特定の状況のときにだけシステムがハングするような場合、どのようにトラブルを切り分けますか? このようなケースではDDRアナライザが威力を発揮します。
DDRアナライザにおけるロジック・アナライザの進化のポイントは以下のとおりです。
以上のとおり、DDRアナライザはDDR専用プロトコル・アナライザのように簡単に接続して誰でも簡単に使用することができます。プロービングについては、仕様でDIMMやSO-DIMMなどの形状が規定されているので、以下のようなプローブをターゲットに接続し、付属のセットアップ・ファイルを開けば準備完了です(図7)。
また組み込みシステムの場合、DDRメモリを基板に直付けするケースも多いと思いますが、その場合は上記のようなBGAプローブを基板とDDRメモリの間に取り付けるだけです。この場合もセットアップ・ファイルが添付されていますのですぐに使用可能です。
DDRアナライザの機能については、すでに第2回、第3回で触れましたので、ここでは以下にパフォーマンス検証、プロトコルレベルのコンプライアンス検証、デバッグ画面の各画面を示します(図8)。
DDRメモリの場合、データバスの信号をモニタしないと割り切れば、64チャンネル入力で足ります。この場合Read/Writeしたデータはモニタできないので分かりませんが、特定のアドレスにRead/Writeしたイベントを検出することが可能です。また上記のDDRアナライザの解析機能も使用可能です。
さらにデータバスをモニタしない場合のメリットはもう1つあります。アドレスやコマンド/コントロール・バスはダブル・データ・レートではありません。例えばDDR2/400の場合、データバスは200MHzの両エッジでのサンプリングが必要ですが、アドレスやコマンド/コントロール・バスは、200MHzの片エッジでのサンプリングです。このためアナライザ・モジュールも安価なモジュール1枚でDDRアナライザとして使用することが可能です。
高速化、大規模化、複雑化したシステムの設計において、システムの各ブロックや統合デバッグにおける評価検証作業は非常に複雑になり、効率的なデバッグが、開発期間を短縮し信頼性を維持するうえでの重要な課題になっています。
しかしながら、システム統合デバッグを非常に複雑にしている要因の1つとして、物理層、論理層、トランザクション層、ソフトウェアなどの各レイヤで使用している測定器の連携の問題(図9)があることはあまり知られていません。
例えば物理層、論理層、プロトコル層、アプリケーション層のエンジニアは、それぞれの使用したシミュレータや開発ツールを前提に不具合解析を行います。しかしながら互いに協力し相関を取らなければ不具合現象を特定することは困難です。その際にロジック・アナライザは、オシロスコープ、プロトコル・アナライザ、ICEなどとの時間相関、トリガ連携が可能ですので、問題現象発生時のイベントを特定することでデバッグ効率は飛躍的に向上します。実際のシステムの動作を正しく把握し、その情報を関係するエンジニアで共有し連携して解決していくことは非常に重要です。
ロジック・アナライザは、基本的な性能よりも、使い勝手の点で進化し低価格になってきています。シミュレーションのためのテストベンチの構築やシミュレーションの精度は極めて重要ですが、実機デバッグをスマートに行うためにロジック・アナライザの活用を検討してみるのも悪くないと思います。
さて次回でこの連載も終了です。FPGAアナライザやDDRアナライザなど実際のデバッグで役立つテクニックについて実例を交えて紹介していきます。
Copyright © ITmedia, Inc. All Rights Reserved.