« 2005年10月 | トップページ | 2005年12月 »

2005.11.27

EZ-USB FX2とSpartan3を接続

EZ-USB FX2とSpartan3をつないで実験しています。

前回の実験では、EZ-USB FX2とCoolRunnerIIを接続して、SlaveFIFOの8ビットモードを使って、どこまで速度が出るかなどを測りました。
今回は、FPGAを使って16ビットモードにして、同様の実験をすることにします。
上手い具合にEZ-USB FX2のレジスタを設定してやると、300Mbpsくらいの速度で転送ができました。でも、どうやら8ビットモードと16ビットモードで、フラグの立つタイミングが微妙に異なるような気配です。

次の図は、131072バイトをバルクIN転送した際の、WR信号とフラグの波形です。
ezusbfx2_1

黒くなっている部分が転送が行われているタイミングです。
この波形を見ると全部で3回に分けて転送が行われているのがわかります。

1回目の細い転送は512バイトです。EZ-USBのデバイスドライバでは、64kバイトの受信をするように指定しても、必ず最初に受信するデータは512バイトになるようです。

その後、数ミリ秒のアイドル期間を置いて、約1.6ミリ秒の間、転送が行われています。それから240μ秒のアイドル期間をおいて、再び1.6ミリ秒の転送が行われています。

これは、EZ-USBのデバイスドライバが64kバイト以上のデータを扱えないので、131072バイトの転送を2回に分けて行ったためです。よって、1回の転送の塊で約64kバイトを送っています。

1.6ミリ秒で64kバイトを転送するので、瞬間最大速度は327Mbpsとなります。
つまり、EZ-USB FX2のSlaveFIFOは、8ビットモードでアクセスしても、16ビットモードでアクセスしても、最大速度は変わらないようです。

次の図は、上の波形を拡大したものです。
ezusbfx2_2
125μ秒の間に、10回の転送(波形がLになっている部分)が行われているのが分かります。1回の転送時間は約5.36μ秒ですから、5.36μ秒×16ビット×48MHz=512バイトで、USB2.0のHighSpeedモードのパケット1個分のデータ量に相当するのがわかります。

つまり、
16bit*48MHz=768Mbps → USBのバスの制約により328Mbpsに制限される
8bit*48MHz=384Mbps → USBのバスの制約により328Mbpsに制限される
ということのようです。
このことは、必ずしもEZ-USBとFPGA間の接続を16ビットにしなくても、バルクIN転送に関しては、限界の速度が出せるということを意味します。

システム全体としてのスループットを考慮するなら、ちょっと考えなければなりません。16ビットモードでは1パケット分のデータを送る時間は5μ秒なのに対して、8ビットモードでは11μ秒かかります。FPGAの後ろにSDRAMなどを置いた場合、FIFOを作らなければ、長い間SDRAMのバスを占有することになりますから、システム全体のスループットは下がるかもしれません。

EZ-USB FX2とFPGAをつないで、満足のいく性能を出すのは、かなり大変です。(決してEasyじゃありません)

今回の実験を行う際に活躍したのは、MITOUJTAGの開発中の新しいロジアナ機能です。
ブロックRAMにFPGAの内部の波形を溜め込んで、あとからJTAGで読み出すしくみなので、48MHzで動くEZ-USB FX2との制御信号もばっちり1クロックづつ見ることが出来ました。

もうJTAGロジアナの速度が気になることはありません。MITOUJTAGの開発は、このように自分で実際に実務に使いながら、デバッグを行っています。
ezusbfx2_3

| | コメント (0)

2005.11.26

目覚しい目覚し時計

目覚まし時計が机から落下して、アラームが鳴らなくなったので、修理しようと思いました。
定価3500円の、MADE IN CHINAと書かれた普通に売られている目覚まし時計です。
振るとカシャカシャと小さな音がするので、何かの部品が折れていたら嫌だなと思いつつ、開けてみました

・・・

