Microsemi インサーキット FPGA デバッグ手順

コンテンツ 隠れる

1 Microsemi インサーキット FPGA デバッグ

2 製品情報

3 導入

4 FPGA 設計のデバッグ時によくある問題

Microsemi インサーキット FPGA デバッグ

製品情報

仕様

デバイスタイプ: Microsemi SmartFusion2 SoC FPGA
発売日: 2014年XNUMX月
デバッグ機能: インサーキット FPGA デバッグ、組み込みロジックアナライザ
最大データキャプチャ周波数: 最大100MHz

抽象的な
FPGAは、多くの設計上の利点を備えた組み込みシステムにおける強力な設計要素です。tagしかし、これらのデバイスは複雑な設計をしており、デバッグが必要な複雑な設計上の問題を抱えている場合があります。定義エラー、システム相互作用の問題、システムタイミングエラーなどの設計上の問題を追跡することは困難な場合があります。FPGAにインサーキットデバッグ機能を組み込むと、ハードウェアデバッグが大幅に改善され、数え切れないほどのフラストレーションを避けることができます。この論文では、FPGAのインサーキットデバッグに対するいくつかの異なるアプローチについて説明し、主要なトレードオフを特定し、例を通してampMicrosemi SmartFusion®2 SoC FPGA デバイスを対象としたこの設計では、新しい機能を使用してデバッグとテストを高速化する方法を紹介します。

導入

FPGA は広く普及した強力な設計要素であり、現在ではほぼすべての組み込みシステムに使用されています。容量の増加、複雑なオンチップ機能ブロックの組み込み、高度なシリアルインターフェイスにより、これらのデバイスにはデバッグが必要な複雑な設計上の問題が発生することもあります。高度な FPGA を使用すると、機能定義エラー (FPGA またはシステムレベル)、機能システムの相互作用の問題、システムのタイミングの問題、IC 間の信号忠実度の問題 (ノイズ、クロストーク、反射など) などの問題の追跡がはるかに複雑になります。シミュレーションは多くの設計上の問題を特定するのに非常に役立ちますが、現実世界の相互作用の多くは、設計がハードウェアに実装されるまで現れません。複雑な設計上の問題をデバッグするためのさまざまな手法が開発され、プロセスを簡素化しています。さまざまな高度な手法を含むこれらの主要な手法のそれぞれを注意深く理解することで、設計上の問題を簡単に特定できます。tagesと不利tagこれは、特定の設計にどの手法または手法の組み合わせが適しているかを検討するときに役立ちます。
元ampMicrosemi SmartFusion2 SoC FPGAデバイスを対象としたFPGA設計は、いくつかの先進的な機能のデモンストレーションに使用できます。tagesと不利tagこれらの標準技術と最新のインサーキットデバッグ機能の統合。この実例ampハードウェアのデバッグ中にハードウェアの問題を迅速に特定して排除するために、これらのさまざまな手法をどのように使用できるかを説明します。

FPGA デバッグがシステム設計と開発の重要な側面である理由は何ですか?
FPGA には、他の設計要素とは異なる 2 つの主な使用モデルがあります。FPGA は、量産製品で使用することも、量産設計コンセプトを実証またはプロトタイプ化するための開発手段として使用することもできます。量産手段として使用する場合、FPGA は ASIC または CPU ベースの量産手段よりもはるかに柔軟なターゲットになります。これは、まだハードウェアに実装されていない新しい設計の場合に特に重要です。さまざまなアーキテクチャオプションを備えた設計を簡単に作成してテストできるため、最適な設計を特定できます。オンチッププロセッサを備えた FPGA (SoC FPGA) では、CPU ベースの処理とハードウェア支援の FPGA ベースのアクセラレーション機能をトレードオフすることもできます。これらのアドバンストtages を使用すると、新製品開発における設計、検証、テスト、障害解析に必要な時間を大幅に短縮できます。
設計のプロトタイプ作成、たとえば量産 ASIC に使用する場合、FPGA の柔軟性が重要な利点となります。実際のハードウェアプラットフォームは、フルスピードで動作しないものであっても、詳細なシステムパフォーマンスメトリック、スループット分析データ、およびアーキテクチャの概念実証結果の取得がはるかに簡単になります。業界標準バス (PCIe®、ギガビットイーサネット、XAUI、USB、CAN など) の強化された実装に対する FPGA サポートにより、これらのインターフェイスに関連するテストが簡素化されます。オンチップ ARM プロセッサ (SoC FPGA) を搭載した最新の FPGA ファミリにより、組み込みプロセッサを使用した実装のプロトタイプ作成が容易になります。以前に開発されたプロセッサコードをプロトタイプに移植し、ハードウェア設計作業と並行して新しいコードを作成できます。

