« 2007年7月 | トップページ | 2007年9月 »

2007.08.31

JTAGの次の規格

これまで何度も述べてきたようにJTAGの本来の機能はバウンダリスキャンですが、現在ではJTAGはバウンダリスキャンだけではなく、CPUのデバッグや、FPGAの書き込みなど、いろんなことに使われています。

CPUデバッグや、FPGAの書き込みなどは、JTAGの規格で定められていた「オプションの機能」を使って実現しています。つまりJTAGを便利なシリアル通信ポートのように使っているだけで、その中で流れているプロトコルはベンダーによって全く異なります。
その方法はベンダーごとに異なり、統一が取れていません。CPUやFPGAのデバッグや書き込み方法は、それぞれのデバイスの内部構造も違うことですし、各ベンダーの発展の経緯があるので当然といえば当然です。

ところが、最近になってCPUのデバッグやFPGAの書き込みについて、標準規格が定められるようになってきました。


FPGAやコンフィグROM、CPLDについてはIEEE1532という規格があります。
これらのデバイスに書き込むには、データファイルと書き込みアルゴリズムが必要です。XILINXの場合、JEDファイルやBITファイルというのがデータファイルです。ALTERAの場合は、SOFやPOFといったファイルがデータファイルです。

データだけあっても、実際のデバイスへの書き込みアルゴリズムを知らなければ、書き込みはできません。
ですが、書き込みアルゴリズムについてはFPGA以外は非公開が普通です。

XILINXでは、サードパーティのツールや組み込みプロセッサからでも容易に書き込めるように、SVFやXSVFファイルを出力することができますが、SVFやXSVFファイルなどはアルゴリズムとデータを結合させてしまっているので、データだけ差し替えることはできませんが、"実行"するのは容易です。

ただし、SVFは条件判断ができないので、書き込み時間などを最適に調整することはできません。また、SVFファイルやXSVFファイルを作るにはiMPACTを使う必要があります。なぜなら、アルゴリズムを知っているツールはiMPACTだからです。
(※もちろん、MITOUJTAGはアルゴリズムを知っているので、SVFやXSVFを中継しなくても書けます。)

アルゴリズムはベンダーやデバイスごとに異なるので、この状況をなんとかしようと定めたのが、IEEE1532という規格です。IEEE1532というのは、JTAGを使った書き込みアルゴリズムを公開してしまいます。最近になって比較的まともにサポートされるようになってきました。
IEEE1532では、BSDLファイルの中に書き込みアルゴリズムが書いてあります。ですが、これでオープンになったと喜ぶのは尚早です。
IEEE1532で使われるデータファイルは、JEDやBITではなく、ISCファイルという変なファイルです。これを作るのにはやはりiMPACTやQualtusに指示しなければなりません。やっぱり、各社とも秘密にしたいところがあるのでしょう。

実際に、IEEE1532はあまり、いや、全く流行っていません。

FPGAベンダーは、IEEE1532に本気で対応させてもメリットはなさそうです。IEEE1532を使わずにネイティブの環境(iMPACTなど)で書き込んだほうが楽だし、小回りもききます。

また、サードパーティの書き込みツールベンダーにとっても、メリットは少ないでしょう。FPGAの書き込みツールはベンダー純正のが既に無料で提供されているのです。Windowsで動く書き込みIEEE1532ツールは商業的に作ってもメリットがないし、組み込みプロセッサから書き換えるならSVFやXSVFがあります。
そういう理由から、今後も流行らないと思われます。

一方、各社まちまちだった、CPUのデバッグについても標準規格を定めようという動きがあるようです。
それはNexus 5001、IEEE-ISTO 5001™-1999というのですが、JTAGのインタフェースを使ってCPUのデバッグプロトコルを統一したい、というもののようです。

http://www.nexus5001.org/index.html
仕様書は上記のページからダウンロードすることができます。

読んでみましたが、どうも流行るとは思えません。
CPUのベンダーはこの規格に従ってデバッグインタフェースを作りたいと思うでしょうか?

従来からあるCPUの後継品種を、この規格に合わせるメリットがあるとは感じられません。
従来どおりのデバッグインタフェースを踏襲したほうが各CPUのアーキテクチャに合うでしょうし、デバッガの動作も速いでしょうし、わざわざリスクを冒してまでデバッグインタフェースを標準化する理由が(CPUベンダーにとって)あるでしょうか。
むしろ、デバッグインタフェースプロトコルは秘密にしてしまいたい考えるベンダーのほうが多いくらいだと思います。

