マルチコアデバッグ


The embedded tools company
特長
ひとつのデバッグインタフェースで複数のコアに接続
Advantages and Disadvantages


マルチコアデバッグ
  ハイライト
同種または異種のマルチプロセッサ/マルチコアの組み込みアプリケーションデバッグ
高品質の標準デバッガをマルチプロセッサ/マルチコアのデバッグに利用可
全てのTRACE32-ICD デバッガはマルチプロセッサ/マルチコアのデバッグ環境で同時利用可
サードパーティーのデバッガへのすばやい対応
単一シリコン上の各プロセッサが同一のデバッグポートをシェア可能
スタート/ストップの同期


Link Order
オーダー情報
Support
テクニカルサポート
Video: Synchronized AMP Debugging with ARMョ and Niosョ-II

TOP

特長


複数のコアを持つシステムオンチップデザインのデバッグが、開発ツールの新しい需要として位置付けられています。チップデザイナーとツール製作者は、ユーザーがコアの組合せを自由に選択し、そしてそれに合う高品質の開発ツールを素早く入手できるように、適切なマルチコアデバッグ技術について、早急に合意することが求められています。

特定のアプリケーション用途のASICは、今現在も組込み開発において、ある一定のペースで使用される機会が増え続けています。最適な機能性と性能を達成するために、SoC形成に複数のコアが統合されることが一般的になっています。いろいろな組み合わせの中でもDSPと組み合わせたRISCプロセッサの使用が広がっています。

この種のマルチコアSoCデザインの統合及びテストには、新しいマイクロプロセッサ開発ツールが必要になります。ここでは、共有されたデバッグインタフェースを通じて複数のコアと接続する事でデバッグを行う仕組みについて解説します。

 
TOP

ひとつのデバッグインタフェースで複数のコアに接続


TRACE32デバッガシステムは並列接続およびカスケード接続でのJTAGインタフェースをサポートします。ひとつ以上のデバッガを同一のJTAGインタフェースに接続することができます。

デバッガ、JTAGコネクタともに別々


デバッガは別でJTAGコネクタは共通、コアの選択は特殊な信号を使用


デバッガは別でJTAGコネクタは共通、コアはカスケード接続


Common debuggers and common JTAG Connector, cores selected by special line


デバッガもJTAGコネクタも共通、コアはカスケード接続


 
TOP

Advantages and Disadvantages


今日、ほとんどのプロセッサがデバッグの為のオンチップデバッグ回路を備えています。デバッグ回路をコントロールするために最も 頻繁に使われているインタフェースはJTAGです。しかし、マルチコアSoCデザインでは、ピン数の節約及びコストの削減のため、それ ぞれのコアの為に別々のJTAGインタフェースを用意していません。代わりに、ジョイントJTAGインタフェースを使用することにより、 全てのコアのデバッグが可能となります。では、デバッガはどのようにしてジョイントJTAGインタフェースを通じて複数のコアを取り扱うことができるのでしょうか。また、どのようにして複数のコアの間における同期デバッグが可能なのでしょうか。

一つのデバッガでSoCの全てのコアをサポート

    一見、開発者にとって理想的な解決方法とご理解頂けると思います。この方法の最も重要な利点は、全てのコアに対して一つの開発ツールである事と、それ故一つのユーザーインタフェースと製品の仕組みを覚えるだけで良いという事です。これは、大量生産され、数多くの開発プロジェクトに使用されるSoCを採用する場合、確実に最良のアプローチです。このような製品の一例として、メインのコアだけではなくペリフェラルコントロールプロセッサ(PCP)をもデバッグ可能とする、ローターバッハの「TriCoreデバッガ」があります。

    その一方、ただ一つの製品の開発での使用を目的とした、個別化されたSoCに向かう市場の流れも存在します。より最適化されたパフォーマンスと機能性を達成する新しいSoCが次の製品のために作り出されています。また、開発者が統合化されるコアを自由に選択したいと思えば、採用されているそれぞれのアーキテクチャに対して最適な開発環境を提供するツールが必要となります。必然的に、最初のチップがウエハーから製造された時点では、デバッグツールも完全にテストされ利用可能状態となっていなければなりません。この解決方法は明らかに最良な方法ではありますが、高い品質基準を維持しながらより迅速に、より安価に実現するのは大変困難なことです。

