マイクロプロセッサデバッグの歴史、1980〜 2016年

デザインがあったエレクトロニクスデザインの黎明期から、バグがありました。しかし、それらがバグであった場合、必然的にデバッグが行われ、障害、バグ、およびエラーとの壮大なレスリングマッチに従事して、どちらが優勢になるか、そしてどれほど徹底的に決定するかを決定しました。

多くの点で、デバッグテクノロジの進化は、設計のあらゆる側面と同じくらい魅力的です。しかし、それが脚光を浴びることはめったにありません。デバッグは、単純な刺激-応答-観察アプローチから、ますます複雑になる設計に対処するために考案された高度なツール、機器、および方法論へと進化しました。現在、2017年には、機能I / Oを介したデバッグが導入され、新しいエキサイティングな時代の幕開けになりました。

これは、世界中からの何十年にもわたる努力と発明の集大成です。私は1984年からデバッグに携わっています。そのため、現在デバッグで経験しているパラダイムシフトを真に理解するには、長年にわたって行われた革新を振り返ることが役立ちます。

1970年代から1980年代
この時期のシステム設計は、現在の状況とは大きく異なりました。一般的なシステムは、CPU、（EP）ROM、RAM、およびいくつかの周辺機器（PIC、UART、DMA、TIMER、IOなど）で構成され、それぞれが独自のICに実装されています。

1980年代のシングルボードコンピューター（SBC）
（出典：http：//oldcomputers.net/ampro-little-board.html）

典型的な開発フローは、ASMまたはCでコードを記述し、それをコンパイル、リンク、および配置して、ROMイメージのHEXファイルを作成することでした。次に、古いEEPROMをターゲットボードのソケットから取り出し、UV EEPROM消しゴムに入れ、UV光で20分間ブラストします。

EPROM消しゴム
（出典：https：//lightweightmiata.com/arcade/area51/area5114.jpg）

次に、EEPROMをEEPROMプログラマーに配置し、コンピューターからHEXファイルをダウンロードして（通常はシリアルまたはパラレルインターフェースを介して）プログラムします。

EPROMプログラマー
（出典：http：//www.dataman.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/m/e/mempro.jpg）

最後に、EPROMをターゲットボードに接続し直し、電源を入れて、プログラムが機能するかどうかを確認しました。プログラムが期待どおりに機能しなかった場合は、次のようにコードをデバッグするためのいくつかのオプションを利用できます。

コード検査： この場合、エラーを探してコードをじっと見つめながらコードをウォークスルーします。この手法は、デバッグツールの使用をプログラミングスキルの失敗と見なす人々によって今日でも使用されています。これを行うもう1つの理由は、ハードウェアの制限またはコストのために、次の手法を利用できない場合です。

LED： この手法は現在も使用されています。ターゲットシステムにLEDまたはその他のインジケーターがある場合は、コードを変更してコード内の重要な場所の状態を通知することにより、コード内のパスを判別できます。次に、LEDを見るだけで、コードの進行状況（または多くの場合進行状況の欠如）を確認できるため、注意を向ける場所を決定するのに役立ちます。 （デバッグインターフェイスが提供されない場合は、RGBLEDを点滅させるも参照してください。 。）予備のデジタルIOがいくつかあり、幸運にもロジックアナライザーにアクセスできる場合は、プログラムによって出力された状態（場所）をトレースすることで、コード内のパスをリアルタイムで効果的にトレースできます。

ターゲットモニター上： シリアルポート（RS232）とモニタープログラムを含めるのに十分な空きEPROM / RAMを備えたターゲットボードの場合、アセンブリレベルでコードをステップ実行し、レジスタの内容とメモリ位置を表示できます。モニタープログラムは、事実上、独自のコードに含めた低レベルのデバッガーでした。プログラムのどこかで、モニタープログラムにジャンプして、デバッグを開始します。シリアルポートはモニタープログラムとの対話に使用され、ユーザーは「s」などのコマンドを発行して命令をステップ実行し、「m83C4,16」を発行して16の場所の内容を表示します。たとえば、アドレス0x83C4から始まるメモリです。コードが期待どおりに機能すると、通常、最終的なプログラムはモニターを配置せずにビルドされます。