ただし、全く新規にFPGA内蔵のCPUコアを作るというのであれば、採用される可能性は十分にあります。当社が現在開発しているJTAG-ICEも、いずれこのNexusにも対応させるかもしれません。
自作のCPUコアにNexus互換のデバッグインタフェースを入れて、どのJTAGデバッガからでもデバッグできるようになる。いつかそんな日が来るかもしれません。

このようにCPUのデバッグ方法やFPGAの書き込み方法をオープンにする動きはありますが、どちらもあまり流行らないと思われます。メリットがないからです。

| | コメント (1)

2007.08.27

V850用JTAG-ICEの開発(つづき)

開発中のV850用JTAGデバッガがだいぶん完成に近づいてきました。
V850jice_08281

今回のJTAGデバッガは、内蔵フラッシュROMにも、内蔵RAMにも同じようにダウンロードできます。あと1ヶ月以内にリリースされると思います。ご期待ください。

先週末には、このJTAGデバッガと、GCCやGDBとの連携を確認しました。
GDBスタブ機能を動かして、GDBやInsightから接続を受けて動作できるのを確認しました。

V850のプログラムをRAM上で動くようにGCCでコンパイルしダウンロードして実行すると、FPLでROMに書き込んでから実行するのとくらべて、圧倒的に待ち時間が短くできます。

V850jice_08282

GDBとの接続を試していて困ったことは、GDBはV850のレジスタが66個もあると思い込んで作られていること。
V850には32個の汎用レジスタと12個のシステムレジスタしかありませんが、GDBはシステムレジスタが32個あると仮定して未定義なものも含めて読み出そうとしてきます。さらにプログラムカウンタと、FPという謎のレジスタも含めて66個を読み出そうとしてきます。
V850のマニュアルを読んでもFPなんてレジスタはないので、なんだこりゃということになるのですが、どうやらGDBのソースを読んでみるとFPというのはレジスタ29の別名らしいです。GCCが関数呼び出しの最適化にでも使うものなのでしょうか。詳細は不明。

それから、GDBはリモート接続した際に、RUNコマンドが入力されると、勝手にkillパケットというのをスタブに送ってしまうようです。killパケットを受け取ったらスタブは接続を切断しなければならず、その後どのようにしてよいやら。killを送ったGDBのほうはTCPの接続を切ったつもりになっているので、スタブ側から何を送ってもそれ以降GDBは反応しなくなります。

GDBのソースを読んでみると、ターゲットのPIDがヌルなIDでなくターゲットが既に実行中の場合には、RUNの前にKILLを行う、という方針になっていました。
うーん、GDBのリモート機能というのは、ターゲットとの論理的な接続と、ターゲットCPUのプロセスが動作しているかことがごっちゃになっているような感じなのですが、なんでなのかは詳しくはわかりません。調べてもいません。そういうものなのでしょう。

ターゲットにKILLコマンドを送った後、じっと待ってればGDBから再接続を試みてくるので、何度かやれば正常にRUNできるのですが、気持ちが悪いです。
ともかく、LOADコマンドでプログラムをロードしたら、RUNではなく、CONTでプログラムを動かせばよいようなので困ることはないようです。

ああ、Insightは重いし不安定。GDBは気絶するほど難解な操作性。
正直、マニア以外にはきついです。
BorlandやMicrosoftの統合開発環境でWindowsのプログラムをデバッグするのとは雲泥の差です。

もうGDBは介さずに、JTAGデバッガ上からCのソースコードデバッグができるようにしたいなと、すこし思い始めてきました。

| | コメント (0)

2007.08.14

6都市FPGAカンファレンスに出展します

特殊電子回路は、9月14日(金)に開催される「6都市FPGAカンファレンス※」に出展します。
特定非営利活動法人FPGAコンソーシアムの主催するFPGA専門の展示会です。

「6都市FPGAカンファレンス」では、JTAGバウンダリスキャンをFPGAの設計に活用するための技術について紹介する予定です。

弊社展示の趣旨
電子回路、とりわけ、組み込み機器のデバッグでは、ひとたび「ちゃんと設計したはずの基板が動かない」、「CPUが動いているのかどうかさえわからない」、「FPGAが起動しない」、「配線がちゃんとつながっているのか怪しい」などの問題が発生すると、原因究明に無駄な時間を費やしてしまうことになりかねません。

