マイクロプロセサを内蔵した組み込み機器向けソフトウエアの開発手法が変わり始めている。命令セットにデバグ専用命令を加えたマイクロプロセサと専用デバガを組み合わせてソフトウエアをデバグする,「オン・チップ・デバグ」と呼ぶ手法を採用する場面が増えてきた。従来のICE(in-circuit emulator)を用いた開発手法では限界に近づいてきたためである。たとえば内部の動作周波数が100MHzを超えるようなチップを搭載する組み込み機器や,マイクロプロセサ・コアに周辺回路を集積したASICを用いた機器の開発で,ICEを使って開発することは難しくなってきている。加えてオン・チップ・デバグには,開発ツールのコストがICEに比べて安いという利点もある。(日経エレクトロニクス誌1999年3月22日号,「NETs特集」,pp.215-225より引用)

 組み込み機器向けソフトウエアの開発で「オン・チップ・デバグ」と呼ぶデバグ手法が定着しつつある。オン・チップ・デバグとは,最終製品に搭載するASICにデバグ専用回路と,デバグ専用命令をもつマイクロプロセサ・コアを集積することによって,デバグする手法である(図1)。従来のICE(in-circuit emulator)を用いた手法では,最終製品に搭載するチップとは別に,マイクロプロセサ・コアと同じ動作をする評価用チップ(エバ・チップ)を別に用意する必要があった。

 オン・チップ・デバグは,決して新しい手法ではない。米Motorola,Inc.などが1980年代から自社製マイクロプロセサに向けたソフトウエアを開発するためのデバグ手法として採用してきた。チップ内部の回路をテストするためのJTAG(Joint Test Action Group)インタフェースを用いて,チップ上のデバグ制御回路にアクセスする。これまでは,ICEを補完する簡易なデバグ手法という位置付けだった。

 しかしここにきて,オン・チップ・デバグの重要性が急激に高まりつつある。チップ内部の動作周波数が高速になったり,マイクロプロセサ・コアを内蔵したASICを組み込む機器が増えた結果,ICEによるデバグは困難になっている。

 ICEを使った手法が抱える問題は,オン・チップ・デバグにはない。その結果,補佐役に過ぎなかったオン・チップ・デバグが,ICEの機能も兼ね備える必要が出てきた。ここにきて日立製作所やNECなどは,ICEを使った手法に比べて弱点とされたリアルタイム実行時のデバグを可能にしたオン・チップ・デバグ機能を搭載したマイクロプロセサやデバガの品ぞろえを強化し始めた。

図1 組込み機器の開発にオン・チップ・デバグ手法が定着へ
マイクロプロセサを組み込んだ機器のソフトウエアのデバグに,オン・チップ・デバグと呼ぶ手法が普及し始めた。オン・チップ・デバグとは,デバグ専用回路を内蔵したチップでソフトウエアをデバグする手法である。従来のICE(in-circuit emulator)による手法では対応できなくなってきた100MHzを超えるような動作周波数が高速のマイクロプロセサのデバグを可能にする。マイクロプロセサ以外のコアを搭載したASICを採用する場面が増えていることもオン・チップ・デバグの普及を促している。ICEによるデバグ手法では,セミ・カスタム品であるASICと同じ動作をするICEの入手は困難である。(図:本誌)

Windows CEも対応へ

 マイクロプロセサ・メーカやツール・メーカは,オン・チップ・デバグの役割が高まってきたことを実感している。「この1年~2年でオン・チップ・デバグに関する問い合わせが非常に増えてきた」(NEC半導体ソリューション技術本部 マイクロコンピュータ技術部プロジェクトマネージャーの松井研司氏や米国ツール・メーカの日本法人イーエスティ マーケティング部長の福徳信夫氏など)。

 組み込み機器市場への本格参入を目指す米Microsoft Corp.は,「Windows CE」を搭載した機器向け組み込みソフトウエアの開発ツール「Windows CE Platform Builder」を,1999年中にオン・チップ・デバグに対応させる予定である。ユーザの要求に応えるためという。Windows CE Plattorm Builderにおいて,マイクロプロセサのオン・チップ・デバグ命令を発したり,マイクロプロセサからデバグ・データを受け取り解析できるようにする。コードを1行ずつ実行させるステップ機能,実行の履歴を確認するトレース機能,レジスタの内容を書き換えたり読み出したりする機能に対応する。

 レーザ・プリンタや自動車用ナビゲーション・システムなどでは,搭載しているマイクロプロセサ内部の動作周波数が上がり続けている。今後,オン・チップ・デバグは,機器向けのソフトウエア開発を中心に,必須のデバグ手法になりそうだ。

