Interface誌2006年9月号にSH2(SH7144F)用JTAGエミュレータが付録しましたが、それと同じような感覚の、SH4A(SH7780)用のJTAGエミュレータを開発中です。
ようやく、メモリやレジスタの読み書き、ハードウェアブレークポイント、ステップ実行、逆アセンブル、GDBとの接続機能などが実装できました。
特殊電子回路㈱のリリースするJTAG関連ツールは「ハードウェア技術者の作業効率アップ」を目指しているので、
・ 動作のサクサク感
・ 使い始めるまでに覚えることが少なく、とにかくすぐ動かせる
というのが、すべてのツールに共通するコンセプトになります。
「マルチOSなんとか」とか、「カーネルデバッグなんとか」という、他のJTAGエミュレータにありがちな、ソフトウェア開発のための便利な機能は一切ありません。
そのかわり、ハードウェア屋さんが必要とするデバッグのためなら、どんな機能でも実装していきますよ～。
ご意見等あればお気軽にお寄せください。
ET2006の某出版のブースで、3DのグラフィックスをデモしていたあのSH-4A(SH7780)の基板が、手元にあります。
というわけで、このSH-4Aの基板をいろいろと試してみることにしました。
ところが、まず何か動かしてみようと思っても、この基板にはCPUから操作できるLEDや汎用のI/Oポートがありません。その上、SH-4AはBGAのパッケージなのでオシロで信号は見えません。
基板上に出ている信号といったら、シリアル通信の信号や、DDR SDRAMの信号。
それからPCIバスやメインボードへつながるコネクタくらいです。
しかし、SH-4Aは起動時にはROMから起動するわけなので、
DDR SDRAMの信号をみても何もわからないでしょう。
その上、プログラムを書いて走らせなければ、シリアル通信は動きません。
PCIバスも、メインボードにつながる信号も、プログラムを書かなければ動きません。
プログラムを書かずにすぐに見えるものといったら、ROMのアドレスバスとデータバスを見るくらいしかありません。
ですが、オシロやロジアナを全信号につないでみるわけにもいきません。
こういう場合、MITOUJTAGの、JTAGロジックアナライザと、フラッシュROMライタ機能とを使えば、基板のハードウェアの動作をすぐに確認することができます。
まず最初に、CPUボードとパソコンをJTAGケーブルでつなぎ、MITOUJTAGを起動します。
フラッシュROMライタを起動し、ROMを全部消去した状態(すべてFF)で、CPUにリセットを行います。
CPUを走らせ、そのアドレスバスやデータバスの動作を、JTAGロジックアナライザで観察してみます。
すると、
このように、SH-4Aのアドレスカウンタがカウントアップしていくのが見えます。
SH-4Aにとって、消去されたROMの値「FFFF」というのは有効な命令ではないのでしょうが、それでも何らかの命令だと思って解釈して、ひたすらアドレスカウンタをアップさせながら動いているのでしょう。
基板上のDIPスイッチで、クロックの速度を変えられるようなので、クロック速度を遅くしてみると、
このように、カウントアップが遅くなります。
CPUは生きていて、ちゃんと動いていそうだということが、おぼろげながらわかります。
次に、もう少し、ちゃんとしたプログラムを走らせてみることにしましょう。
まずは、SLEEP命令。
SH-4Aにとっては、001BというのがSLEEP命令です。
この基板では、CPUの動作状態がビッグエンディアンかリトルエンディアンかよくわからなかったので、
"001B 1B00"
という2ワードを、ROMに書いてみます。
ROMに書き込むには、CPUのアドレスバスや、データバス、RD、WR、CS信号などを操作できればよいわけです。MITOUJTAGにはバウンダリスキャンを利用したフラッシュROMライタがあるので、CPUとROMがつながってさえいれば、どんなROMにでも書き込むことができます。
すると、
みごとにアドレスバスの動きが止まりました。
消費電流も3分の1くらいに減ったので、きっと見事にSLEEPしたのでしょう。
命令はアドレス0000か、少なくともアドレス0002に置かれているはずですが、物理アドレスは0001Eを指して停止しています。SH-4Aのパイプラインとかキャッシュとかの仕組みによって、ある程度先の命令までまとめて一気に読むようになっているのでしょうか。
では、もうちょっとプログラムらしきものを書いてみます。
まず、NOP命令。この機械語コードが0009ということは、分かっています。
これを100個ほど並べます。そして、BRA命令で最初のアドレスに戻るようにします。
つまり、
「NOP NOP NOP NOP NOP NOP ・・・ NOP NOP NOP NOP NOP NOP NOP NOP BRA NOP 」
というだけのプログラムを作ります。
※ 注意 BRAの後にもNOPを置かないと、遅延スロットとかの問題でちゃんと動作しないようです。
全部で224バイトくらいになりました。
これをROMに書き込んで、リセットすると、
アドレスA1～A7までが激しく動いています。
A0が動かないのは、ROMが16ビット幅だからです。
この波形からわかることは、プログラムというか、CPUが読み出す領域は256バイト以内に収まっている、ということです。
もうちょっとNOP命令の数を増やして、読み出される領域が256バイトを超えるようにしてみます。
すると、
このように、アドレスA8まで動くようになりました。
こんな単純なプログラムですが、SH4Aは、ちゃんとROMから命令を読み出してそのとおりに実行してくれているのだろう、ということがなんとなく分かります。
最後に、他のSH-4ボード(SH7750)用に作られたredbootを書き込んでみます。
redbootというのは、簡単に言えばLinuxなどを起動させるための最初のローダです。
さすがにCPUの型番が違うので、Redbootとしては動作しませんでした。
ですが、バスの波形を見ると、何かをしようとしている様子が見えます。
アドレスA1～A5が激しく動き、A13～A25は5％くらいの頻度で一斉かつ規則的に動いています。
この動きは、どこかの番地に書かれたメモリやレジスタでも参照しようとしているのだけれども、何もないからループしてしまっているか、もしくは特権命令違反か何かでどこかの番地に嵌ってしまっているのだけれど、抜け出すこともできない、という感じでしょうか。
詳しい動作状態はわかりませんが、何かのプログラムが動いているのは確かです。
もし、基板を設計したハードウェア屋さんなら、この動作が見えるだけでもかなり安心できるでしょう。
場合によっては、ハード屋さんの仕事はここで完成といってもいいでしょう。
ハードが動いているのがわかったので、あとはソフトウェアの問題です。
ところが、普通のやり方でCPUの動作を確認しようとすると、まずはLEDをチカチカさせたりシリアル通信に文字を出したりということになりますが、この最初のステップはとても高いハードルです。
なぜなら、アセンブラを覚えたり、内部のレジスタ構造やアーキテクチャを覚えることになり、マニュアルの読みこなしや、コンパイラの使い方を覚えなければならず、特にSH-4AのようにハイエンドなRISC CPUでは大変な労力を要します。
普通は、基板が最初に動いているのを確認するのは回路を設計したハード屋さんの仕事なので、ハード屋さんはこういったソフトの世界をも、かなり深く勉強しなければなりませんでした。
たとえLEDチカチカであっても、CPUがプログラムを読んで実行するためには、ROMやクロック、モード設定(エンディアンやROMの幅など)が正しく設定されていなければなりません。つまり、ハードが完璧でないと、LEDチカチカすら動かせないわけです。
シリアル通信の実験などでは、RS232CドライバICや、クロスケーブルとストレートケーブルの違い、RTS・CTSなどをつながない、などの理由で、本当はCPUは動いているのにパソコンに文字を送れないことだって起こりえます。
こういう理由で、いままでは未知のハードが動いているかどうかを確認するのは、至難の業でしたが、MITOUJTAGのJTAGロジックアナライザを使うと、以上の例で示したように「基板のハードが動作しているか否か」までは、あらゆるCPUですぐに確認することができます。
アセンブラ命令も、NOP命令と、SLEEP命令、BRA命令くらいだけ知っていれば、アドレスバスの動きからCPUの動作を観察することができます。
明日は、某出版の○○さんが、某SH-4Aの基板のことで、急遽事務所にいらっしゃることになりました。
というわけで、SH-4A用のJTAG ICE(エミュレータ)の開発にも本腰をいれていくことにします。
対応デバイス強化月間ということで、DigikeyでXILINXのXCF16Pと32Pを買いました。
フラットパッケージなのでピッチ変換基板を使わなければならないのですが、サンハヤトのSSP-53を使うことにしました。
ところが、この変換基板は製品Webページを見ても、詳しい寸法がわかりません。
結局、実際に買ってみて照らし合わせてみるしかなさそうです。
買って試してみると基板の方が短く、みごとに実装できませんでした。
XCF08P～32Pはチップに印刷されたシルクの文字が妙なフォントです。
さて、XCF32Pの方は、発注ミスをしてしまいBGAパッケージのものが届いてしまいました。
１個3200円ですから、捨てるのは惜しいです。
0.8mmピッチと狭いのですが、ピン数がそれほど多くはないので、いずれ空中配線によるBGAの実装にチャレンジしてみたいと思います。
MITOUJTAGの現バージョンは、
・XILINXのXCF08Pは書き込めるが、XCF16P、XCF32Pは未対応。
・XILINXのCoolRunner/CoolRunnIIは書き込み未対応。
・ALTERAのFPGAではCycloneのみ書き込み可能。他のFPGAは未対応。
・ALTERAのMAX IIでは、EPM240のみ書き込み可能。MAX IIの他の品種は未対応。
・ALTERAのコンフィグROMはすべて書き込み未対応。
と、なっています。
いずれのデバイスも、SVFファイルを経由すればMITOUJTAGから書き込みができるのですが、それでやはり面倒です。
というわけで、MITOUJTAGの対応デバイスを増やそうと思います。
また、FPGAの中がみえる埋め込み式ロジアナ機能、「BLOGANA」も、サンプリング長やビット幅を自由に変えられるようにしたり、Spartan2やVirtex4にも対応したバージョンをどんどんリリースしていこうと考えています。
というわけで、これから１ヶ月ほどかけて対応デバイスを強化していきたいと思います。
どうぞ皆様ご期待ください。
2日目の展示が終わり、家に帰ってからは3日目に向けての準備です。
家庭に仕事を持ち込んでいます。
出展2日目には、3回のプレゼンがあって力尽きていたのでその夜は徹夜をせず、17日の朝5時に起きて準備をすることにしました。
3日目の大きなイベントは、ルネサスさんでのプレゼンです。
プレゼン資料をいくつか手直しし、また、プレゼン中に簡単なデモを行えるよう、予行練習を行います。
デモは、「実機(SH-4でLinuxが動くボード)をつないで、バウンダリスキャンを使って動いているところを見せる」というものなので、現地で一発で成功するように事前準備が必要です。どうしても実機を持ってデモをしようとすると、コネクタが接触不良したり、PCがスタンバイモードから復帰したときにUSBが認識されなくなっていたり、というトラブルが最悪のタイミングで発生するものです。
今回はそんなことのないように、事前準備をばっちり行いました。
また、配布するプレゼン資料を35枚ほど作りました。
3日目の朝、総武快速線と東海道線が激しく遅れていました。
この日はグリーン車に乗って、車内でプレゼンのイメージトレーニングです。
この日、IPAさんでのプレゼンは1回だけだったのですが、なんと80名の方にお越しいただけました。
ルネサスさんでの発表は何人いらっしゃったのかわかりませんでしたが(85名だそうです)、準備しておいた配布資料はすぐになくなってしまっていました。実機デモをしようとしていたのですが、講演の2分くらい前になって、実機がJTAGでつながらないことが判明。コネクタをセロテープで止めていたのがいけなかったようです。B-03ブースから移動してくる間に接触不良してしまったようです。セロテープで固められた中でケーブルが接触不良しているようだったので、テープを剥がしTCKとかTDIとかの線をつなぎなおし、何とか動くように直前に復旧しました。これには焦りました。
プレゼンは問題なく、実機デモも含めて成功。
その後、弊社ブースに多くのお客様がいらっしゃって、いろいろとお話しました。
この展示会では、いろいろな方に出会いました。ネット上や書籍・雑誌記事などで名前を聞いただけだった方にも大勢お会いすることができ、大変有意義でした。
3日間あわせてIPAさんだけで220名ほど。ルネサスさんとCQさんの発表をあわせると、合計360名以上の方に発表をお聞きしていただけたのではないかと思います。
JTAGを使ったこのようなデバッグ方法があるのだ、ということを組み込み業界に広く伝えることが出来たのではないかと思います。
来年は、さらに多くの方に、弊社が提唱するこの新しいJTAGデバッグ方法を知っていただきたいので、自社ブースを出展しようかと考えています。
また、今回、展示がうまくいった背景には、アルバイトの人の協力によるところも大きかったです。
弊社ブースならびに、講演にご来場いただいた皆様、本当にありがとうございました。
おかげさまで、大盛況でした。
１日目が終わると、２日目に向けて準備開始です。
２日目は、CQ出版さんの中での講演があります。パワーポイントの資料を作らなければなりません。夜の12時ごろまで、資料を作り、あとは写真を何枚か貼り付けるだけ、という形にまでできあがりました。
BLANCAをFFTやスペアナとしての動作させることは出来ていたのですが、画面に「周波数」やら「時間軸」や、「デシベル」を表示する、いわゆる文字表示機能が全くできていませんでした。
というわけで夜中の12時ごろから作業開始し、深夜の4時ごろに、ようやく文字表示機能が出来上がりました。
文字を16×16ドットサイズの「漢字かな混じり」にするか8×8ドットサイズの「英数のみ」にするか迷いましたが、画面サイズがVGAなので、漢字なら40文字×30行、英数のみなら80文字×60行となります。
40×30だと画面全体で1200文字なので、XILINX FPGAのBlockRAM1個に収まります。
しかし、80×60だと4800文字になるので、BlockRAMの使用量が4個になります。
そういうわけで、画面表示は漢字かな混じりの16×16ドットにしました。
画面表示のしくみは簡単で、40×30のキャラクタROMから、その位置に表示されるべき文字を調べ、別途用意したフォントROMを参照し、表示するだけです。BlockRAMにはフォントは全部で64文字入りますが、実際には33文字しか使いませんでした。
で、4時ごろ出来上がったBlanca-FFTの画面は、こんな感じです。
これが、CPUなどを一切使わずに、FPGAの中のロジック(カウンタとかメモリとか加算器・乗算器など)だけで作ったフーリエ変換マシンです。周囲の音声をマイクで拾ってサンプリングし、即座にFFTして画面に表示します。
ほとんど完成に近い形なのですが、まだ「窓関数」の機能をつけていませんでしたが、もう遅いので寝ることにします。
2日目の朝、横浜に向かう東海道線の中で、BLANCA-FFTの開発を続けます。
窓関数を実現するのは比較的簡単で、電車の中で書き上げることができました。会場についたら展示用PCで、展示しながら裏で論理合成をします。ちゃんとハニング窓の窓関数が効いて、表示されるスペクトラムの分解能が上がったようです。
ディジタルフィルタまで入れてしまおうと思いましたが、さすがに時間切れです。
2日目は講演が全部で3回あります。IPAさんで2回。CQさんで1回です。
IPAさんの発表は、合わせて120名(アンケート枚数)ほどお越しいただきました。昨日の2倍です。
CQさんのブースでの講演もとても多くの方に起こしいただいたようです。ありがとうございました。
その後の質問で本当に11日で作ったのか、と聞かれました。そうです。厳密には今日の朝の電車の中を入れれば12日です。
この日、marseeさんとお会いしました。お話したその機能もぜひ作っていこうと思います。
今年は、ET2006に出展者として出展しました。
1日目の開始前、どんな展示会になるだろうと期待に胸をおどらせながら、セットアップのため、会場には30分ほど前に到着しました。
9時半ごろ、電話がきました。(事務所の電話は携帯に転送しているので、移動中でも受け取れます)
「私、アイ●ックスと申しまして、千代田区の会社と長い間おつきあいさせていただきていて、・・どうたらこうたら」このように無意味な挨拶が延々と続くのはたいてい、先物関係です。
「おたくは、先物の会社でしょ？」
「はいそうです」
先に正体を見抜いて、言ってやると、調子を崩されるらしいです。
「私は先物はやらんのですよ」
このように、はっきり言えば、普通は引き下がるのですが
「リスクが大きいとお考えなのですか？」
しぶとい！
「やらないといったら、やりません。もうかけてこないで下さい」
と、切ります。
・・・
幸先の悪いスタートでしたが、展示は大盛況！
きっと、運の悪い出来事はすべて先ほどの先物業者がぜんぶ引き取ってくれたのでしょう。
10時すぎから、早速お客さんがいらっしゃいました。
今まで出展してきた展示会はどれも組込み開発とはちょっと分野のことなる展示会だったのですが、今回は、MITOUJTAGが展示会の来場者層にベストマッチ。初めて見られた方は驚いていかれたようです。
会場はネットがつかえるようになっていたのですが、会社にVPNで接続しようとしても何故かつながりません。また、FPGAデータの入ったメモリスティックや、雑多な情報の入ったノートPCを忘れてきてしまったので、その場にあったデータだけで何とかやりくりします。
１日目は、IPAブース内で、２回の講演がありました。今回は、パワーポイントの資料を作るのに、デザインやレイアウトや色使いの基礎などについて、我流ではなく本を読んで勉強して臨みました。
IPAブースでの２回の講演には、(集計されたアンケート枚数によると)合わせて60人ほど起こしいただけました。
お昼頃、アルバイトの人に自分のブースを任せて、いろいろと挨拶回りに出かけました。
まずアヴネットのブースに行き、まさちくさんにご挨拶。
それから、TIのブースに行き、PCI Expressのカメラが動いているのを確認。
ほか、いろいろと回ります。
創業数年ですが、いろいろなところに知り合いができたようです。
また、ルネサスさんから綺麗な「パートナー・フラワー」をいただきました。
有難うございます。おかげさまでブースが彩り華やかになりました。
いよいよ明日からET2006がはじまります。
今日は会場のセットアップのため、パシフィコ横浜に行ってきました。
IPAの中にある自社のブースは狭かったです。
余りの狭さに愕然として、来年からは自社の専用ブースを１小間出そうと決意しました。
（でも１小間取ると結構高いんですよね・・。やはり共同出展か・・）
隣はForCyで有名な(有)リカージョンさんのブースです。
パンフレットを何枚用意したかという話になって、
1000枚とか1500枚とかいう話を聞いて、私は焦りました。
頑張れば１日で300枚は配れるそうです。
いままでの展示会では、３日間運営してもせいぜい300枚がいいところでした。
ですから、とても1500枚なんて数は用意していません。
印刷を業者に頼むと、500枚でも5000枚でもたいして値段は変わらないから
多めに頼んでしまえばいいのですが、重いし、保管する場所も食いますし、
パンフレットをバージョンアップしたりする際に廃棄するコストが増加するので、
うちはいままで最低限度の枚数しか作ってきませんでした。
ETは組込み筋のお客様が多いから、パンフレットがたくさん必要になるだろうということで、
急遽、パンフレットを500枚追加で発注することにしました。
運がよければ金曜日の午前中に展示会場に直接届くことになります。
（前にもこういう荒業をやったなあ
そのときは、印刷業者さんが間違えてパネル用ポスター（B1サイズ）を
全く別の会社に配達してしまい、それで会場送り技を使った）
液晶が割れていないことやPCが起動することを確認し、セットアップは終了。
ルネサスさんとCQさん、TIさんのブースに挨拶にいき、会場を後にしました。
帰ってきてからはMITOUJTAG体験版のCD-ROMを作る作業に追われています。
ようやく50枚を焼き終えました。
明日は朝早いのですが、
「BLANCAでFFT」のさらなる改良や、プレゼン原稿づくり、
SH4/4Aマイコンの動作確認などやることがたくさんあり、
まだまだ休むわけにはいきません。
昨日、BLANCAで作ったハードウェア・フーリエ変換機では、FFTの演算をした後、その結果を画面に表示するために、パワースペクトラムの計算をおこなっています。
その計算は、すなわち、log10 √(x2+y2)の計算を行うわけですが、これをハードウェアで計算しなければなりません。
そこで、次のように回路を工夫しました。
まずx2+y2の計算です。xとyというのはある周波数での実部と虚部ですが、これはSpartan3のハードウェア乗算器を使って計算しているので、簡単に実装できます。
平方根をハードウェアで計算するのは難しいのですが、log10 √P、という演算であればそれほど難しくはありません。対数の性質により、平行根の部分をlogの外に出すことができるからです。つまり、
log10 √P = 1/2 log10 P
だからです。
よって、この計算の中心は、logを求めることになります。
さて、ハードウェアでlogを求めるにはどうしたらよいでしょう。
二乗の和の平方根を取るような場合、元の数が16ビットなら32ビットくらいの精度で数字を扱わなければなりません。したがって、32bitの入力のlogの表を全部をテーブルに入れてしまうのは得策ではありません。
また、テーラー展開やニュートン法は大変なので採用したくありません。
そこで、私は次のように考えました。
我々が普段使っている常用対数というのは、10進数で考えた場合の(桁数-1)を表しているものです。
例えば、log10 10 = 1、log10 100 = 2、log10 1000000=6です。
1と0が並ぶ数でない場合は端数が出ます。
例えば、
それと同じように、2進数で考えた場合は、対数は2進数の桁数として計算することができます。
例えば、log2 10 = 1、log2 100 = 2、log2 1000000=6です。
左端以外のビットに1がつく場合は端数が出ます。
というわけで、2進数で対数を計算するには、その数字の桁数を数えればよいことになります。
つまり、
00010010101010010100101011100101
という32ビットの数字があった場合、左から数えて最初に'1'が出るビットの位置が対数をとった時の整数部となります。
上の例では、bit28がはじめに'1'になっているので、
log200010010101010010100101011100101 = 28.何とか
という数になります。
(左端をbit31、右端をbit0として数える)
では、「何とか」と書いた小数部はどうやって求めるかというと、その最初に'1'になったビットの右側の何ビットかを使って求めます。
つまり、8ビットの精度で
00010010101010010100101011100101
の部分と、最初に'1'になったビットを使って
1.00101010という固定小数点の数字に見立てて、対数を求めることになります。
これは10進数で言って1～2の間に必ず収まる数ですから、テーブルを使うことができます。
式で考えると、Pという数の対数を取りたい場合、
(ただし、Nは整数、1≦M<2とする)
とし、
このlogMは次のようなグラフになります。
直線で近似してしまってもいいかもしれないくらいな関数です。
つまるところ、2進数での桁数と、最初に出た'1'に続く数ビットの対数を取れば十分な精度で求められることがわかります。
今回のスペアナでは、画面のサイズが640×480ですから、対数を取った後の数字は8ビットあれば十分です。
32ビットの2進数の対数を取るわけなので、桁数で5ビットの精度があります。
よって、端数のlog2Mの部分は3ビットあれば十分ということになります。
BLANCAに実装したハードウェア・フーリエ変換器では、次のような回路を使って、3クロックでlog10 √(x2+y2)を求めることができました。
二乗の和の部分に2クロック、平方根と対数演算の部分で1クロックです。
タイミングレポートによれば、これが70MHzくらいの速さで動きます。
バレルシフタの後にもう一つフリップフロップをいれてやれば、100MHzは簡単に超えられるでしょうが、1クロックでの対数計算にこだわったので、こうなりました。
また、精度を上げたければ、対数表の部分をより精密にすることで容易に実現できます。
今回は5ビット入力3ビット出力の対数表にしたので、直接when～else文で記述してしまいましたが、Spartan3のブロックRAMに対数表をいれておけば、11ビット入力9ビット出力の対数表が作れます。整数部(桁数)は5ビットで出てくるので、最大14ビットの精度で対数が計算できるはずです。
このアルゴリズムが常識かどうかは調べていないのでわかりませんが、こんな簡単な回路で実用上十分な計算ができるのを確認できました。
ようやく、BLANCAで作ったハードウェア・フーリエ変換機が動き出しました。
(これでやっとET2006に出られます。)
512ポイント、16bitのフーリエ変換を1.1ミリ秒で行うことができます。
今はFPGAのクロックを25MHzで動かしていますが、ツールのレポートによると100MHzでも動くようですので、クロックを上げればこの4倍くらいの速さになると思います。
MicroBlazeなどのソフトコアCPUを一切使わず、ハードウェアだけで作ったので、かなり小さな回路にすることができました。
XC3S1500の、どのくらいのリソースを使ったか、レポートを抜粋してみると、
Number of Slice Flip Flops: 638 out of 26,624 2%
Number of 4 input LUTs: 1,037 out of 26,624 3%
Logic Distribution:
Number of occupied Slices: 700 out of 13,312 5%
Total Number 4 input LUTs: 1,228 out of 26,624 4%
Number of Block RAMs: 9 out of 32 28%
Number of MULT18X18s: 3 out of 32 9%
Number of GCLKs: 3 out of 8 37%
Number of BSCANs: 1 out of 1 100%
だいたい5%くらいしか使っていません。
これならXC3S100にも十分入ります。
フーリエ変換スペアナの機能としては完成しました。
あとは、計測器として使えるように、画面に文字(周波数や時刻、dBの表示など)をいれたり、窓関数処理をしたり、画面の見栄えをよくしたり、といった楽しい作業ばかりが残っています。
BLANCAは、FPGAを起動させるために、XILINXのコンフィギュレーションROMを使っていません。
コンフィグROMを使わずに、汎用のフラッシュROMにコンフィギュレーション用のデータを書いておいて、電源投入時に、基板上のCPLDがROMから読み出してFPGAに送って起動する、という仕組みになっているようです。
したがって、電源ONでFPGAをROMから起動させるには、
1. CPLDに「FPGA起動用回路」を書き込んでおく
2. フラッシュROMにFPGAのデータを書いておく
という準備をしたあとで、BLANCAの電源を入れるということになるのだと思います。
で、どうやってフラッシュROMにFPGA用のデータを書き込んでおくかというのが気になりますが、マニュアルやソースファイルを読んだ限りでは、基板に２つあるFPGAのうち大きいほうのFPGA(XC3S1500)を通じてUSB経由で書き込むようです。CD-ROMにはそのためのサンプルアプリが同梱されています。
出荷時の状態ですでにROMやCPLDにはサンプルアプリが書き込まれているのですが、全く空の状態から書き込みたいというときには、まず電源ONした後に、CPLDとFPGAに必要なファイルをJTAG経由で書き込み、USBを通じてFPGA用のBITファイルを送りこむ、ということになるのでしょう。
ちょっとややこしいので、ここではMITOUJTAGを使ったBLANCAの起動方法をいくつか考えてみました。
このサンプルアプリは、MicroBlazeなどのソフトコアのCPUが動いている複雑なものなので、FPGAのハードだけで動く回路をちょこっと作って試すには、全部空にしてしまいたくなります。
したがって、まず、電源ONでデフォルトのアプリが起動しないようにしたいわけです。
それには、CPLDを消去するのが、最も手っ取り早そうです。
MITOUJTAGを起動して自動認識ボタンを押すと、３つのデバイスが認識されます。
いちばん左側のデバイスがCPLDですので、これをクリックして、MITOUJTAGのツールバーの「消去」ボタンを押します。これで、CPLDが消去され、電源ONでFPGAが起動しなくなります。
再度、電源をいれなおし、バウンダリスキャンをおこなってみます。
すると、FPGAの全端子が入力(HI-Z)状態(網掛けの状態)になっているのがわかり、また、FPGAのDONEピンがLowの状態になっていることがわかります。
つまり、FPGAが起動していないことがわかります。
このように、MITOUJTAGでは、FPGAが起動する前でもそのデバッグ機能を使うことができます。これは、他のFPGAデバッグツールでは真似できない特徴です。
真中のデバイス(XC3S1500)をクリックして、ツールバーの「書きこみ」ボタンを押し、FFT用のBITファイルを選択します。使用するケーブルにもよりますが、およそ２～３秒で書き込みが成功し、FPGAが起動します。BLANCAはスレーブパラレルモードになっていますが、JTAGを使ってもFPGAに書き込みができるようです。
FPGAが起動した状態でバウンダリスキャンを行うと、下の図のように、それぞれのI/O端子が出力や入力に変わり、一見してにぎやかな感じに変わります。また、DONEピンもHighに変わったことがわかるので、コンフィグに成功したことは一目瞭然です。一番右のFPGA(XC3S400)には何も書き込んでいないので、起動していません。このFPGAの端子状態は全部入力(HI-Z)のままです。
ROMから起動するには、フラッシュROMにFPGA用のデータを書き込みます。
MITOUJTAGには、バウンダリスキャンを利用したフラッシュROMライタが内蔵されているので、これを使って書き込んでみましょう。
フラッシュROMライタ機能を使うには、まず、フラッシュROMの各端子(アドレスやデータ、CEなど)がFPGAやCPLDのどの端子につながっているかを、MITOUJTAGに登録する必要があります。
その接続情報は、回路図とCPLDのUCFファイルを読んで解釈し、自分で一つづつ入力します。
この入力は10分くらいで終わるでしょう。入力した接続情報はファイルに保存しておきます。
→ 「blanca.jfc」をダウンロード
回路図によると、フラッシュROMはAm29DL640Gという品種で16ビット幅のROMです。
ですが、CPLDとの間は8ビットでつながっているので、ROMを8ビットモードで動かさなければなりません。そのためには、ROMのnBYTEという端子をLに固定するとともに、[D15/A-1]という変なアドレス入力を使う必要があります。
また、フラッシュROMのアドレスやデータなどはCPLDにつながっているのですが、ROMのnBYTE端子、nWRP端子、リセット端子はCPLDにつながっていません。nWRPは単なるプルアップ、リセットはシステムのリセットなのでそのままでも問題ありませんが、nBYTE端子はちゃんとLowになるようにしなければなりません。
nBYTE端子はIDT QS3257QというICにつながっています。このICはおそらくバススイッチで、セレクタ代わりに使っているのだと思われます。
このICのCFG_nBYTEという信号をLにしてやれば、ROMのnBYTE端子はLowになりそうです。幸いCFG_nBYTEはCPLDにつながっているので、CPLDを適切に制御してやればフラッシュROMの全端子を操作することができて、CPLDからフラッシュROMにアクセスできるはずです。
というわけで、「フラッシュにアクセスするときにはCFG_nBYTEをLowにするように」と、MITOUJTAGに指示します。こうしてフラッシュROMライタを起動し、「調査」ボタンを押すと、下の図のようにちゃんとフラッシュROMのIDコードが読み出せるのが確認できました。
また、０番地からフラッシュメモリをダンプしてみると、なにやらB6 00 ・・などというデータがたくさんでてきます。きっと、CPUのプログラムではないかと思われます。
BLANCAのマニュアルには、フラッシュROMの後ろのほうの1Mバイトにそのデータが書き込まれている、と書かれています。フラッシュROMは8Mバイトなので、0x700000番地からダンプしてみると、「3s1500」などというデータが見え、その後におなじみの「FFFFFFFFAA995566」という、FPGAのコンフィギュレーションデータが見えました。
このデータを消去してしまえば、たとえCPLDが動いても、FPGAは起動しなくなります。
また、このデータのかわりに自分が設計したFPGAのBITファイルを書き込めば、そのファイルでBLANCAが起動するようになるでしょう。
そこで、まず、MITOUJTAGのフラッシュROMライタのセクタ消去機能をつかって、0x700000番地以降をを消してしまいましょう。0番地などにあったCPUのプログラムは今後のことを考えて残しておきます。
書き込みには少し時間がかかります。XC95288XL、XC3S1500、XC3S400のすべてがバウンダリスキャンチェインにつながっていると遅くなりますので、FPGAのBSDLを割り当てないようにします。
MITOUJTAGのデバイスの選択画面で、「BSDLを使用しない」と表示されるデバイスを選択すればOKです。下の図のようにFPGAだけ灰色で表示されます。
これで、XC95288XLだけを操作することでフラッシュROMに書き込めるようになり、書き込み時間が大幅に短縮できます。
また、先ほど消去したCPLDのデータを復活させます。CPLDの絵をクリックして「書き込み」ボタンを押し、BLANCAのCD-ROM中の"normal.jed"を書き込みます。
次の図は、書き込み中の画面です。
フラッシュROMのセクタ構成(水色)の上に、ファイルサイズ(黄色)と、書き込みエリア(赤)、そしてどこまで書き込んだか(緑)が図示されます。この画面でしばらく放っておけば、そのうち書き込みが完了しています。
なお、フラッシュROMと、CPLDとはどちらを先に書き込んでも構いません。
なぜなら、MITOUJTAGはバウンダリスキャンを使っているので、フラッシュROMの書き込み時にはCPLDの中の回路は動いていないからです。
つまり、CPLDやFPGAなど、すべてのデバイスが正しく動作していなくても、CPLDとROMがつながってさえすれば、書き込みができます。CPUの場合も同様です。クロックが怪しくてICEすら起動しなくても、バウンダリスキャンならなんとかなるでしょう。
MITOUJTAGのフラッシュROMライタは「つながってさえいれば」、CPLDでも、CPUでもFPGAでもなんでも使えてしまいます。この万能さは、各社から発売されているCPU用JTAG ICEやFPGA用デバッグツールにはない特徴のひとつです。
これで、BLANCAのCPLDは電源ON時に、新しいBITファイルをFPGAに流し込み、新しいデザインで起動するようになりました。
バウンダリスキャンでフラッシュROMに書き込むのは時間がかかります。デフォルトのサンプルアプリを使うのでなければ、開発時にはCPLDを消去しておき、JTAGでFPGAに直接ダウンロードするのがよいと思います。
今年もこの季節がやってまいりました！
特殊電子回路㈱は、ET2006に出展します！
会期 11月15日(水)～17日(金)
会場 パシフィコ横浜 （横浜駅からみなとみらい線で３分）
場所 展示会場 B-03ブース
B-03ブースは独立行政法人情報処理推進機構、いわゆるIPAのブースです。未踏ソフトウェアやその他、過去にIPAが支援したプロジェクトの成果など中から組込み関係の人が出展しているようです。
http://www.pp-web.net/ET2006/list.cgi?mode=enter#さ
特電の展示内容は、現在開発中のMITOUJTAGの最新バージョン(MITOUJTAG BASIC Version 1.2.5)による電子回路デバッグの実演を予定しています。
また、３箇所で計８回ほどの講演が予定されています。(汗)
そして、MITOUJTAGの次のバージョン1.2.5に準拠した体験版の無償配布も予定しています。
(前回の展示会で配布していたものよりも新しいバージョンです。)
昨今のMITOUJTAGは、かつて配布していた無償評価版0.3.1と比べると、比べ物にならないほど機能アップしています。あまりにも高機能化しているので、どのように変わったかを文章で書いて表現することが難しく、最新のMITOUJTAGをできるだけ多くの方に体験していただくためには、お客様に実際にご利用いただいたほうが分かりやすいと思い、会場にお越しいただいた皆様に最新の体験版を無償で配布することにしました。
前回と前前回の展示会、「インターネプコン2006」、「IPAX2006」では多くの方に体験版をお渡しすることができましたが、さらに多くの方にMITOUJTAGを体験していただきたいと思い、再び体験版を配布することにしました。
体験版は、ご希望の方に無償でお配りいたします。(お名刺をご持参ください)
また、限定50枚と、ご用意する数が多くはないので、予約も承っております。
展示内容と予約方法の詳細は下記のURLをご覧下さい。
「展示会 ET2006出展のご案内」
http://www.nahitech.com/event.html
多くの方のご来場をお待ちしております。
皆様、ぜひともご来場ください。
特殊電子回路㈱のページをリニューアルしました。
http://www.nahitech.com/
MITOUJTAGのページも一緒にリニューアルしました。
http://www.nahitech.com/jtag/
Webデザイン関係の本を3冊ほど読んで勉強した甲斐あって、
現代風のページを作ることができました。
新しくなった特殊電子回路のWebサイトをよろしくお願いします。
さて、AC97まわりのデバッグも佳境に入ってきました。
前回の問題を整理すると、
① のこぎり波をサンプリングすると、真中あたりで不連続となる
② 無信号時の状態でAD変換した値が、とつぜん、大きな値となる
③ 音声を入力してみると、波形がグラフの上下にはりついてしまって、正しくならない
ということが挙げられます。
そこで、まず、前回の波形をみてみます。
よくみると、ADC_OUT(19)が常に'0'のままです。
WM9711のデータシートをよくみてみると、AD変換器は18ビットと書いてあります。
AC97は１つのフレームを20ビットで送るので、おそらくbit19とbit0を使わないのでしょう。
真中の18個を取るのが正解のようでした。
また、出てきた値は、２の補数表現だったようです。
FPGAの中を書き換えて、２の補数表現で数値を扱うようにし、また、ADCの値はフレームの真中の18ビットだけを使うようにしたところ、①と③の問題が解決できました。
その結果、波形は
このように、ちゃんとのこぎり波らしくなりました。
次はライン入力を実験します。
WM9711の内部レジスタ設定を変更して、「オーディオ出力→オーディオ入力」のループバックのパスを切り、オーディオ入力をライン入力につなぎます。
BLANCAのライン入力に何もつながなければ無音状態のはずなのですが、下の図のように、なにやら下向きのパルスが規則的に出ています。
おそらく、AC97から出力している「のこぎり波」の、微分成分がノイズとしてライン入力にのってしまっているのでしょう。WM9711の感度は凄いというか、WM9711でのこぎり波のような鋭い波形は出力しないほうがいいのかもしれません。
とりあえず、のこぎり波を出力するのはやめておきましょう。
問題点の②は、オーディオ入力からのこぎり波を出力していたために、それが回り込んできてADCがたまにマイナスの値を出力してしまい、それが原因でbit18などの大きなビットが動いた、というのが真相です。
次に、BLANCAのライン入力用のコネクタに、市販のパソコン用マイクを直接つないでみました。
ライン入力はライン入力であって、マイクを直接つなぐものではありません。ですが、WM9711のレジスタを設定して、AD変換の前の内蔵プリアンプで30dBの増幅を行っておけば何とかなるようです。
マイクに向かって何か喋ると、このように画面に波形が表示されます。
この画面の横の目盛は時間を表していて、１目盛が0.666ミリ秒です。
画面上には横１６目盛分の波形が表示されるので、画面いっぱいで約10ミリ秒間の波形が表示されることになります。
口笛を吹くと、結構綺麗な正弦波が表示されます。
というわけで、音声帯域のシンプルなオシロが出来ました。
ハードウェアで何かをやるというのはとても楽しいですね。
BLANCAのアプリケーションを開発しています。
いま作っているアプリケーションにおける、AC97オーディオ入力まわりの問題点をまとめておきます。
AC97のチップ「WM9711」は、オーディオ出力や入力ができます。
これらは48kHzという周波数で行われます。
ADコンバータの入力を「ライン入力」に設定し、変換されて出てきた値を、JTAGロジアナで観察してみると、
図が縮小されてしまってみづらいのですが、0x000C4、0x0026A、0x0013C、0x001AEという値が出力されているのがわかります。
本当はもっと長時間サンプリングして見たいのですが、現在のJTAGロジックアナライザのBLOGANAモードでは、最大で1024ポイントまでしかデータを取ることができないません。
そこで、このAD変換された値をFPGAのI/O端子に出力して、通常モードのJTAGロジックアナライザで観ることにします。通常モードでは１分や２分というオーダーで、FPGAの全I/O端子の波形を観ることができるからです。
ところが、FPGAの外に波形を出力させてみると、
いままで0x00000からせいぜい0x003ffくらいまでの範囲でしか動いていなかったのに、FPGAの外に信号を取り出して長時間サンプリングしてみると、大きなビットを使う値が出力されるようになりました。
ノイズでしょうか。
再びJTAGロジックアナライザでキャプチャしてみると、何度か試してみると、稀ですが確かに大きな値が出力されることがあることが確認されました。
ノイズか、それともAC97チップの使い方が間違えていたのでしょうか。
想像してみてください。 オシロや、物理的なプローブをつなぐロジアナで、同じバグを発見するのがどれだけ大変な手間がかかるか。 もし、このような現象をオシロだけでみつけるとなると、それはとても困難でしょう。 たとえ32chなどというロジアナを使ったとしても、FPGAはBGAパッケージですから、プローブをあてようがありません。 MITOUJTAGのように、JTAGバウンダリスキャンを使えばこういうバグを迅速に発見することができます。
さて、今、AC97チップの出力には、８ビットカウンタを直結していて、256周期（＝48kHz/256≒187Hz）ののこごり波を出力するようにしています。
／|／|／|／|／|／|／|／|／|／|／|／|／|／|
つまり、AC97のオーディオ出力からはこういう感じの波形が出力されています。
音で聴くと「ブー」という音になります。
WM9711は、出力信号を入力にループバックさせてAD変換することができるので、DAで出力した信号を再びAD変換してFPGAに取り込み、画面に表示させて見てみました。
結果は、
本当は直線的に延びていく波形なのですが、なぜか半分くらいのところでとつぜん、値が下がって上からでてくる、という不可解な現象となりました。
次回はこれらのデバッグを行います。
今日はBLANCAのオーディオ入力を使って、マイクから取り込んだ音声をAD変換して、それを波形として画面に表示させる機能を作ろうと思います。
要するに、BLANCAのオーディオ入力と、ビデオ出力をつかって、オシロみたいなことがやりたいわけです。
AC97のチップ「WM9711」にはマイク入力機能があるのですが、BLANCAではマイク端子やマイク用バイアス電圧端子がGNDに接続されてしまっているので、使えません。仕方なく、マイクをライン入力につなぎます。
本当はマイクアンプでも通したほうがいいのでしょうが、夜なのでとりあえず直接つないでみます。
ライン入力の信号は4.7kΩの抵抗２本を介してアースされています。GNDにつながっているほうの抵抗を外し、かわりに手近にあった10kΩをVCCからつなぎ、バイアス電源のかわりにします。
そうして、AC97のAD変換機能でライン入力の波形を取り込んで、取り込んだ波形をブロックRAMに書き込み、そしてそれを画面に波形として表示させます。
詳しい話は後でゆっくり書きますが、まず画面を。
なんか変ですね。
これは間違いです。
原因はわかりませんが、FPGAの設計に間違いがあったのでしょう。データの取り込みと画像表示のタイミングが重なっているとか、アナログのゲインがおかしいとか・・・
明日ゆっくりと原因を解析していくことにします。
最近のコメント