JTAGサーバーの使用


    デバッガは専用のJTAGハードウェアを使う代わりにJTAGサーバーのソフトウェアインタフェースを使用しています。今日、多くのコアにおいて、高い先進性を持つデバッガを利用することができます。そのため、ジョイントJTAGインタフェースを通じて各コアへのアドレッシングを管理するJTAGサーバーに、既存のデバッガを接続する方法が考えられます。

    次のように、JTAGサーバーを実装することによる解決方法を考えてみます。サーバーハードウェアはジョイントJTAGインタフェースの手前に接続され、ハードウェアはホスト上のサーバーソフトウェアによって制御されているとします。今、それぞれのデバッグクライアントは、リモートプロセジャーコールを使ってサーバーにコミュニケーションリクエストを送信します。これにより、ジョイントJTAGインタフェースへの排他的なアクセスが保証され、それぞれのコアに対して通信リクエストが送信されます。図1に、このケースのサーバソリューションの基本的原理を示します。この場合デバッガはJTAGサーバーに対して専用のJTAGハードウェアの代わりに、ソフトウェアインタフェースを使用します。

    一見、とても賢明なアプローチに見えますが、先と同様に問題に対する完全な解決策とはなっていません。既に、数社の半導体メーカーから、製品シリーズ中でコアのグルーピングをした物へのJTAGサーバーソリューションが提供されていますが、各ベンダに依存しない解決策を提供するサーバ基準はまだ存在しません。また、JTAGサーバーを使用する解決策は、各半導体メーカーがデバッグ機能追加のためのJTAG信号の拡張によって、柔軟性が失われることになります。例えば、マルチコア開発環境においては、それぞれのコアがすぐにコアを停止させることができるストップリクエスト信号が有る事が望まれます。また、コアが停止状態にあることを示す信号があり、それを使って停止したことを知らせることです。理想的には両方の信号があれば、マルチコアアプリケーションにおいて全てのコアの同期停止に使用できます。

    最適なコアの組合せの自由な選択により、いくつかの信号が現れることになります。一つの選択肢として、単純にこれらの信号はボード上を通過させ、追加機能を組み込むことなく済ませることもできます。しかし、これらの信号はしばしば必要であり、非常に役立つ事は確かですから使うべきです。このため、JTAGサーバーは特定アプリケーションにも適合させ、テストされなければなりません。

    もう一つ特にリアルタイムアプリケーションを扱う際に考慮しなければならないクリティカルポイントは、JTAGサーバが操作しなければならない膨大なデータです。それに応じて個別のCPUコアの応答時間も遅くなります。それでもシステムのリアルタイム要求を満たすためには、スピードが重視される機能をハードウェアに盛り込む必要があります。つまり、それはやはりJTAGサーバを特定のアプリケーションに適合させることを意味します。以上より、最適なサーバソリューションとして考えられるのは、一つのSoC上で使用される全てのコアが同一の半導体メーカーから供給され、そしてまたその半導体メーカーがJTAGサーバーとそのサーバーの仕様に適合するデバッガも供給することです。一方、特定のアプリケーションに適合するように設計されたサーバを実現するには、デバッガメーカー間の協定が必要となります。これは競合により難しいとされ、時間の浪費とコストの集中になります。追加の要因として、サーバーを全ての新しいコアの組み合わせに再度適応させる必要があります。