ICEがデバグに,使えなくなった四つの理由

 ここにきてオン・チップ・デバグへの関心を急速に高めている要因は,大きく四つある。すなわち,1.マイクロプロセサ内部の動作周波数の高速化,2.マイクロプロセサに周辺回路を集積したセミ・カスタムLSIを組み込む機器の増加,3.パッケージのピン数の増加,4.開発コスト削減に対する要求の激化である。

ICEの限界は60MHz程度

 1.マイクロプロセサの動作周波数が高くなると,ICEでのデバグが難しくなる。ICEは,最終製品に搭載するチップのマイクロプロセサ・コアの代わりとなるエバ・チップ,ワーク・メモリ(代替メモリ)やタイマやインタフェースなど周辺回路で構成している。実チップでは同じチップ上に集積していたワーク・メモリと周辺回路を,ICEではプリント基板上で配線する。このため実チップ内部の動作周波数が60MHzが超えたあたりから,遅延時間が問題になってプリント基板上で同じ動作を再現できなくなる。

 たとえば,あるコードにブレーク・ポイントを設定し,そのコードで動作を止めるプログラム・ブレーク機能を使う場合を考える。ブレーク・ポイントを設定したコードのアドレスを判定して,エバ・チップに停止命令を発して,実際に動作を止めるまでの処理を,1クロック以内で行なう必要がある。動作周波数が高くなり,ICEのプリント基板上での配線遅延時間が長くなると,1クロック以内で,こうした処理を終えることが難しくなくなる。この結果,動作周波数を低くしてデバグするなどの対策が必要になる。

 これに対し,オン・チップ・デバグ手法では,一部のトレース機能を除き,チップの動作周波数でのデバグが可能になる(表1)。

 100MHzを超える動作周波数のマイクロプロセサを多くの技術者が機器に組み込むようになったのは,この1年~2年のことである。レーザ・プリンタや自動車用ナビゲーション・システムなどへの搭載が進んでいる。携帯機器向けでも動作周波数は今後ますます高速になっていく。消費電力を減らすためになるべく低い周波数で動作させていた携帯電話機向けでも,次世代のW―CDMA方式向けでは,100MHzなどで動作させることがある。100MIPS以上の最大処理能力が必要だからである。

 2.セミ・カスタムLSIに対応するICEは,ユーザが開発する必要がある。マイクロプロセサ・コアや汎用インタフェース回路のみを搭載した汎用LSI向けならば,ツール・メーカやマイクロプロセサ・メーカがICEを用意する可能性が高い。しかしユーザごとに異なるカスタム品向けにICEを用意するツール・メーカや半導体メーカはほとんどない。

 たとえばW―CDMA電話機向けディジタルLSIは,マイクロプロセサやDSPなどのコアに加え,端末メーカ独自の回路を1チップに集積する。ICEを使う手法では,ユーザである電話機メーカが,電話機メーカごと,機種ごとに異なるLSI対応のICEを用意することになる。

表1 オン・チップ・デバグとICEの違い(表:本誌)