従来は、このような問題の解決には経験と勘のようなものが必要とされてきましたが、JTAGを使うとこれらのデバッグに要する時間を大幅に削減することができ、問題点を素早く見つけることが可能になります。

このような事例をデモ形式で展示します。

本展示会では、
・JTAGバウンダリスキャンを視覚的に行うことができるソフトウェア「MITOUJTAG」
・論理シミュレータとバウンダリスキャンを組み合わせた「ICエミュレータ」
・C言語で気軽に書いたとおりにFPGAが動く「Advanced JTAG Function Generator」
などを展示する予定です。

また、展示のほかに講演もご用意しておりますので、是非とも皆様お声がけの上、ふるってご参加ください。

もちろん、本展示会では、MITOUJTAG体験版の無償配布も行いますので、どうぞお越しください。MITOUJTAGや弊社製品について忌憚のないご意見をうかがわせて頂ければ幸いです。

多くの皆様のご来場を心よりお待ちしております。

会期
 平成19年9月14日(金)
会場
 キャンパスイノベーションセンター
展示内容
 ●FPGAが論理合成せずに動かす新技術、「ICエミュレータ」の紹介
 ●バウンダリスキャン可視化ソフト「MITOUJTAG」の紹介
 ●MITOUJTAG体験版CD-ROM配布
講演日時
 10:40~11:10ごろ 「バウンダリスキャンを活用したFPGA設計方法」
交通機関
 ● JR山手線・京浜東北線 田町駅

※ 今年は東京会場のみ出展します。

| | コメント (0)

2007.08.06

軽井沢にいってきた

5日~6日にかけて、軽井沢に行ってきました。
東京から意外と近くて車で2時間弱でいけました。
リゾート地は人がいっぱい、車もいっぱい。おまけに暑い。でも、楽しかったですよ。
開発もいいけど、たまにはバカンスもいいものです。

いつか会社を大きくしたら、軽井沢オフィス兼保養所を作り、
夏の間は社員が自由に軽井沢で開発できるようにする、なんていう夢を描いてみるのもいいですね。

| | コメント (0)

2007.08.05

V850ES用JTAG-ICEの開発

先月から始めたV850ES/JG2用のJTAG-ICですが、ちょっとづつちょっとづつやりながら、ようやく開発が進んできました。ステップ実行機能やハードウェアブレークポイント機能を実装し、実用的なJTAGデバッガとなりつつあります。

V850ice

先週から今日にかけては、V850の内蔵フラッシュROMへのデータの書き込みルーチンを作っていました。JTAG経由でV850内蔵のフラッシュにあと少しでプログラムの書き込みができるというところまでいきました。

好きなプログラムを作るのって、楽しい時は楽しいですね。ついつい時間を忘れてのめりこんでしまいます。

現在、消去やブランクチェック、テスト用データの書き込みは成功しています。
あとはブランクチェックや、ELFファイルをダウンロードして、それをフラッシュROMに転送するというルーチンがあれば、ひととおり使えるようになるでしょう。

このJTAG-ICEは、XILINXのパラレルケーブルを使ってV850ES/JG2と接続できます。
ところが、XILINXのパラレルケーブルには汎用ポート出力がありません。
V850ESの仕様では、内蔵フラッシュに書き込む時にはFLMD0端子(付録基板のJ1)を操作しなければなりませんが、パラレルケーブルからはそれ用の信号が出ていないため、ジャンパJ1を手動でカチカチする必要があります。ですが、JTAG経由でフラッシュに書き込めれば、かなり開発が快適になるはずです。

あとは、GDBと接続する機能もほしいですね。

もしV850設計コンテスト出場予定の方や、各種ロボコン、その他いろいろな理由でこのデバッガを早く試してみたいという方がいらっしゃいましたら、ぜひご連絡ください。

| | コメント (4)

2007.08.04

FPGAが論理合成しなくても動く(5)

前回は、スクリプト言語でFPGAの動作を記述することで、基板検査や迅速なプロトタイピングができるということを説明しました。

今回は、新製品の核心部分である「ICエミュレータ」について説明します。

実は、いままで何回かにわけて説明してきたAdvanced JTAG Function Generator自体は、従来の技術と比べて新規性やそれほど大きな進歩性があるわけではありません。C言語や独自の言語、テストベクタや、H/L表などで書いたとおりにFPGAやASICの端子を動かしていくというのは、基板検査ソフトウェアなどでは従来からあった技術です。