ジョイントJTAGインタフェースにおいて完全に独立したデバッガ



    同一JTAGポート上に一つ以上のデバッガが接続された場合、排他的アクセスを保障します。

    同一JTAGポート上に一つ以上のデバッガが接続された場合、排他的アクセスを保障します。 このアプローチでは、シンプルでかつオープンな解決方法を示しています。この方法では、可能な限りの最良のコアの組み合わせを、特定のアプリケーションに対応できるように自由に選択することができます。開発と統合の期間、開発者は開発環境を特定のアプリケーションに適応させる必要はなく、全て完璧なデバッガを利用することができます。

    ここでの基本的な考え方は、独立したデバッガが全コアの為に用意されたジョイントJTAGインタフェースに接続するというものです。このアプローチが機能するためには、データをそのコアと交換していない時は、それぞれのデバッガはそのデバッガに対応するJTAGドライバを無効にしなければなりません。

    今、複数の独立したデバッガが同じJTAGインタフェースを使用しているので、一度には、一つのデバッガのみがインタフェースを使っての操作をすることを確実にしておく必要があります。これは ホスト上のデバッグタスクがセマフォシステムを使ってJTAGへの排他的アクセス決めるというシステムにより自動化できます。その他に考えられる選択肢としてはハードウェアセマフォを使用する方法もあります。

    全てのコアの同時実行及び停止については、SoC上の特別のロジックを通じて簡単にかつ効果的に解決することができます。例えば、次の2つの信号を追加することにより、全てのコアを同時に停止させることができます。

    • STOP Request Signal --- CPUコアを即座に停止させることができる信号
    • STOP Indication Signal --- CPUコアが停止したことを知らせる信号

    これらの信号は、マトリックスを通じてSoC上に組み込まれています。例えば、メモリマップドコントローラレジスタをセットすることにより、ある一つのコアが停止した場合に、それぞれのコアは停止するか実行を続けるかをセットすることができます。図3はこのタイプのマトリックスを示しています。また、このマトリックスでは、個々のコアが持つ周辺機能の対する拡張が簡単にできます。このソリューションの主な利点は停止時の高度な同期性能にあり、そしてチップデザイナーによるデバッガ製造者のための標準インタフェースの提供です。



    特別のオンチップロジックは実行と停止の同期を行うために、コアの実行/停止を要求する信号および実行/停止を示す信号のクロス接続を行います。



    このソリューションは、チップデザイナーとツール製作者にとって比較的シンプルな手段となっています。基本的な前提条件がわかっていればどのようなコアでもSoC上に統合することができ、関連のある開発環境を自由に選ぶことができます。

    ここでの利点は、次のようにまとめることができます。

    • このアプローチではツール製作者間で取り交わされる追加協定は必要ありません。高性能開発ツールをすぐに利用できます。

    • ここで述べてきた解決策では、ツール製作者の側において特定のアプリケーション用途向けの修正を必要としません。これにより、他の開発プロジェクトでも再利用できるように、標準的なツールを採用することができます。

    • 全てのコアに完璧なデバッグシステムを得なければならないという一見不都合なことが、見直してみると長所が多いことがわかります。通常、開発段階では一度にテストされるのは一つのコアのみで、デバッガを個別に使用することができるからです。全てのデバッガを同時に使用しなければならないのは、コア間での動作をテストする統合段階においてのみです。





TRACE32のデバッガではすでに数多くのコアをサポートしています。またマルチコアSoCデザイン用デバッガを使用する上で、標準化したユーザーインタフェースと共通の製品哲学が既に確立されています。

マルチコアデバッグが初期段階にある限り、または一般的な規格が定義されない限り、この三番目の解決策が最も効果的なものであると考えます。TRACE32デバッガはすでにジョイントJTAGインタフェースでの操作が備えられています。




Copyright © 2016 Lauterbach Japan, Ltd., Kouhoku-ku, Nisso 16th Building, Yokohama-shi, Japan 222-0033  Impressum
The information presented is intended to give overview information only.
Changes and technical enhancements or modifications can be made without notice.
Last generated/modified: 19-Oct-2016