開けてびっくり。
fruity1
うわっ!ぎゃっ、この配線は・・・

抵抗なんか空中配線されてます。
fruity2
ショートしないか心配でアラームよりも早く起きてしまいそうです。

何ですと?ビニル電線が短かったらしく、絶縁せずにつぎはぎしています。赤い電線ですからVCCでしょうか。
fruity3

きっとこれがどこかにショートして、アラームが鳴らなくなったのでしょう。
カシャカシャと音がしていたのは、半田のカスでした。ポロっと出てきました。

修理するまでもなく、開けただけでアラームが鳴るようになりました。

| | コメント (0)

2005.11.18

ET2005でトラ技付録CPLD基板を紹介

ET2005のCQ出版ブースにおいて、2006年4月号のトラ技付録CPLD基板紹介の講演をさせていただきました。
ET2005 CQ出版ブースにて講演

お聴きいただいた皆様、ありがとうございました。

MITOUJTAG特別体験版MITOUJTAG特別体験版もご期待ください。

#講演後、Mobile JTAG Cableをご使用でEP1Kが認識されないと質問された方、ここを読まれていたらメールください。会場でお名前を聴き忘れました。

| | コメント (0)

ET2005で講演します

ET2005も最終日ですが、本日18日、CQ出版様のブースにおいて、来年のトランジスタ技術付録CPLD基板の紹介と応用について講演をさせていただきます。
http://www.kumikomi.net/info/et2005.html

 日時 11月18日(金) 11:30-12:00
 場所 パシフィコ横浜 CQ出版ブース[C-44]
 タイトル 『トラ技』2006年4月号付録 MAX II CPLD基板の魅力

ET2005へ起こしの際は、ぜひお立ち寄りください。

| | コメント (0)

2005.11.13

伊勢参り

長年の夢だった伊勢参りに行ってきました。
東京から名古屋まで新幹線。名古屋から伊勢市までは、「快速みえ」で行きます。
名古屋から伊勢まで結構あります。
出発したのが朝6時30ですが、伊勢に着いたころにはすっかりお昼になっていました。

伊勢神宮は、外宮(げくう)と内宮(ないくう)と2つあり、内宮は天照大御神を、外宮は豊受大御神とよばれるお米や産業のお恵みを与えてくださる守護神をまつっています。
まずは外宮から参り、それから内宮へ参ります。
外宮は駅の近くにありますが、内宮は駅から数キロ離れていて車で10分程度あります。

内宮と外宮の正殿の隣には古殿地という土地が広がっています。これは、式年遷宮といって20年に一度、御装束や御神宝もすべて新調し、新しいお社をそこに建てるためだそうで、持統天皇(690年)のころから1300年も続いているそうです。次の第62回式年遷宮は平成25年だそうです。凄いスケールです。
内宮と外宮も、どちらもとても素晴らしかったです。

内宮の近くには土産物屋が並んでいて、にぎやかな通りになっています。
お土産に、お札をと赤福を頂いて帰って来ました。

伊勢神宮に参る人の数は、年間600万人とガイドブックに載っていました。
これは相当な人数ですよ。

| | コメント (0)

2005.11.12

JTAGロジックアナライザが200MHzで動作!?

JTAGロジックアナライザが200MHzで動作するようになりました。

その仕組みは、FPGAの中にあるメモリに波形データを取り込んで、それをJTAG経由で読み出すというものです。
以前からこの機能の開発に取り組んではきたのですが、本日、ようやく満足に動作するようになりました。

いままでのMITOUJTAGのJTAGロジックアナライザは、バウンダリスキャンを利用しているので、CPUでもCPLDでもFPGAでもバスバッファでも、JTAGに対応しているデバイスであれば何でも数百本のI/O信号をサンプリングして観察できるというメリットがありました。しかし、JTAGというシリアル通信を使っているがゆえにサンプリング速度は最大でも数十kHzどまりでした。
今回の改良は、対象となるデバイスは今のところXILINXのFPGAのみで、観測できる信号数も制限されますが、数百MHzで動作する信号を一つも逃すことなくキャプチャすることができます。これは、JTAGロジックアナライザの新たな可能性を拓くものとなります。
もう、JTAGロジックアナライザが遅いなんていわせません。