標準プロセッサと標準インターフェイスバスの組み合わせにより、利用可能なコードライブラリ、ドライバ、機能 API、リアルタイムオペレーティングシステム、さらには完全なオペレーティングシステムからなる大規模なエコシステムを活用して、より迅速に実用的なプロトタイプを作成できます。さらに、設計が固まったら、FPGA プロトタイプを使用して、実際のシステムデータを反映する広範なシミュレーションテストセット (刺激と応答の両方) をキャプチャできます。これらのデータセットは、ASIC やその他の生産実装の最終シミュレーションを作成する際に非常に役立ちます。tagFPGA を設計プロトタイプとして使用すると、最終製品の実装における設計、検証、テスト、障害解析にかかる時間を大幅に短縮できます。
これら一般的なFPGA使用モデルの両方において、設計ターゲットとしてのFPGAの柔軟性は重要な利点である。tage. これは、多くの設計変更と反復が標準となることを意味し、したがって、設計エラーを迅速にデバッグする能力は、可能な限り多くの設計オプションを可能にするために重要になります。効率的なデバッグ機能がなければ、アドバンテージの多くはtagFPGA 設計の柔軟性は、追加のデバッグ時間によって低下します。幸いなことに、FPGA は、リアルタイムデバッグを大幅に簡素化する追加のハードウェア機能も提供できます。これらの機能を見る前に、まず FPGA 設計が直面する可能性のある最も一般的な種類の問題を見て、さまざまなデバッグツールの効率と関連するトレードオフを評価するための適切な背景情報を得ましょう。

FPGA 設計のデバッグ時によくある問題

現代のFPGAがもたらす拡張された機能とともに、それに伴う複雑さの増大により、エラーのない設計を作成することがますます困難になっています。実際、デバッグは組み込みシステムの設計サイクルの50％以上を占めると推定されています。市場投入までの時間に対するプレッシャーが開発サイクルを圧迫し続ける中、初期システムのハードウェアデバッグは後回しにされ、検証（それ自体が大きな割合を占める）が重要ではないと想定されることが多すぎます。tag初期システム立ち上げ前に、すべてのバグを早期に発見できるようなシステム開発計画（開発スケジュールの策定）を策定しましょう。一般的な設計が初期システム立ち上げ時に直面する課題をより深く理解するために、一般的なシステムの問題の種類をいくつか見てみましょう。

機能定義のエラーは、設計者が特定の要件を誤解しているため、見つけるのが2倍難しく、設計の詳細を注意深く見てもエラーが見落とされる可能性があります。amp一般的な機能定義エラーの1つは、ステートマシンの遷移が正しい状態にならない場合です。エラーは、システムインターフェースの相互作用の問題として現れることもあります。たとえば、インターフェースの遅延などです。ample が誤って指定され、予期しないバッファオーバーフローまたはアンダーフロー状態が発生する可能性があります。
システムレベルのタイミングの問題も、設計エラーの非常に一般的な原因です。特に非同期イベントは、同期またはタイミングドメイン間の影響が慎重に考慮されていない場合に、一般的なエラーの原因となります。高速で動作している場合、これらのタイプのエラーは非常に問題になる可能性があり、非常にまれにしか発生しない可能性があり、特定のデータパターンが現れる場合にのみ発生する可能性があります。一般的なタイミング違反の多くはこのカテゴリに分類され、シミュレーションが非常に困難、または不可能であることがよくあります。

タイミング違反は、集積回路間の信号忠実度が低いことが原因で発生することもあります。特に、各回路に複数の電源レールがあるシステムでは、信号忠実度が低いと、信号ノイズ、クロストーク、反射、過負荷、電磁干渉 (EMI) の問題が発生する可能性があり、タイミング違反として現れることがよくあります。過渡現象 (特にシステムの起動時またはシャットダウン時)、負荷変動、高電力消費ストレスなどの電源の問題も、原因不明のエラーの原因となることがありますが、電源ソースに簡単にたどり着くことはできません。設計が完全に正しい場合でも、ボード製造の問題によってエラーが発生する可能性があります。たとえば、はんだ接合部の欠陥やコネクタの不適切な取り付けなどです。amp、エラーの原因となる可能性があり、温度やボードの位置に依存する場合もあります。高度な FPGA パッケージング技術を使用すると、プリント回路基板上の信号をプローブすることが困難になる可能性があるため、目的の信号にアクセスするだけでも問題が発生することがよくあります。多くの場合、多くの設計上の問題はすぐにエラーを生成せず、エラーが実際に現れるまで設計全体に波及する必要があります。最初のエラーを根本原因まで追跡することは、多くの場合、イライラさせられる、困難で時間のかかる作業です。

例えばamp例えば、変換テーブル内の1ビットの誤りは、何サイクルも経たないうちにエラーになることがあります。この論文で後ほど説明する、専用のインサーキットデバッグハードウェアを使用するツールのいくつかは、特にこれらの「バグハンティング」をより迅速かつ容易にすることを目的としています。これらのツールの詳細に入る前に、その利点をよりよく理解するために、まずは一般的なソフトウェアベースのデバッグ手法のシミュレーションを見てみましょう。tagesと不利tagデバッグにシミュレーションを使用する利点。