インサーキットエミュレータ： 余裕のある人にとっては、インサーキットエミュレータ（ICE）が究極のデバッグツールでした。いくつかの点で、このツールは、最先端のデバッグツールが今日の開発者に提供するよりも多くの機能を提供しました！ ICEは、ターゲットシステムのCPUを、CPUをエミュレートした電子機器に置き換えます。これらのICEツールは大きく（デスクトップPCよりはるかに大きい）、非常に高価でした—私たちは何千ドルも話しているのです。この時代、ICEは通常、CPUメーカーまたは当時の主要なツール会社の1つ（Tektronix、HP / Agilent、Microtekなど）によって設計され、エミュレーション下のCPUの「ボンドアウト」バージョンが含まれていました。 。ボンドアウトCPUは、文字通り、デバイスのピンに追加の内部信号を出力して、エミュレーターがCPUを制御し、内部操作の可視性を高めることができるようにしました。エミュレーターは、CPUによって実行される操作を監視し、今日の多くの開発者の羨望の的となる複雑なブレークポイントとトレース機能を提供します。オンターゲットメモリ（通常はEPROM）の領域をICEに含まれるエミュレーションRAMに置き換えることも可能でした。これにより、コードをエミュレーションRAMにダウンロードできます。開発中にEPROMを消去したり吹き飛ばしたりする必要はありません。至福のひとときです！

Motorola Exorciser ICE
（出典：http：//www.exorciser.net/personal/exorciser/Original%20Files/exorciser.jpg）
Intel MDS ICE
（出典：http：//www.computinghistory.org.uk/userdata/images/large/PRODPIC-731.jpg）

1982-1990
1980年代に、組み込み開発者向けに3つの主要な変更が行われました。 1つ目は、CPU、PIC、UART、DMAの組み合わせを含むより統合されたICが登場し始めたことです。これらはすべて、1つのデバイスに含まれています。例としては、8086/8088 CPU（元のIBM PC）の進化形であるIntel 80186/80188、Z80（Sinclair Spectrum）の進化形であるZilog Z180、およびMotorola CPU32ファミリー（たとえば、 68302）、これは68000（Apple Lisa）の進化形でした。

2つ目は、ICEが開発者にとってはるかにアクセスしやすくなったということです。いくつかの企業は、CPUメーカーのシステムよりもはるかに低コストでICEツールの製造を開始しました。これらの企業の多くは、ボンドアウトチップを使用していませんでした。これにより、利用可能な機能がわずかに減少しましたが、低コストのICE製品の可用性の向上に大きく貢献しました。 80186のICEは、10,000ドル未満で購入できるようになりました。

3つ目は、CPUクロック速度が絶えず増加しているため、ICEテクノロジに問題が発生し始めたことです。これは、ICEが使用するケーブルシステムに重大な課題を課し、エミュレーション制御テクノロジーに問題を引き起こし始めました。エミュレーション制御テクノロジーは、（再び）非常に高価になることなく、これらの高速で動作することはできませんでした。また、CPUメーカーは、余分なオンチップ接続がチップの動作を妨げるため、CPUのボンドアウトバージョンの作成に消極的になりました。これらの問題の解決策は、CPUデバッグ制御回路をオンチップで構築することでした。これにより、シングルステップ、メモリとレジスタアクセス、およびブレークポイントテクノロジをフルCPU速度で動作させることができましたが、現時点ではトレースを提供していなかったため、デバイスの外部バスインターフェイスピンにアクセスする必要がありました。

多くの内部ペリフェラルアクセスでは外部バスが使用されなかったため、このトレースの機能も低下しました。したがって、外部アクセスのみが完全に表示され、内部周辺アクセスは暗くなりました。オンチップデバッグ（OCD）テクノロジへのアクセスは、独自のインターフェイステクノロジ（通常はBDM（バックグラウンドデバッグモード）と呼ばれます）を介して、または標準のJTAGインターフェイスを介して行われました。これらのインターフェイスにより、企業はクロック速度の制限なしにCPU実行を制御するための低コストのデバッグツールを作成できました。機能は実装間でわずかに異なります。たとえば、CPUの実行中にデバッグツールがメモリにアクセスできるようにするものもあれば、許可しないものもあります。