この新しいJTAGロジックアナライザを使用するには、FPGAの中に下の図のようなイメージのロジアナ用のモジュールを、IPとしてあらかじめ組み込んでおきます。

blogana3

blogana4

これだけで、超高速なロジックアナライザが、FPGAに埋め込まれます。とても簡単です。

使い方はとても簡単です。通常どおりJTAGロジックアナライザを起動したら、ボタンを押して設定ダイアログを開きます。

blogana1

すると、MITOUJTAGは、FPGAにアクセスしてビット幅やデータ長やクロック周波数を自動で調べ、ダイアログに表示します。MITOUJTAG上でユーザが設定する項目は、各ビットの信号名と、トリガをかけるポイントのみです。

このダイアログが設定し終わったら、JTAGロジックアナライザの画面に戻ります。
ここでいつもどおりサンプル開始ボタンを押せば、超高速で波形をサンプリングし、それがパソコンの画面上に表示されるわけです。

blogana2(クリックで拡大)

今のところSpartan3専用ですが、Virtex2 Proなどでもそのまま動作するでしょう。そして、Virtex2や4では、さらに高速に動作することが期待されます。

バウンダリスキャンを利用した通常のJTAGロジックアナライザと内蔵メモリを活用したロジックアナライザ。この両方をうまく使いこなせば、FPGAの開発の効率は、さらに飛躍的に向上するでしょう。

(追記)
いろんなボードでこの新ロジアナを試してみたいと思い、アットマークテクノさんから発売されているFPGAボード「SUZAKU」にも実装してみました。
結果は下の図のとおり。

blogana5(クリックで拡大)

SDRAMのアドレスバスや、データバス、制御信号などが観察できます。
CAS=Hで、RASとWENがLのは、プリチャージですね。
今回のサンプリング周波数は51MHzです。

| | コメント (0)

2005.11.10

技術士二次試験(筆記)の結果

今日、技術士二次試験(筆記)の結果発表がありました。
まだ葉書がくるまでは安心できないのですが、Webで確認したところ合格でした。
Web上では氏名が出ないので、今日、都内に出るついでに文科省まで掲示を見に行ってきます。
技術士の資格を得るため、私は、一次試験→技術士補登録→二次試験(筆記)→二次試験(面接)というパターンを採っています。次は最後の関門、面接(口頭試験)です。これは12月初旬に行われるでしょう。

私が受けた部門は、電気電子部門で選択科目は電子応用です。非常に受験者が少ないマイナーな分野です。

私の試験対策は、ひたすら過去問を解くことと専門外の分野を勉強することでした。
そして、その過去問の絡んだ分野をくまなく調べることです。
電気電子の範囲は非常に幅が広く、発電や変電から照明、ビルの電気設備まで多岐にわたります。私は弱電の中の、しかもFPGAとかCPUという非常に限られた分野をやっているので、専門外の知識が非常に多く要求されました。
電気電子部門の二次試験では、長大な計算問題や自分の所感を記述する問題はありませんでした。
(問題1つに解答用紙1枚なので、スペースがない)
いろいろな現象の理論や対策を文章で記述できるかがポイントとなるようでした。
勉強方法としては、電験の参考書を読んだり、パワエレの本を読んだり、東京電力のWebサイトを見たりして、それをひたすらノートにまとめていくわけです。特に、地球環境と電気に関することは要チェックポイントでした。

勉強する上で再認識したことに、本やWebの情報は見るだけで覚えるのは難しいということがありました。手で紙に書いたり、キーを叩いてファイルに書くという操作を行わないと人間は覚えることは難しいのかもしれません。言い換えれば、自分の頭を通して、入力して出力しないと、なかなか記憶として定着しないようでした。
平たく言えば、書いて書いて書いて書いて、ようやくおぼえるという感じでした