デバッグのためのシミュレーションの使用
通常、設計シミュレーションでは、設計の内外のすべての実際のコンポーネントが、標準CPUで順次実行されるソフトウェアプロセスとして数学的にモデル化されます。設計にさまざまな刺激を適用し、予想される出力をシミュレーションされた設計出力と比較することは、ほとんどの明らかな設計エラーを簡単に検出する方法です。典型的なシミュレーション実行を示すウィンドウを以下の図1に示します。tagシミュレーションとハードウェアベースのデバッグの違いは、シミュレーションはソフトウェアで実行できることです。実際のハードウェアベースの設計やテストベンチは必要ありません。シミュレーションでは、多くの設計エラー、特に誤った仕様、インターフェイス要件の誤解、機能エラー、および単純な刺激ベクトルによって容易に検出されるその他の多くの「重大な」タイプのエラーを迅速に検出できます。

シミュレーションは、設計者が広範な刺激の組み合わせを利用でき、その結果の出力がよくわかっている場合に特に効果的です。このような場合、シミュレーションによって設計のほぼ完全なテストを行うことができます。残念ながら、ほとんどの設計では広範なテストスイートに簡単にアクセスできず、テストスイートの作成プロセスに非常に時間がかかることがあります。大規模な FPGA ベースの設計では、設計を 100% カバーするテストスイートを作成することは事実上不可能であり、設計の主要要素をカバーするには近道を使用する必要があります。シミュレーションのもう XNUMX つの難点は、シミュレーションが「現実世界」の実装ではないため、非同期イベント、実速度でのシステム相互作用、またはタイミング違反を捕捉できないことです。最後に、シミュレーションプロセスは非常に遅くなる可能性があり、多くの反復が必要な場合は、シミュレーションがすぐに最も時間がかかり、多くの場合、開発プロセスの中で最もコストのかかる部分になります。

代替案として（あるいは、シミュレーションへの追加として）、FPGA設計者は、デバイス内の主要な信号を観察および制御するために、FPGA設計にデバッグハードウェアを追加できることを発見しました。これらの技術は、当初はアドホックなアプローチとして開発されましたが、徐々に標準的なハードウェアデバッグ戦略へと発展しました。このインサーキットデバッグ機能の使用は、大きな利点をもたらします。tagFPGAベースの設計では、次のセクションでは最も一般的な3つの戦略とそのさまざまな利点について説明します。tagesと不利tages。

FPGA の一般的なインサーキットデバッグ手法
FPGA にインサーキットデバッグ機能を実装する最も一般的な手法は、組み込みロジックアナライザ、外部テスト機器、または FPGA ファブリック内に組み込まれた専用信号プローブハードウェアのいずれかを使用することです。組み込みロジックアナライザは通常、FPGA ファブリックを使用して実装され、設計に挿入されます。JTAG ポートはアナライザへのアクセスに使用され、キャプチャされたデータは PC に表示できます。外部テスト機器を使用する場合、テスト対象の FPGA デザインが変更され、選択された内部 FPGA 信号が出力ピンにルーティングされます。これらのピンは、外部テスト機器を通じて観察できます。専用の信号プローブハードウェアを使用すると、さまざまな内部信号をリアルタイムで読み取ることができます。一部のプローブ実装は、レジスタまたはメモリ位置に書き込むために使用することもでき、デバッグ機能をさらに強化します。アドバンスの詳細を見てみましょう。tagesと不利tagこれらの各テクニックを実際に試して、amp設計を比較して、これらのさまざまなアプローチが全体的なデバッグ時間にどのように影響するかを確認します。

インサーキット FPGA デバッグ組み込みロジックアナライザ
組み込みロジックアナライザの概念は、FPGAが初めて使用されたときに設計者が実装したアドホックなインサーキットデバッグ機能の直接的な結果でした。組み込みロジックアナライザは新しい機能を追加し、設計者が独自のアナライザを開発する必要をなくしました。ほとんどのFPGAはこれらの機能を提供しており、サードパーティは標準アナライザを提供しています（SynopsysのIdentify®は人気のある例の1つです）。ampより高レベルのツールと簡単にインターフェースして生産性をさらに向上できるツール (例: 統合開発環境 (IDE)) です。

ロジックアナライザ機能は、図2に示すように、FPGAファブリックと組み込みメモリブロックをトレースバッファとして使用して設計に挿入されます。複雑な信号相互作用を簡単に選択してキャプチャできるように、トリガーリソースも作成されます。制御とデータ転送のためのアナライザへのアクセスは、通常、標準のJTAG ポートによりインターフェース要件が簡素化されます。キャプチャしたデータは、一般的な viewingソフトウェアであり、通常はロジックシミュレータの波形出力をミラーリングします viewingスタイル。