価格はICEの1/10以下

 3.実チップのパッケージのピン数が増加すると開発中のプリント基板を接続しにくくなる。開発中のプリント基板上に用意したピン数が数百本のICソケットにコネクタ(プローブ)を接続しても,ソケットの端子との接触が不十分になってしまう恐れがある。最終製品では,直接ハンダ付けするので,接触不良の問題はない。

 4.ICEを使ったデバグでは,開発コストを削減したいという要求に応えることができなくなってきている。オン・チップ・デバグを採用した場合のデバガの価格は,ICEの価格に比べ,1ケタ安い。たとえば,日立製作所がオン・チップ・デバグに対応する「SH―3」と「SH―4」の一部品種向けに発売しているデバガ「E10A」の価格は,9万8000円である。これに対し,ICEの価格は100万円以上であることが多い。

 「自動車用ナビゲーション・システム・メーカが,大半のICEをオン・チップ・デバガに切り替えて,開発ツールのコストを1/10にした例がある」(マイクロプロセサ・メーカの技術者)。多くの組み込み機器の開発現場では,ハードウエア中心の技術者とソフトウエア中心の技術者それぞれが,デバガをもちたいという要求が強い。特にソフトウエアの開発コードが増大している自動車用ナビゲーション・システムなどの組み込み機器では,ソフトウエア開発者の数が増えており,すべてのソフトウエア技術者がICEを持つと,コストがかさんでしまう。そこで大半の技術者は,オン・チップ・デバグ用のデバガを持ち,一部の技術者のみがICEを持つようにする。上述の自動車用ナビゲーション・システム・メーカは,約9割のソフトウエア技術者がオン・チップ・デバグ用デバガを,約1割のハードウエア技術者がICEを持つようにした。ICEが必要なのは,オン・チップ・デバグ用デバガだけではデバグできない場合があるためである。この点に関しては後述する。またハードウエア技術者は,ICEの利用に慣れていたという理由もある。

専用デバガと組み合わせて使う

 オン・チップ・デバグは,次のようなシステムで行なう。デバグ機能を内蔵したマイクロプロセサはプリント基板に搭載し,プリント基板上に用意した端子数が10ピン前後のデバグ専用コネクタからデバグ専用ピンの信号を引き出せるようにしておく。このコネクタ経由でケーブルを引き出し,デバガと接続する。デバガはマイクロプロセサ上のデバグ機能を制御する回路やパソコンとのインタフェース回路などを内蔵する。デバガは,パソコンにPCカード・スロットやRS―232Cなどのインタフェースで接続する。パソコンには専用のソフトウエアをインストールする必要がある。

デバグ回路でアドレスを比較

 マイクロプロセサに搭載するデバグ専用回路は,デバグ制御回路,命令とデータを一時的に格納しておくためのシフト・レジスタなどを内蔵する(図2)。デバグ専用回路は,マイクロプロセサ・コアと内部バスにアクセスできるようになっている。ICEでは,内部バスの出力端子を備えたエバ・チップ,周辺回路,メモリ,デバグ制御回路をプリント基板上に搭載していた。これに対しオン・チップ・デバグでは,マイクロプロセサ・コアと周辺回路,メモリを同一のチップに,デバグ制御回路も内蔵する。デバグ制御回路には,アドレスを判定するための比較回路を含む。

 デバグ専用回路の規模は,1万ゲート前後である。たとえばNECの場合,プログラム・ブレークとプログラム・ウォッチの機能のみを実現する場合は5000ゲート,さらにトレース機能も実現できる場合は1万5000ゲートである。

図2 デバグ専用回路を搭載する
オン・チップ・デバグ対応のマイクロプロセサは,マイクロプロセサ・コアに直接アクセスできる専用バスを備えたデバグ専用回路を内蔵している。たとえば外部のインタフェース回路からデバグ命令を与えると,このデバグ専用回路がマイクロプロセサの実行している命令を抽出し,外部端子に出力する。米Motorola,Inc.の「MPC860」の例。(図:モトローラの資料に本誌が加筆)