さて、今年の経験論文は、ちょっと変わっていました。
普通は技術士の経験論文といえば、『あなたが受験申込書に記入した「専門とする事項」について、技術士にふさわしいと思われる業績の2つを答案用紙に6枚以内にまとめよ』という感じで出題されます。
このような普通の問題文ならば、従来の技術、解決すべき課題、課題を解決すべき方法、その効果、という具合にまるで特許明細書みたいな要領で書いていけばよかったのですが、今年の電子応用の問題形式はちょっと変わっていて、


『あなたが受験申込書に記入した「専門とする事項」に関して、あなたがこれまでに実際に行った業務の中から、技術士にふさわしいと思われる業績2つを選び、それぞれ次の(イ)、(ロ)、(ハ)の設問に答えよ
 (イ)業績の概要とあなたの役割
 (ロ)業績の出発点(理論的基礎)となる「公知の法則」ないしは「公知の理論」の概略を解説せよ
 (ハ)あなたは、それらをどのように応用して、業績を完成させたのか、その技術的な展開(みちすじ)を述べよ。』

という、初めて見るパターンでした。ともかく「公知の理論」を元にして自分の業績を説明しなければならないのです。
準備していたものがすべてふっとんでしまいました。それでも経験年数が少ない私なりに何とか書いたのですが、今思い起こせば何を書いたのかさっぱりです。

思えば技術士になりたいと思ってから4年が経ちました。あともう一息です。
こうして書いていると、ようやく最大の難所を通ったんだなという実感が湧いてきました。
まだ最後の関門、口頭試験が残っていますので油断はできません。
今日からまた試験対策の日々が始まります。

| | コメント (2)

2005.11.09

電子部品をスキャナにかけると

大変つまらない実験ですが、電子部品をスキャンしてみました。

BGAのボール

これは、132ピンBGAの裏側で、ボール間隔は0.5mmです。物はCoolRunnerIIです。
普通のデジカメではここまで細かく(画像としては大きく)撮ることはできませんでした。

そもそもなんでこんなことをやっているかというと、ある基板の穴の位置を確認したくて、かといってノギスでは基板上の穴の位置を正確に測れなかったため、スキャナでめいっぱい高解像度で取り込み、その画像の座標から穴の位置やサイズを測ろうとしたのです。
仮に、1200dpiでキャプチャしたとしたら0.8milの解像度が期待できます。0.8milということは20μmですから、プリント基板の最も細い配線よりもずっと細いわけです。
実際にはあまりうまくいきませんでしたが、何かに応用できるといいですね。
例えばデスクトップ環境で、ソフトウェアだけで基板の実装検査ができるといいな。

かなり綺麗に撮れます。

scan1

0.65mmピッチならブリッジすればすぐに見つかるかもしれません。

scan2

0.5mmピッチも大丈夫です。
ちょっと画像処理してエッジ検出などしてみました。

scan3

うーん


| | コメント (0)

2005.11.06

EZUSB FX2のSlaveFIFOをCPLDでアクセス

 昨日(土曜日)、EZ-USB FX2を載せる基板ができあがってきました。
 スキャナでパターンの一部を読み取ってみます。
 最近、基板や小さな部品は、スキャナで結構きれいに撮れることに気が付きました。

fx2_pattern

 この基板にはEZ-USB FX2LPのQFPパッケージ版とCoolRunnerIIが載っています。昔使ったLowPower版ではないEZ-USB FX2は発熱がすごかったので、今回の基板は放熱を考慮したパターンで設計しましたが、そこまで苦労して設計する必要はなかったかもしれないです。EZUSB FX2LPはほとんど発熱しません。

 さて、EZ-USB FX2は、EZなんていう名前がついていますが、全然Easyじゃありません。
 サンプルのアプリやI/Oポートをアクセスさせるのは簡単ですが、FPGAやCPLDをつないで高速にデータを転送するとなると、とても難しいデバイスです。