これらの技術を総括して言うと、「与えられた記述のとおりに順番に手順を実行していく」といえるでしょう。たしかに条件分岐やサブルーチンコールなどが使える製品もありますが、基本的にはあらかじめ与えられた手順に従って実行していくという点は変わりません。どちらかというと、VHDLやVerilogで記述したシミュレーション用テストベクタと同じ類のものでしょう。

ところが、ICエミュレータは違います。

これは、FPGAの論理合成を行うために記述したVHDLやVerilogのソースコードを解読して、その記述と入出力信号の状態から当該FPGAが次に出力するだろうという値をパソコンで計算し、その出力信号を実際のFPGAから出力するというものです。FPGAが入力する信号のキャプチャと、FPGAが出力する信号のセットは、JTAGを通じて行われます。

ICエミュレータ

つまり、パソコンの中では、バウンダリスキャンソフトウェアと論理シミュレータが連携して動作する形になります。

ターゲット基板上のFPGAは、I/O端子をパソコンのコントロール下におかれ、FPGAが入力した信号はパソコンに送られ、パソコン上で論理シミュレーションの計算が実行され、その結果をJTAGバウンダリスキャンでFPGAから出力するのです。

ICエミュレータの動作速度は、FPGAの本当の動作速度に比べてはるかに遅いです。論理シミュレーションの計算速度とバウンダリスキャンの入出力速度によって動作速度は制限されます。

ところが、FPGAのソースコードを書いたら論理合成されずにインタプリタのように動くという効果は、従来のFPGA設計スタイルを大きく変化させる可能性を秘めています。

ICエミュレータを使うときには、FPGAは実際には何も動作せず、すべての動作はパソコン上で計算(エミュレート)される形になります。
この製品を使うと、FPGAは従来のようにVHDLやVerilogで記述されたとおりにしか動作できないということはなく、エンジニアの気まぐれによって動作を変更してしまうこともできるわけです。

たとえば、VHDLのソースコードに、
HIT_OP <= '1' when (COUNT = x"FFFF") else '0';
と書かれていたら、論理合成されて動くFPGAではそのとおりにしか動けませんが、ICエミュレータでは、エンジニアが好きなタイミングでこの信号を操作することができるのです。また、FPGAが入出力する信号をすべてパソコン上でログすることもできます。

従来はこういう製品はなかったので、なかなかイメージが掴みにくいかと思います。
本ブログや展示会、ホームページなどを通じて、この新しい技術を紹介していきたいと思っています。
現在はまだ技術のコアの部分が動き出したという段階ですので、一般用製品化までにはもうしばらく時間がかかると思います。ですが、もしお客様の特定用途向けの製品として早く欲しいというご要望がございましたら、是非ともご連絡ください。当社では、多くのお客様のご要望を取り入れて、この新しい技術をどんどん進歩させていきたいと考えております。

なお、今年の9月13日に行われる展示会「6都市FPGAカンファレンス」(東京会場 田町、キャンパスイノベーションセンター)において、MITOUJTAGとともに、今回のJTAG新製品の展示と講演を行う予定ですので、ご興味のある方は是非ともお越しください。

多くの皆様のご来場とお問い合わせをお待ちしております。

| | コメント (2)

2007.08.03

FPGAが論理合成しなくても動く(4)

前回は、新製品「Advanced JTAG Function Generator」を使うと、C言語ライクに簡単なスクリプトを書けば、そのとおりにFPGAが動作するということを説明しました。

JTAGファンクションジェネレータ

今回は、スクリプトで書けることの何が嬉しいのか、ということを説明します。

この機能の応用分野は、
・迅速なプロトタイピング
・各種ICとインタフェースするための正しいシーケンスの早期確立
・アルゴリズムを再利用可能にした基板検査
・基板上の不揮発性メモリの初期設定
・各種部品の不良の検出
・テストベクタの作成
などがあります。

例えば、FPGAを中心としていろんな部品が実装された基板があったとします。その装置にはシリアルやパラレルで接続された不揮発性メモリが載っている姿を想像してみてください。そういったメモリにはブートコードや、製品のシリアル番号など、初期データを書き込まなければなりません。
開発時のデバッグや、故障検査などイレギュラーなケースがおきたとき、そのようなメモリへ読み書きする回路をいちいちFPGAで作って動作させるのは面倒ですし、迅速な対応ができません。