1990-2000
外部の痕跡はほとんどなくなりました。内部CPUキャッシュの導入と相まって、CPUクロック速度の向上により、外部トレースはほとんど役に立たなくなりました。ただし、より複雑なプログラムの欠陥を診断するには、CPUの実行パスを記録できる必要がありました。課題は、オンチップロジックを使用してこれを行う方法（フルCPU速度で動作できるようにするため）ですが、可能な限り少ないピンを使用して、実行可能なクロックレートでトレースデータをチップから転送する方法でした。解決策は、CPUの実行パスを圧縮データセットに変換することでした。このデータセットは、オフチップで転送してデバッグツールでキャプチャできます。その後、ツールはデータセットを使用して実行パスを再構築できます。デバッグツールが実行されたプログラムにアクセスできる場合、圧縮が不可逆になる可能性があることがわかりました。たとえば、非シーケンシャルなプログラムカウンターの変更のみが出力された場合、デバッグツールは実行中のプログラムの知識を使用して「ギャップを埋める」ことができます。 IBMのPowerPC、MotorolaのColdFire CPU、ARMの7TDMIベースのコア、およびその他はすべて、この概念に基づいてトレースシステムを実装しました。

2000-2010
圧縮されたコアトレースデータセットの導入により、データセットをオフチップで転送するか、比較的小さなオンチップトレースバッファを使用してデータを保持するかを選択できるようになりました。 2000年代初頭、さまざまなベンダーがトレースパフォーマンスの向上に努めました。たとえば、ARMはEmbedded Trace Buffer（ETB）を設計しました。これは、JTAGを介してアクセスでき、トレースデータを保持するようにサイズを構成できます。これにより、SoCでシリコン領域を使用することを犠牲にして、比較的高速のオフチップトレースポートを提供する必要があるという問題が解決されました（ただし、コアクロック速度にはまだほど遠いです）。

2000年代半ばに、組み込みCPU設計者はマルチコアシステムの実装を開始しました。 ARM IPを使用した設計では、JTAGテクノロジーが使用され、各コアはシリアルJTAGスキャンチェーンに表示されます。これは、コアの電源管理が実装されるまで問題ではありませんでした。その結果、電源を切ると、コアはJTAGシリアルスキャンチェーン上で存在しなくなりました。 JTAGは、シリアルスキャンチェーンに現れたり消えたりするデバイスをサポートしていないため、デバッグツールとSoC設計者の両方に問題が発生しました。これを克服するために、ARMはCoreSightと呼ばれる新しいデバッグアーキテクチャを作成しました。これにより、単一のJTAGベースのデバッグアクセスポート（JTAGスキャンチェーン上の1つのデバイス）が、システム内のすべてのARMコアを含む多くのメモリマップドCoreSightコンポーネントへのアクセスを提供できるようになりました。これで、CoreSight準拠のデバイスは、JTAGスキャンチェーンに影響を与えることなく自由に電源を切ることができました（CoreSightテクノロジの詳細については、この新しいホワイトペーパーを参照してください）。このテクノロジーは、現在も設計されている最新の、そしてはるかに複雑なARMIPベースのシステムで使用されています。

2010-
組み込みプロセッサの機能が向上するにつれて（特に64ビットコアの出現により）、デバイスのデバッグをサポートすることがより実現可能になりました。以前は、一般的なデバッグシステムは、実行/トレースを制御するためにターゲットシステムへのJTAG / BDM接続を利用する高性能ワークステーションでデバッグツールを使用していました。 Linux / Androidが広く使用されるようになると、カーネルはオンチップCoreSightコンポーネントにアクセスするためのデバイスドライバーで拡張されました。 perfサブシステムを利用することで、オンターゲットのトレースキャプチャと分析が可能になりました。

ARM Embedded Logic Analyzer（ELA）の導入により、ICEの時代に戻り、複雑なオンチップブレークポイント、トリガー、およびトレースにアクセスして、古いものと同じように内部SoC信号にアクセスできるようになりました。 1980年代初頭に提供されていたボンドアウトチップ。

今日、40年間の革新の後、私たちはデバッグの新時代の先端にいます。この時代では、エンジニアは機能I / Oのデバッグとトレースを実行できるため、時間と費用の両方を節約できます。既存のデバイスインターフェイス上でデバッグを実行するためのプッシュは、よりスリムなソリューションを提供するだけでなく、デバッグおよびトレース機能を次のレベルにステップアップするのにも役立ちます。このようにして、バグとの戦いにおける私たちの魅力的で長い歴史の新しい章が始まります。