アドバンtagこのアプローチの利点は、追加のFPGA I/Oピンが使用されず、標準のJTAG 信号。組み込みロジックアナライザIPコアは通常比較的安価で、場合によっては既存のFPGA合成やシミュレーションツールのオプションになることもあります。場合によっては、組み込みロジックアナライザは、より便利な場合は、未使用のI/Oに追加の出力を提供することもできます。tagこのアプローチの欠点は、大量のFPGAリソースが必要になることです。特に、トレースバッファを使用する場合、使用可能なブロックメモリの数が減少します。広いバッファが必要な場合は、メモリの深さとのトレードオフになります（広いメモリを使用するとメモリの深さが浅くなるため）。これは大きな欠点です。tagたとえば、小型デバイスを使用する場合などです。この手法の最大の欠点は、プローブの配置を調整するたびに、設計を再コンパイルして再プログラムする必要があることです。大型デバイスを使用する場合、このプロセスにかなりの時間がかかることがあります。信号プローブが設計内に配置される方法により、信号のタイミング関係を相関させることが困難になる場合があります。さらに、信号プローブ間の遅延は一定ではないため、タイミング関係を比較することが困難です。これは、非同期信号または異なる時間領域の信号を比較する場合に特に困難です。

インサーキット FPGA デバッグ – 外部テスト機器
外部ロジックアナライザがシステムテストにすでに利用可能であったため、外部テスト機器と組み合わせてインサーキットデバッグコードを使用することは自然な流れでした。図3に示すように、内部テスト信号を識別して選択し、FPGA I/Oに適用する簡単なデバッグコードを作成することで、アナライザの高度な機能（大きなトレースバッファ、複雑なトリガーシーケンス、複数の viewシンプルで強力なデバッグ環境を構築するために、さまざまなオプションが用意されています。高度なトリガーオプションのためのより複雑なインサーキット機能により、必要な出力の数を最小限に抑えることができます。たとえば、ampたとえば、外部ピンが必要な場合、広いバス上の特定のアドレスを選択することは困難になる可能性があります。
内部 FPGA ロジックを使用すると、I/O 要件が大幅に削減され、より複雑な問題をデバッグするために特定のアドレスパターン (呼び出しと戻りのシーケンスなど) を探すこともできます。共通のユーザーインターフェイスが利用できる場合は、学習曲線が簡素化され、生産性が向上します。

アドバンtagこのアプローチの利点は、外部テスト機器のコストを活用できるため、ツールコストが追加されないことです。一部のデバッグ回路 IP コアは、機器メーカーまたは FPGA メーカーから提供されており、非常に低コストまたは無料の場合があります。信号選択ロジックを実装するために必要な FPGA リソースの量は非常に少なく、トレース機能は外部ロジックアナライザを使用して実行されるため、ブロックメモリは必要ありません。選択ロジックは安価であるため、トリガーが広い多数のチャネルもサポートできます。ロジックアナライザはタイミングモードと状態モードの両方で動作できるため、タイミングの問題を特定するのに役立ちます。
不利な点tagこのアプローチの欠点としては、プロジェクトにロジックアナライザがまだ割り当てられていない場合は、ロジックアナライザを購入する必要があることが挙げられます。この欠点は、tag多くの場合、このアプローチは推奨されない可能性があります。ただし、PC またはタブレットをディスプレイとして使用する低コストのロジックアナライザオプションが利用可能になりつつあり、単純なデバッグ要件の場合、このオプションの方がはるかにコスト効率が高くなることに注意してください。
消費されるFPGAピンの数も別の欠点となる可能性がある。tagまた、幅の広いバスを観察する必要がある場合は、ボードレイアウトとデバッグコネクタの追加について十分な計画が必要です。この要件は、設計段階の早い段階で予測することが難しい場合が多く、望ましくない複雑さが増します。組み込みロジックアナライザアプローチと同様に、外部テスト戦略では、新しい実験が必要になるたびに、設計の再コンパイルと再プログラミングが必要になります。

一般的な欠点tagこれら 2 つの手法の欠点は、オンチップリソースの使用 (デザインのタイミングパフォーマンスに影響し、追加のデバッグ要件が生じる可能性もある)、デザインの再コンパイルと再プログラムの必要性 (デバッグスケジュールに数時間または数日追加される可能性がある)、可能性のあるテストシナリオを識別するための事前の計画、および追加のチップ I/O リソースの使用であり、これらの欠点のないアプローチが必要になりました。1 つの対応策として、一部のデバイスの FPGA ファブリックに専用のデバッグロジックが追加されました。その結果、ハードウェアプローブを使用したインサーキットデバッグが実現しました。