インタフェース回路の設計
 Webには載せていませんが、私はこの3年間くらいの間にEZ-USB FX2とFPGAを使っていくつかの装置を設計してきました。
 それとは別に、今回、PLDとの接続インタフェース回路(IP)を1から作り直しました。
 この回路は、SlaveFIFOを使ってEZ-USB FX2とPLDをインタフェースします。バス幅は8bitで、インタフェースクロックは48MHzです。エンドポイントはダブルバッファを構成します。

 要はEZ-USB FX2から送られてくるフラグを実ながら、SLWRやSLRDといった信号を操作するだけの簡単なものですが、作ってみてEZ-USB FX2とPLDを48MHzでアクセスするのは非常に難しいと実感しました。
 なぜならば、48MHzということはクロックの周期は約21nsですが、EZ-USB FX2が要求するSLRDやSDWRといった制御信号のセットアップ/ホールドタイムは、10数ns/数nsしかありません。PLDが出力する信号の遷移できる時間の幅は僅か5nsくらいしかないのです。
 しかし、何より難しい点は、FIFOの状態を表すフラグがクロックから13.5ns秒後に変化することです。つまり、EZUSB-FX2から送られてくるフラグを見てデータの送信を止めるということは、タイミング的に間に合わないのです。

fx2_timing

 最近のCPLDやFPGAはとても高速ですが、チップの外から中に信号が入って出るにはやはり10nsくらいを要します。外とのインタフェースは、速くしようとすると、結構大変です。
 そういうわけで、EZ-USB FX2とPLD間でタイミングをとるのは簡単ではありませんでした。裏クロックを使ったり、フリップフロップの後ろにゲートを置いてそのゲートが削除されないような仕組みを施したりで、ようやくEZ-USB FX2との48MHzでのインタフェースタイミングが満たせます。


IN方向のバルク転送
 次の図は、CPLDで発生させた8MBytesの数列をホスト(パソコン)に送信したときの、SLWR信号の波形です。転送の方向は『IN』ということになります。

8MBytesのデータを書き込んだときの波形

 この「SLWR」信号がLになっているときにデータは送信されています。8MBytesのデータを送るのにおよそ236msかかっていますので、平均速度はおよそ284Mbpsということになります。
 データサイズをいろいろと変えてみましたが、およそ260~290Mbpsの間のようです。

 波形には疎密があるので拡大してみると、次の図のように周期的なパターンが繰り返しているのがわかります。

マイクロフレームにあわせてデータが書き込まれる

 この信号がLに下がっている期間にデータがCPLDからEZ-USB FX2に送られています。その期間はおよそ10.6μ秒で、48MHzの速度で512バイト(USBの1パケット)を送る時間と等しくなっています。複数のパケット連続して送ろうとすると、データを送ることができない期間が規則的に表れますが、これはSlaveFIFOがFULLになっているため送信できない時間です。

 FIFOがFULLになったままの期間はおよそ125μ秒周期で表れています。言い換えれば、およそ125μ秒の間に10個のパケットがほぼ規則正しく送信されているのがわかります。これはUSB2.0 HighSpeedでのマイクロフレームと関係があるのでしょう。

 USB2.0のHighSpeedモードでは、1パケットは512バイトで125μ秒に5120バイト送れています。ここだけ見れば瞬間最大速度は328Mbpsも出ています。この調子でずっと125μ秒間に5120バイトを送りつづけることができれば、328Mbpsの速度でパソコンにデータを送ることができるはずです。しかし、実際には次の図のように「信号を送れない長い比較的長い期間」が生じてしまいます。こういう期間が結構な頻度で出現するため、実質的な速度は300Mbpsを切ってしまいます。

 この波形を良く見ると、データを最大の効率で1.58ミリ秒送った後、データを送れない期間が200μ秒出現するということがほぼ周期的に出ています。データを送れた1.58ミリ秒の間には、1.58ms*328Mbps≒64700Bytesとなります。