デバグ専用モードで起動

 デバグの手順は,マイクロプロセサ・メーカによって異なるが,おおよそ次のようになる。デバグ専用回路を内蔵したマイクロプロセサの動作モードは,デバグ・モードと通常モード(ラン・モード)の2種類がある。デバグ・モードとは,デバグ制御回路を起動するモードである。デバグ時のみに使う。一方通常モードはソフトウエアを処理するモードである。通常モードで動作しているときは,デバグ専用回路はマイクロプロセサの動作に影響を与えないようになっている。

 デバグを開始する場合には,常にデバグ・モードで起動する。そしてデバグ・モードでデバグ回路を動作させてから,通常モードに移行する。終了する前にはデバグ・モードに戻る。たとえばプログラム・ブレークやプログラム・ウォッチを実行する場合は,まずデバグ・モードでデバグ制御回路の初期設定を行なう。その後,通常モードに移行し,デバグ制御回路にアドレスを監視させる。

 終了前に通常モードからデバグ・モードに戻るためには,プログラムの中に「デバグ・モードに戻れ」という意味のデバグ専用命令をあらかじめ挿入しておく場合と,デバグ専用端子のステータスを変化させるなどの方法で戻す場合がある。マイクロプロセサによって,このいずれか,または両方で実現できる。

リアルタイム・トレースに限界も

 オン・チップ・デバグによる開発手法には,今のところICEの機能を完全に代替しているとは言えない。プログラムの実行中にリアルタイムで実行したコードなどを開発者が観察できるようにするためのリアルタイム・トレース機能を利用できなかったり,利用できてもすべてのコードを観察できないことがある(下掲の「リアルタイム・トレースは現行では32~64ビットまで」参照)。

 これは,デバグ専用端子からデバグに必要なデバグ・データをデバガに出力するためのバス幅が狭いことによる。現在発売中の製品では,最大でも4ビット幅である。1ビット幅(シリアル)の製品もある。8ビット幅のコードをトレースしたい場合は,転送できるコードは1/8~1/2になってしまう。各社は,こうした問題の緩和策を用意している。

 一般的にICEのエバ・チップは,実チップの内部バスや外部バスの幅と同じバス幅でデバグ・データを取り出す。このため,すべてのコードをリアルタイムに転送することが可能である。

リアルタイム・トレースは現行では32~64ビット品まで
 オン・チップ・デバグ機能で,実際にICE並みのリアルタイム・トレースが可能か検証してみよう。デバグ・データのリアルタイム転送能力の向上を優先している日立製作所の方法を例に取る。
 同社のSH―4シリーズでは,データのバス幅は最大64ビットである。データ量を圧縮しない場合,デバグ・データをリアルタイムで転送するには,単純計算で16(=64/4)倍の転送速度が必要になる。デバグ・データを転送するための専用端子が4ビット幅だからだ。ここで分岐などの部分でのみデータを転送する圧縮の効果を考慮すると,データ量は1/15(=1/5×1/3)になる。この試算では,デバグ・データのうち15/16を転送できることになる。データの圧縮率はプログラムによって異なるため,リアルタイム・トレースが可能になる場合もあり,64ビット品がリアルタイム・トレース可能なぎりぎりの上限といえそうだ。32ビット幅なら余裕をもってリアルタイム・トレースできることになる。

 なお,リアルタイム・トレースの実行中にデバグ・データを転送しきれなくなった場合は,デバグ・データの転送を止めるか,プログラムの実行をいったん停止する。どちらにするかは,ユーザが選択できる。

 今後登場するバス幅が128ビット以上のチップをリアルタイム・トレースできるようにするには,デバグ・データのバス幅を8ビットなどに拡大する必要があるだろう。日立製作所は,SH―4など現行シリーズでは4ビット幅を維持する予定としているが,次のシリーズについては白紙の状態である。

各手法を比較,デバグ専用端子の数に差

 オン・チップ・デバグの実現手法は,マイクロプロセサ・メーカごとに異なる(pp.224―225の「オン・チップ・デバグの標準,まもなく仕様策定」参照)。日立製作所,Motorola社,NECの例で比較してみよう。デバグ専用端子数や,JTAGと端子を共用するか,などの点に差がある(表2)。

 いずれもICEによるデバグ手法に比べて見劣りするリアルタイム・トレース機能の改善を目指した技術を採用している。具体的には,まずJTAG以外のデバグ専用端子を設けている。加えて,デバグに必要なデバグ・データを転送する際のフォーマットに工夫を凝らしている。特に日立製作所とNECの両社は,リアルタイム・トレース機能を実現するために,この2点をJTAGを用いた従来手法に比べて,大幅に改良している。