インサーキット FPGA デバッグ – ハードウェアプローブ
ハードウェアプローブを使用すると、FPGA のインサーキットデバッグ手法が大幅に簡素化されます。SmartFusion2®SoC FPGA および IGLOO®2 FPGA デバイスのライブプローブ機能として実装されているこの手法では、FPGA ファブリックに専用のプローブラインが追加され、任意のロジック要素レジスタビットの出力を観察できます。図 4 のブロック図に示すように、ハードウェアプローブは XNUMX つのプローブチャネル A と B で使用できます。

選択されたレジスタ出力 (プローブポイント) は、図の下部に示されているように、2 つのプローブチャネルの上にルーティングされ、選択された場合は A チャネルまたは B チャネルのいずれかに適用できます。これらのリアルタイムチャネル信号は、デバイス上の専用のプローブ A ピンとプローブ B ピンに送信できます。プローブ A 信号とプローブ B 信号は、組み込みロジックアナライザーに内部的にルーティングすることもできます。

プローブピンのタイミング特性は規則的で、プローブポイント間の偏差がごくわずかであるため、リアルタイム信号のタイミング特性を比較することがはるかに容易になります。データは最大 100 MHz でキャプチャできるため、ほとんどのターゲット設計に適しています。
おそらく最も重要なのは、プローブポイントの位置が実装された設計の一部として選択されないため (設計が FPGA 上で実行されている間に専用のハードウェアによって選択される)、選択データをデバイスに送信するだけで簡単に変更できることです。設計の再コンパイルや再プログラミングは必要ありません。
ライブプローブ機能の使用をさらに簡素化するために、関連するデバッグソフトウェアツールは、自動的に生成されたデバッグを通じてすべてのプローブ信号位置にアクセスできます。 file図 5 に示すように、信号名を信号リストから選択し、目的のチャネルに適用できます。これは、設計の実行中でも実行できるため、設計内のプローブアクティビティはシームレスかつ非常に効率的です。

多くの場合、Live Probe などのハードウェアプローブ機能は、前述の組み込みロジックアナライザーおよび外部テスト手法と組み合わせて使用できます。

図 6 に示すように、信号をオンザフライで選択できる Live Probe 機能により、設計を再コンパイルすることなく、観察対象の信号をすばやく簡単に変更できます。外部ロジックアナライザまたはスコープを使用すると、専用のプローブ出力ピンの図の右上部分に示すように、プローブされた信号を簡単に観察できます。代わりに (またはそれに加えて)、内部ロジックアナライザ (図に示す ILA Identify ブロック) を使用して、プローブピンを観察できます。プローブ信号は ILA によってキャプチャされ、波形ウィンドウで観察できます。プローブの位置は、ターゲット設計を再コンパイルすることなく変更できます。
トリガーとトレースの追加機能を使用するとプローブの機能が強化され、複雑な設計上の問題も簡単に見つけられることに注意してください。

SmartFusion2 SoC FPGA および IGLOO2 FPGA デバイスでは、追加のハードウェアデバッグ機能も利用できます。これらの機能の XNUMX つである Active Probe は、任意のロジック要素レジスタビットを動的かつ非同期的に読み書きできます。書き込まれた値は XNUMX クロックサイクルの間保持されるため、通常の操作を続行でき、非常に有用なデバッグツールになります。Active Probe は、内部信号をすばやく観察する必要がある場合 (リセット信号のように、アクティブであるか、または目的の状態にあるかを確認するだけの場合など)、またはプローブポイントに書き込むことによってロジック機能をすばやくテストする必要がある場合に特に役立ちます。
(おそらく、制御フローの問題を分離するために入力値をすばやく設定して、ステートマシンの遷移を開始するためです)。

Microsemi が提供するもう 7 つのデバッグ機能は、メモリデバッグです。この機能により、設計者は選択した FPGA ファブリック SRAM ブロックを動的かつ非同期的に読み書きできます。デバッグツールのスクリーンショット (図 XNUMX) に示されているように、[メモリブロック] タブを選択すると、ユーザーは読み取りたいメモリを選択し、メモリのスナップショットキャプチャを実行し、メモリ値を変更して、値をデバイスに書き戻すことができます。これは、計算指向のスクラッチパッドや組み込み CPU によって実行されるコード用の通信ポートで使用されるデータバッファをチェックまたは設定する場合に特に便利です。メモリをすばやく観察および制御できると、複雑なデータ依存エラーのデバッグがはるかに迅速かつ容易になります。