データを送信できない期間もある

 実は、EZUSBのデバイスドライバは、デフォルトでは一度に64kBytesまでのデータしか扱えないので、64kBytesを超える大きなデータを送受信する際には64kBytes以下のサイズに細切れにしなければなりません。細切れにするということは、複数回DeviceIOControlを呼び出すということを意味します。
 私のテストソフトウェアでは65024バイトに分割して送っているので、その影響が出ているのでしょう。
 とにかく、64kBytesにデータを細切れにするということは、転送の効率を88%に低下させてしまうという結果になります。

 すなわち、 『IN』方向のバルク転送は、今回のハードウェアでは328Mbpsが限界で、瞬間的にはこの速度が出るものの、大きなデータを転送する際にはデバドラのオーバーヘッドで効率が88%に下がり、CPLDからPCのメモリへの実質的な転送速度は288Mbps程度に下がってしまったと考えられます。

FX2のIN方向スループットの説明


OUT方向のバルク転送

 さて、逆にホスト(パソコン)からターゲット(作った装置)にデータを送る『OUT方向』の速度も測ってみたところ、8MBytesを送った場合、平均して230Mbpsくらいでした。

 今度はSLRD信号をオシロで観察したところ、125μ秒周期の「マイクロフレーム」の間に8パケットしか受け取ることができていませんでした。このため、『IN方向』よりも速度が出ないようです。
 波形を見る限り、125μ秒周期のマイクロフレームに8パケットですから、512Byte*8*8/0.000125で、瞬間最大速度は262Mbpsとなります。

fx2_rd

 次の図は、CPLDがデータを受け取る『OUT』方向バルク転送時のSLRD信号を数ミリ秒間にわたって観測した波形です。SLRD信号が激しく遷移してデータを受け取っている期間がおよそ2ミリ秒、SLRDが動かずデータが送られていない期間がおよそ280μ秒あり、それを周期的に繰り返しています。

2ミリ秒=65536バイトごとにIDLE期間が入る

 この2ミリ秒の間に送信されたデータは、2ms*262Mbps≒65536Bytesです。本実験では8MBytesのデータをまとめて送っていますが、デバイスドライバの都合で64kバイト単位で細かく分割して送っています。このため2.28ミリ秒間に2.00ミリ秒分しかデータを送れず280μ秒はパソコン内でのデータの移動などに費やされています。要するに、デバイスドライバのために効率が87%に落ちてしまっています。

 『OUT』方向のバルク転送は今回のハードウェア的には262Mbpsが限界で、瞬間的にはこの速度が出るものの、大きなデータを転送する際にはデバドラのオーバーヘッドで効率が87%に下がり、PCのメモリからCPLDへの転送速度は227Mbps程度になってしまったと考えられます。

fx2_matome2


まとめ
 EZ-USB FX2やFX2LPのチップ自体は、USB2.0のHighSpeedモードを規格の範囲内でほぼ限界まで使うことができます。その性能を活かすことができるか否かは、接続するCPLD/FPGAの設計と、デバイスドライバの改良にかかっています。それは決してEasyではありません。

 速度をより向上させるためには、DDKを用いてEZUSBのデバドラを再コンパイルして、バルク転送時のバッファサイズの最大値を64kBytes以上に引き上げる必要があります。

 なお、今回の実験で送ったデータはテスト用の意味の無い数列で、メモリに格納されたあとすぐに破棄されてしまいます。これをハードディスクに格納したり画面に表示すれば、スループットはこれより下がるでしょう。
 以前検証した際には、EZ-USB FX2とFPGAを16ビット48MHzモードでインタフェースした場合、もう少しスループットが出ていたような気がします。今製造中の次の基板が仕上がったら、16ビットモードでも実験してみることにします。

| | コメント (0)

« 2005年10月 | トップページ | 2005年12月 »