注1)日立製作所とNECはデータのバス幅を2や8などに変更可能。Motorla社が推奨するコネクタの端子数は10。


端子数と実行転送速度はトレード・オフ

 デバグ専用端子の数は,データ転送速度とトレード・オフの関係にある。デバグ専用端子は,マイクロプロセサの性能向上には貢献しないため,デバグのことを考慮しなければなくしたい端子である。一方,デバグ・データを高速転送するためには,バス幅を大きくした方が効率的である。

 デバグ・データのフォーマットには,データの単位を固定長にして転送する方法と,可変長にする方法がある。可変長にすると,デバグ・データを必要最小限に区切って転送できるため,デバグに必要なデータを効率よく転送しやすい。ただしデータの区切りを示すためのヘッダを付加するか,区切りを示すデータを別途送信する必要がある。固定長にすると,データの区切りを必ずしも知らせる必要はないが,データの転送効率は一般に低くなる。

日立は転送速度,NECは端子数の削減を優先

 日立製作所は,デバグ・データの実効的な転送速度を高めることを優先した仕様を採用している。具体的には,デバグ・データ向けのバス幅を4ビットとしている。これとは別にデバグ・データが同期するクロックと,データの区切りを示すストローブ信号用の端子が必要になる(図3(a))。すなわち,合わせて6本の端子が必要である。

 この仕様では,4ビット幅のバスにデバグ・データのみを転送できるようにしている点が特徴である。ストローブ端子を別に設けたことで,ヘッダなどデバグ・データとは無関係のデータを流す必要がない。さらにデバグ・データの単位を可変長としている。

 一方,NECは,実効的な転送速度よりも必要な端子数の削減に留意した仕様を採用している。クロック端子はJTAGのクロック端子と共通化し,ストローブ用の端子は使わない(図3(b))。デバグ・データのバス幅は,日立製作所と同じ4ビットである。JTAG用の端子をすでに備えているという前提に立てば,デバグ専用端子は4本ですむ。

 この仕様では,ストローブ端子がないため,デバグ・データの区切りを示すために4ビットのヘッダを付加している。その後に続くデバグ・データは最大48ビットとした。

 Motorola社は,従来のJTAGの仕様を引き継いだ仕様を採用している。JTAGと同様にデバグ・データは,シリアル・データとして転送する(図3(c))。転送するデータは固定長である。日立製作所とNECの手法に比べて,デバグ・データのバス幅は狭いのは,同社の従来製品との互換性を保つために変更していないからである。

 なお,日立製作所とNECのデバグ・データの幅は4ビットの固定ではない。ユーザの要求に応えて,あるいはマイクロプロセサの種類に合わせて変更する可能性がある。

図3 デバグ・データのインタフェース手法の比較
デバグに必要なマイクロプロセサ内部のデータ(デバグ・データ)を,外部に出力するための方法をマイクロプロセサ・メーカごとに比較した。この方法の差は,デバグ・データの有効転送速度と,デバグ・データの取り出しに必要な端子数に影響する。(a)日立製作所の手法では,クロックと,データの始まりを示すストローブを使ってデバグ・データを外部に出力する。(b)NECの手法では,ストローブを使わない。デバグ・データは,4ビットのヘッダを付けることで区切る。(c)米Motorola,Inc.の手法では,デバグ・データをシリアル・データとして出力する。(図:本誌)

必要なデバグ・データのみを転送

 日立製作所とNECは,いずれもリアルタイム・トレース時に,なるべく高いクロック周波数でもコードを転送できるように,デバグに不要なデータを省く工夫をしている。具体的には,プログラムの分岐やループなど,デバグする上で重要なコードのみを転送する(図4)。実際にはコードそのものを転送するのではなくコードのアドレスを転送する。プログラムの分岐部分では,分岐元と分岐先のコードのアドレスのみを転送する。こうすることで,リアルタイム・トレース時に転送するデータ量は1/5程度に減るという。これは転送頻度が約1/10に減って,1回の転送で2個のデータをまとめて転送するためである。転送されなかったコードは,ソース・コードから復元する。転送されたコードのうち,正しく実行されていることを確認できたコードの間にあるコードは,転送されていなくても正しく実行されたとみなす。

 日立製作所は,さらに実効的な転送効率を高める工夫をしている。具体的には,コードのアドレスを転送する際に,現在のアドレスと分岐先などのアドレスとの差分のみを転送する。アドレスが8ビット幅でも,差分データが2ビットや3ビットなどと小さくなる場合は多い。同社の手法では,デバグ・データを可変長で転送するため,転送するデータ

