On-Chipデバッガ方式

デバッグ機能を全てハードウェアで構成する、市販マイコンで採用されている方式です(図 3参照)。図 3～図 6で紫色はデバッグ機能実現に必要なリソース、黄色はデバッグ対象となるソフトウェアの格納先を示しています。ホストPCとの通信はJTAGベースのシリアル通信路で行います。CPUと並行してバスをモニタし、特定のアドレスやデータが発生するとCPUの実行を中断させる(アドレスブレーク/データブレークと呼ぶ)事ができるので、他の3方式と異なりROM上のプログラムもデバッグすることが可能です。また命令実行毎にCPUレジスタの内容をリアルタイムにダンプするトレース機能もこの方式にしか出来ない特徴です。

しかし機能のサポートに応じて論理規模も増加し、場合によってはCPUよりも大きな論理となる場合があります。

図 3　On-Chipデバッガ方式の構成

ハードサポート方式

On-Chipデバッガまでの機能は求めないが、必要最低限のデバッグ機能は欲しいという場合に採用される方式です(図 4参照)。On-Chipデバッガ同様JTAGベースのシリアル通信を行うので、基板上の専用リソースは必要としません。それ以外の機能は次に解説するROMモニタ方式と同様になります。

CPUベンダーによっては、数点のアドレスブレーク等On-Chipデバッガ方式の一部をハードサポートしているものもありますが、制約が多いため使い勝手が良いとは言えません。

図 4　ハードサポート方式の構成

ROMモニタ方式

CPUのソフトウェア例外発生命令を利用したデバッグ方式です(図 5参照)。ターゲットのROM上に書き込まれたモニタプログラムが起動と共に立ち上がり、デバッグ専用のシリアルインターフェイス(SIO)を介してホストPCとの通信を行います。デバッグ対象の実行バイナリはRAM上にロードされ、実行を中断もしくは停止したい箇所の命令をこの例外命令に置き換えることでCPUの実行管理を実現します。またメモリや変数の参照・変更などそれ以外の機能も全てがCPUのソフトウェアで実現されています。しかしデバッグ対象がRAM上にあることが大前提となるので、最終的にROM化するアプリケーションの場合でも、デバッグ時の事を考慮したRAM容量をターゲットのハードウェアに搭載しておく必要があります。

図 5　ROMモニタ方式の構成

OS依存方式

OSに備わっているデバッグサポート機能を利用する方式です。実行管理はROMモニタ方式と同じです。これまでの3方式とは異なりOSに関係する状態も含めて管理できるので、アプリケーションのデバッグには最適と言えます。しかしこの方式はOSが立ち上がっていることが前提となるので、OS自体のデバッグには前述の3方式のいずれかが必要となります。

図 6　OS依存方式の構成

今回はデバッグ方式を解説する上で解りやすい切り口としましたが、実際はいくつもの方式を組み合わせた製品が出荷されています。例えばOn-Chipデバッガを使いながらOS上のアプリケーションデバッグにも対応したツール等があります。確かにハードウェア＋OSがほぼ固定化されている製品であれば、アプリケーション開発効率を上げる手段としては最適です。しかし今回の連載は汎用的な観点で解説しているので解説の対象からはずしています。周辺情報は各自補って下されば幸いです。

Nios IIの対応

図 7にNios IIのデバッグ機能選択画面を示します。この図はSOPC BuilderでNios IIを組み込むと出てくる画面です。

・No Debugger：ROMモニタ方式、OS依存方式

・Level1、2：ハードサポート方式

・Level3、4：On-Chipデバッガ方式

に相当します。

図 7　Nios II のデバッグ機能選択画面

また下から2段目に追加されるLE数の目安が表示されています。機能に応じて論理規模が大きくなっていることが良く解ります。更にLevel3以上は市販のライセンス購入が必要になるので、デバイスの規模も含めデバッグ機能の導入は予算次第という所でしょうか。

※Level3：First Sililon Solutions(FS2)社のライセンスをお持ちでなくても、16フレーム分であれば、インストラクションのOn-Chip Trace機能をご評価いただけます。