設計のデバッグが完了したら、機密情報を保護するためにハードウェアデバッグ機能をオフにすることが望ましい場合があります。攻撃者はこれらの同じ機能を使用して重要な情報を読み出したり、システムの機密部分に簡単にアクセスできるシステム設定を変更したりする可能性があります。Microsemi は、デバッグが完了した後に設計者がデバイスを保護できるようにするための機能を追加しました。たとえば、ampたとえば、ライブプローブとアクティブプローブへのアクセスをロックして、攻撃手段としての機能を完全に無効にすることができます (これにより、プローブアクティビティによって供給電流にパターンが作成され、プローブデータを間接的に観察しようとする可能性も排除されます)。または、設計の選択した部分へのアクセスをロックして、そのセクションのみへのアクセスを禁止することもできます。設計の一部のみをセキュリティで保護し、設計の残りの部分には現場でのテストやエラー分析のためにアクセスできるようにする場合に便利です。

インサーキットデバッグ比較表
詳細な再view 8つの主要なインサーキットハードウェアデバッグ手法について説明しました。図XNUMXに示すように、さまざまなアドバンスの詳細を示す概要チャートが作成されました。tagesと不利tag各方法の利点。いくつかの手法は組み合わせて使用できることを覚えておいてください（たとえば、Synopsys Identifyのようなライブプローブと内部ロジックアナライザ（ILA）など）。amp図 1 から、各手法の主な長所と短所がわかります。インサーキットハードウェアデバッグ機能の集合 (ライブプローブ、アクティブプローブ、およびメモリデバッグ、総称して SmartDebug と呼ばれます) は、使用可能なプローブの合計数 (赤い円) に関しては他の手法と比較して最も弱く、キャプチャ速度 (外部テスト機器の方が高速になる場合があります) を考慮すると、最も優れたもの (黄色い円) よりも劣っています。
Synopsys Identify のような ILA ベースの技術は、他の技術と比較した場合、また FPGA リソース要件を考慮すると最も弱いです。外部テスト機器ベースの技術は、コスト、設計タイミングの影響、およびプローブ移動オーバーヘッド (設計を再コンパイルする必要があるため) が最も厄介な、いくつかの考慮事項の中で最も弱いです。おそらく最適なソリューションは、SmartDebug と他の技術の 1 つを組み合わせることです。これにより、SmartDebug のチャネル数の弱点が軽減され、プローブポイントの移動の欠点が軽減されます。tag他の技術のコストも同様に削減されました。

信号分類
最も一般的なシグナルの種類のいくつかを区別することで、デバッグのアプローチを計画する際に役立ちます。例:ampたとえば、システムリセット、ブロックリセット、初期化レジスタなど、システムの起動時以外は変化しない信号は、静的信号として分類できます。これらの種類の信号は、長い再コンパイルサイクルを必要とせずに、信号を簡単に観察および制御できる機能を通じて最も効率的にアクセスできます。アクティブプローブは、静的信号のデバッグに最適な機能です。同様に、頻繁に変化するが、大部分の時間は静的である信号は、疑似静的として分類でき、アクティブプローブを使用して最も効率的にデバッグできます。クロック信号のように頻繁に変化する信号は、動的として分類でき、アクティブプローブから簡単にアクセスできません。これらの信号を観察するには、ライブプローブの方が適しています。

シンプルなデバッグユースケース

さまざまなインサーキットデバッグオプションについて理解が深まったので、簡単な設計例を見てみましょう。ampこれらの手法がどのように機能するかを見てみましょう。図 9 は、SmartFusion2 SoC FPGA デバイスのシンプルな FPGA デザインを示しています。マイクロコントローラサブシステム (MSS) は、CoreSF2Reset ソフト IP ブロックによってリセットされます。このブロックへの入力は、パワーオンリセット、ユーザーファブリックリセット、および外部リセットです。出力は、ユーザーファブリックへのリセット、MSS リセット、および M3 リセットです。エラーの症状は、デバイスが POR 状態を正常に終了しても、I/O でアクティビティがないことです。このエラーをデバッグするための 2 つの異なるオプションも図に示されています。青いボックス (ラベル ETE) は外部テスト機器方式、緑のボックス (ラベル ILA) は内部ロジックアナライザ方式、オレンジ色のボックス (ラベル AP) はアクティブプローブ方式です。エラーの潜在的な根本原因は、CoreSFXNUMXReset ソフト IP ブロックへのリセット入力が不適切にアサートされていることであると想定します。

ここで、これまでに説明した 3 つのインサーキット方式のデバッグプロセスを見てみましょう。

外部テスト機器
この方法を使用する場合、テスト機器が利用可能であり、優先度の高いプロジェクトで使用されていないことが前提となります。さらに、いくつかのFPGA I/Oが利用可能であり、テスト機器に簡単に接続できるように事前に計画しておくことが重要です。たとえば、PCBにヘッダーがあると、ample は非常に役立ち、プローブ中に「可能性のある容疑者」を特定して接続したり、ピンがショートするのを防ぐために費やす時間を最小限に抑えることができます。調査する信号を選択するには、設計を再コンパイルする必要があります。多くの場合、最初の調査ではさらに多くの疑問が生じるだけなので、「玉ねぎの皮をむく」ようなことは起こらず、さらに調査するために追加の信号を選択する必要がありません。いずれにしても、再コンパイルと再プログラミングのプロセスにはかなりの時間がかかり、タイミング違反が発生した場合は再設計が必要です (タイミングクロージャの問題を解決しようとすると、特に設計のバグを見つけるために設計を変更しているときに、どれほどイライラするかは誰もが知っています。プロセス全体に数分から数時間かかることがあります)。また、設計に空きユーザー I/O がない場合、この方法は実装できないことも覚えておく必要があります。さらに、この方法は構造的に設計に影響を及ぼし、タイミング関連のバグが反復間で消えたり再び現れたりする可能性があります。