4 リアルタイム・トレース時のデバグ・データを削減するための手法
日立製作所やNECのデバグ手法では,マイクロプロセサが実行したコードをリアルタイムに出力するリアルタイム・トレースを行なう場合に,デバグ・データを必要最小限に削減している。分岐やループなどの場合のみ,データを出力し,その間のデータはソース・コードから補完する。これは,デバグ・データを4ビットなどと狭いバス幅で,チップの動作周波数に同期したクロックに合わせて出力するため,すべてのデバグ・データを出力することができないからである。そこでトレースする上で重要なコードのみを出力することで,デバグ専用バスがボトルネックとならないようにする。(図:本誌)

オン・チップ・デバグの標準,まもなく仕様策定

 現在のところオン・チップ・デバグの手法は,マイクロプロセサ・メーカごとに異なり,標準化されていない。しかしここにきて標準化に向けた動きが出てきた。業界団体「NEXUS」が,まずは自動車のエンジン制御用マイクロプロセサ向けに,オン・チップ・デバグ機能の標準化作業を始めた。オン・チップ・デバグの物理的インタフェースとデバグ・データのフォーマット,デバグ制御命令などを標準化する。

 NEXUSの主要メンバは,3社のマイクロプロセサ・メーカと2社のツール・メーカである。マイクロプロセサ・メーカは日立製作所,米Motorola,Inc.,独Siemens Semiconductor社。ツール・メーカは米ETAS社と米Hewlett-Packard Co.である。

 1998年4月に活動を始めた。1999年2月に暫定仕様のRevision0.9を策定し,インターネットのWWWサーバ上に公開している(URLはhttp://www.nexus-standard.org/)。仕様の第1版(Revision1.0)は1999年4月をメドに策定,公開する予定である。

自動車業界が要望

 標準化は,マイクロプロセサ・ユーザに大きな利益をもたらす。標準化されると,マイクロプロセサ・ユーザは,手持ちのデバグ・ツールを使って,複数のマイクロプロセサをデバグできるようになる。新しいマイクロプロセサに移行しても,ツールを買い換える必要はなくなる。使い慣れたツールを永続的に使える上,デバグ・ツールの新規購入コストを抑えられる。実際,NEXUSの標準化を望んだのは,マイクロプロセサ・ユーザである自動車メーカだった。
 標準仕様ではエンジン制御用マイクロプロセサ向けだけではなく,次のような応用も想定している。すなわち,エンジン制御と同様にリアルタイム制御が必要なハード・ディスク装置,データ処理量が多いレーザ・ビーム・プリンタ,命令コード数の多いハブやルータである。ただし標準といっても日立製作所やMotorola社は,当面は各社の独自方法と並存させる形で,特定の応用向けのみに採用することになりそうだ。

JTAGのみまたは拡張端子を使用

 NEXUSの暫定仕様(Global Embedded Processor Debug Interface Standard Revision0.9)では,四つのクラスを規定している。クラス1は,物理的インタフェースとしてJTAGのみを利用する。クラス2~クラス4では,拡張端子を追加している。

 クラス1~クラス4のいずれもプログラム・ブレーク/ウォッチ機能を実現できる。クラス2では,クラス1の機能に加えプログラムのリアルタイム・トレースなどが可能になる。クラス3では,クラス2の機能に加え,プログラムの実行中に読み書きしたデータとメモリの割り当て状態をリアルタイムで観察できる。クラス4では,クラス3の機能に,デバガ側からプログラムの命令コードを実行する機能を追加する。

 拡張端子の数は次の推奨仕様を決めている。クラス2では2本(デバグ・データの出力用には1本),クラス3および4では,最大20本(同2,4,8,16本)である。