このようなケースでは、一刻も早くメモリにデータを書き込むための信号をFPGAから出力させたくなります。まじめにFPGAの論理回路をつくらずにC言語で簡単に書いたとおりにFPGAの端子が動いたら、どんなに喜ばしいことでしょう。

また、FPGAのデバッグ時には、「ちょっとだけ通常とは異なった信号を出力させたい」という要求が頻繁に発生するでしょう。そのようなときにも、まじめにVHDLでコードを書いて論理合成するのではなく、Cのスクリプトで書いたとおりにインタプリタで即動作すれば、非常に楽になります。

またよくあるケースでは、例えば、シリアルEEPROMなどの正しい通信シーケンスがデータシートからわかりにくい、という場合があります。FPGAの端子を操作してシリアルEEPROMを操作する場合、正しい通信シーケンスに達するまで何度も何度も論理合成を繰り返してしまいがちですが、これでは時間も労力もかかります。
こんなときは、回路を論理合成をするのではなく、インタプリタのように即時動作させれば、正解のシーケンスに到達するまでの時間は大幅に短縮できるでしょう。

もちろん、「Advanced JTAG Function Generator」のスクリプトはライブラリとして再利用することができます。不揮発性メモリへの読み書きや、SDRAM、SRAM、DRAM、汎用のLCD、ADコンバータなど、よくある操作シーケンスは、弊社からライブラリとして提供します。ピン定義ファイルの記述だけを書き換えれば、お客様のシステムにすぐに対応することができるでしょう。
もちろん、お客様が独自につくったFPGAの出力シーケンスはお客様独自のライブラリとして、他のシステムに再利用することも容易です。

これによって、迅速なプロトタイピングや、メモリの初期設定などの検査を行うことができるようになります。
また、回路の中心となるFPGAの端子を操作して周囲の部品を操作してその結果を解析する、ということはすなわちJTAGを利用した基板検査が行えるということです。

また、Advanced JTAG Function Generatorは、テストベクタを出力することもできます。
正しく部品が実装された基板でCのスクリプトを動作させることによって、FPGAの周囲のメモリやAD/DAコンバータ、各種インタフェースチップなどはそれぞれ何らかの信号を出力します。これをFPGAが取り込んで、テストベクタとして出力します。

もちろん、Advanced JTAG Function Generatorは、正常に動作している基板で採取されたベクタと、検査ターゲット用の基板で採取されたベクタを比較することもできます。つまり、基板検査ができるということです。

さらに、テストベクタの出力には、従来の基板検査ソフトウェアにあったような表形式(信号名と論理値の羅列)だけでなく、VHDLやVerilogのテストベクタとしても出力することができます。これは従来の基板検査ツール以上のメリットがあります。

つまり、FPGAの周囲の各種ICが返す波形をサンプリングして、入力と出力をひっくりかえして、VHDLやVerilogの形式のテストベクタとして出力するわけです。

なぜAdvanced JTAG Function Generatorにこんな機能をつけたかということを説明します。ほとんどの場合、ある程度の規模のFPGAの設計をする時には論理シミュレーションを行うと思いますが、周囲のICがどういう信号をFPGAに送ってくるか、というのを正確に記述するのはなかなか大変な作業です。
そんなときAdvanced JTAG Function Generatorの出力するテストベクタを使えば、実機から得られた正確な応答パターンをつかって、FPGAを設計するときのシミュレーション用テストベクタを作成するのに役立てることができます。

ところで、どうしてVHDLは難しいのでしょうか。
それはC言語などのソフトウェア用のプログラム言語は基本的に上から順番に実行していくのに対して、VHDLなどのハードウェア記述言語はすべての部分が同時に動作するからでしょう。だから、難しい。
最近ではSystem-CのようにCライクな言語でハードウェアを記述できるようになっているようですが、やはり普通のCではないので難しいものです。

ハードウェア記述言語は難しいから、ハードウェア技術者を一人養成するにはソフトウェア技術者の場合とくらべて時間もお金もかかります。ですから、普通のC言語を覚えた技術者がハードウェア開発の即戦力になることは大きなメリットだと私は考えているわけです。

まとめると、今回の新製品の機能の1つであるAdvanced JTAG Function Generatorを使うと、C言語でFPGAの動作を記述して、実機を動かし、周囲のICからの応答を調べ、それをもとにFPGAの論理シミュレーション用のテストベクタを作る、という一連の作業が簡単に行えるようになります。

次回は、今回の新製品のもう1つの機能について紹介します。

| | コメント (0)

« 2007年7月 | トップページ | 2007年9月 »