内部ロジックアナライザ
この方法を使用する場合、ファブリックリソースを使用して ILA をデザインに挿入し、再コンパイルする必要があります。ILA がすでにインスタンス化されている場合、調査する信号がインストルメント化されていない可能性があり、この場合も再コンパイルが必要になることに注意してください。このプロセスでは、元のデザインが変更され、タイミング制約に違反するリスクがあります。タイミングが満たされた場合、デザインを再プログラムして再初期化する必要があります。再コンパイル時間が長く、複数のパスが必要な場合は、このプロセス全体に数分または数時間かかることがあります。このアプローチは構造的に侵入的であり、上記の方法を使用した場合に説明した問題と同様の問題が発生する可能性があります。

アクティブプローブ
この方法を使用すると、アクティブプローブをさまざまなリセット信号のソースに向けることができます。これらの信号はすべてレジスタ出力によって供給されます (優れたデジタル設計方法では一般的です)。信号は、図 10 に示すアクティブプローブメニューから XNUMX つずつ選択されます。選択した信号値は読み取られ、アクティブプローブデータウィンドウに表示されます。誤ったアサーションがあれば簡単に識別できます。このテストは、デバイスを再コンパイルして再プログラムする必要なくすぐに実行でき、構造的にも手順的にも邪魔になりません。プロセス全体にかかる時間はわずか数秒です。この方法では、他の XNUMX つの方法では許可されない制御性 (値を非同期に変更する) も作成できます。この特定の例では、ampたとえば、レジスタによって生成されたリセット信号は簡単にプローブされ、アクティブ状態に保持されていることが検出される場合があります。

リセット信号を生成するレジスタを非同期的に操作することで、リセット信号の瞬間的なトグルを実現できます。

より複雑なデバッグユースケース
上記のデザインは非常にシンプルで、説明したデザイン手法を使用するための入門として役立ちますが、より複雑な例ampleはさらにわかりやすいかもしれません。多くの場合、関心のある信号は、単純な例のように静的な信号ではありません。ample ですが動的です。一般的な動的信号は中間クロックで、シリアルインターフェイスのハンドシェイクのタイミングに使用される可能性があります。図 11 は、ユーザーソフト IP コア (この場合は、システム APB バスに接続されたカスタムシリアルインターフェイス) を使用したこのような設計を示しています。エラーの症状は、ユーザーのカスタムシリアルインターフェイスでアクティビティがないこと、および APB バスマスターがシリアルインターフェイスにアクセスするためにトランザクションを発行すると、ハンドシェイクが正しくないことを示す例外状態になることです。これらの状態は、トランザクションステートマシンが予想される速度で動作していないために例外が発生するため、不正なリセット信号などの静的な原因を排除しているように見えます。根本的な原因は、ユーザー IP コア内のクロック周波数ジェネレーターであると考えられます。

正しい周波数で実行されていない場合は、説明したエラーが発生します。

このような状況では、アクティブプローブアプローチをライブプローブに置き換える方がおそらく良い戦略です。これは、上の図のオレンジ色のLPボックスで示されており、JTAG プローブソース選択用の信号。

外部テスト機器
この場合、方法論は前述の単純な例と非常によく似ている。ample。ユーザークロック信号がテストポイント (できればヘッダー上) に出力され、時間のかかる再コンパイルが必要になります。また、比較信号としてユーザー IP をクロックするために使用されるシステムクロックなどの参照信号を出力することも役立つ場合があります。この場合も再コンパイルと再プログラミングが必要になるため、プロセス全体にかなりの時間がかかる可能性があります。

内部ロジックアナライザ
このケースは単純な例と非常によく似ているample。ILA を挿入するか、必要な信号を定義し、再コンパイルと再プログラムサイクルを実行する必要があります。前述のすべての問題により、依然としてデバッグサイクル時間が長くなります。ただし、さらに複雑な点があります。ILA を駆動するクロックは同期している必要があり、理想的にはユーザーのソフト IP コアから観測されるクロックよりもずっと高速である必要があります。これらのクロックが非同期であったり、タイミング関係が正しくない場合、データキャプチャは予測不可能になり、デバッグプロセスで混乱の原因となる可能性があります。
ユーザーの Soft IP クロックがオンチップで生成されない場合 (シリアルインターフェイスから回復される可能性があります)、設計者は追加のリソースを使用してより高速な ILA クロックを生成するためにクロックモジュールを追加する必要がある可能性があり、タイミング違反が発生する可能性があることに注意してください。

ライブプローブ
この方法を使用すると、ライブプローブをユーザークロックのソースとレジスタからのその他のクロックソースにすばやくポイントして、エラーの根本原因を追跡できます。ライブプローブは、選択した信号出力をリアルタイムで表示するため、信号間のタイミング関係を簡単に判断できます。プロセス全体はわずか数秒で完了します。

シリアルインターフェースのその他のデバッグ機能
また、SmartFusion2 SoC FPGAおよびIGLOO2 FPGAデバイスには、前述の例のようにシリアルインターフェースで使用できる追加のデバッグ機能が多数あることも指摘しておくことが重要です。ampエラーがさらに複雑になるような設計。たとえばSERDESデバッグample は、専用の高速シリアルインターフェイスに特定のデバッグ機能を提供します。SERDES デバッグ機能には、PMA テストサポート (PRBS パターン生成やループバックテストなど)、レジスタレベルの再構成による複数の SERDES テスト構成のサポート (構成変更に完全な設計フローを使用する必要がないようにする)、構成されたプロトコル、SERDES 構成レジスタ、レーン構成レジスタを示すテキストレポートなどがあります。これらの機能により、SERDES のデバッグがはるかに簡単になり、ライブプローブやアクティブプローブと組み合わせて使用することで、複雑な回路のデバッグをさらに高速化できます。
前述のメモリデバッグツールは、SERDES デバッグと組み合わせて使用してテストを高速化することもできます。メモリデバッグを使用すると、メモリバッファを迅速かつ簡単に検査および変更できるため、「テストパケット」をすばやく作成し、ループバックまたはシステム間通信の結果を観察できます。設計者はこれらの機能を活用して、追加の FPGA ファブリックを消費し、チップのタイミングに影響を与える可能性のある特殊な「テストハーネス」の必要性を最小限に抑えることができます。

結論
この論文では、FPGA および SoC FPGA のインサーキットデバッグを実装するためのさまざまなアプローチ (統合ロジックアナライザの使用、外部テスト機器の使用、FPGA ファブリックに統合された専用プローブ回路の使用) について詳細に説明しました。Microsemi が SmartFusion2 SoC FPGA および IGLOO2 FPGA デバイスに提供する Active Probe や Live Probe などの特殊な専用プローブ回路を追加すると、デバッグプロセスが大幅に高速化され、簡素化されることが示されました。内部信号の選択をすばやく変更する機能 (非常に時間のかかる再コンパイルおよび再プログラムサイクルを実行する必要がない) と内部信号をプローブする機能 (FPGA ファブリックを使用する必要がなく、タイミング違反が発生する可能性がない) は、大きな利点であることが示されました。tagFPGA設計をデバッグする際の注意点。さらに、より包括的なデバッグ機能を提供するために連携できる複数の方法論の使用についても説明しました。最後に、2つの例を紹介します。amp説明した方法間のトレードオフを示すために、le debug の使用例を示しました。

さらに詳しく

IGLOO2 FPGA
SmartFusion2 SoC FPGA

Microsemi Corporation (Nasdaq: MSCC) は、通信、防衛およびセキュリティ、航空宇宙、産業市場向けの半導体およびシステムソリューションの包括的なポートフォリオを提供しています。製品には、高性能で耐放射線性に優れたアナログミックスドシグナル集積回路、FPGA、SoC、ASIC、電源管理製品、タイミングおよび同期デバイス、および世界標準の時刻を設定する正確な時刻ソリューション、音声処理デバイス、RF ソリューション、個別コンポーネント、セキュリティ技術、スケーラブルなアンチタイムソリューションなどがあります。amper製品、Power-over-Ethernet ICおよびミッドスパン、カスタム設計機能およびサービスも提供しています。Microsemiはカリフォルニア州アリソビエホに本社を置き、世界中に約3,400人の従業員を擁しています。詳細については、 www.microsemi.com.

マイクロセミ本社

1つ Enterprise、Aliso Viejo CA 92656 USA
内でアメリカ: +1 800-713-4113
外アメリカ: +1 949-380-6100
販売: +1 949-380-6136
ファックス： +1 949-215-4996
メールアドレス: sales.support@microsemi.com

よくある質問

Q: デバイスの最大データキャプチャ頻度はどれくらいですか?
A: このデバイスは最大 100MHz のデータキャプチャをサポートしており、ほとんどのターゲット設計に適しています。
Q: デバッグにプローブ回路を使用する場合、設計を再コンパイルする必要がありますか?
A: いいえ、プローブポイントの位置は、設計の再コンパイルや再プログラミングを必要とせずにすぐに変更できます。