2014年6月29日日曜日

環境発電

FPGAとは関係無い話題。
秋月電子で環境発電(エネルギーハーベスト)関連の部品を扱い始めたようだ。もしかしたら、ずっと以前から扱っていたのかも知れないが私はつい最近それに気づいた。  環境発電関係はストロベリーリナックスでも扱っていて、私としてはこちらの商品の方が面白い。  幾つか購入してみた。

購入したのはMICROCHIPのMCP1640を使ったDC/DCコンバータ基板、 austriamicrosystemsのAS1322Aを使ったDC/DCコンバータ基板、リニアテクノロジーのLTC3105を使ったDC/DCコンバータ基板、LTC3588を使った圧電素子・振動発電モジュール、そして0.1Fのスーパーキャパシタだ。 何れのDC/DCコンバータも1V以下の電圧から動作可能で、LTC3105に至ってはなんと250mVから動作するらしい。あと、LTC3588も面白い。これは圧電素子等で発生する交流電圧を+3.3V等に変換する。(取り出せる電力はそれほど大きく無い。) 圧電素子・振動発電モジュールという名称ではあるが、入力は交流信号であればいいので、電磁的な信号源も使えるかも知れない。  このレベルになると電流を[A]ではなく[C/S] (クーロン毎秒)で考えなきゃならない位にシビアな世界のような気もするが、なかなか面白そうな分野ではある。


my_FPGA_BOARD 8 (FT2232HのFT245モード 2)

FPGAとFT2232H間のハンドシェイクは下図の通りTXE#とWR#で行われる。


オシロスコープでFPGA→FT2232H間のハンドシェイク信号を見てみた。
CH1(黄色)がTXE#、CH2(ピンク)がWR#。

WR#のLを検出してTXE#がHになるまでの時間(t6)は5.0ns (仕様は1ns〜14nsの範囲)

WR#サイクル後のTXE#のinactive期間(t7)が79ns (仕様は49ns以上)

WR#の幅は約36ns(仕様は30ns以上)

TXE#の周期は134nsでデータレートに換算すると7.46Mバイト/sec

ロジアナソフトのプログレスバーの動作時間から算出したデータレートの5.3Mバイト/secよりも高い。。。途中で速度が低下する事象でも発生してるんだろうか?  そこで、データ転送中にHになるフラグ信号をFPGAの未使用ピンに出してそれを観測してみた。 
以下(CH2・ピンクがフラグ信号)が観測した波形で、これによると転送時間は2.27secだった。
フラグ信号が途中でLに落ちているのはアップロードが2回に分かれているからであり、これはロジアナのバッファ構造に起因する。ロジアナのバッファはリングバッファになっており、データを時系列にするためには、ソフトウェアはまずカレントポインタからバッファの最終番地までを取り込み、次にバッファの先頭番地からカレントポインタまでを取り込む必要があるためである。以下はロジアナアプリのデータを取得する部分だ。

たまたま、カレントポインタの位置がバッファ先頭であればアップロードは1回で済むが、多くの場合はこのように前半・後半の2回になる。  また、それによる中断時間は28msec程度だ。
何れにしろ、上記波形からアップロードは約2秒で出来ている。。。が、ソフトウェアでは3秒程度要しているように見えている。この差の時間はソフトウェア(GUIやスレッド処理等)の処理時間なのかも知れない。


2014年6月22日日曜日

my_FPGA_BOARD 7 (FT2232HのFT245モード)

FT2232HのFT245モードを試してみた。

my_FPGA_BOARDではFT2232HのPORT Bを通信I/Fとして使用しているので、同期型245FIFOではなく、非同期型245 FIFO (FT245 Style Asynchronous FIFO)が使用できる。

FT2232Hを非同期型FT245モードにするには、EEPROMで設定する必要がある。

ただし、この設定方法が若干判り辛い。 非同期FT245にする場合はPORT A, B双方を245モードに設定しなければならない。

具体的には、EEPROMに書き込むFT_PROGRAM_DATA構造体のRev 7 (FT2232H) Extensionsの部分のIFAIsFifo7とIFBIsFifo7を1にする。

これで、非同期FT245モードになる。 ソフトウェアからFT_SetBitMode関数で設定する必要はない。

RTLはUART版の場合は以下のような構造にしていた。

FT245版では以下のようにuart_coreが無くなり、uif_v2に相当する部分をft245ifとして、FT245 I/Fとのハンドシェイク回路もこのモジュールに持たせた。


FT245 I/Fのハンドシェークの仕様は以下のようになっている。 受信(FT2232H→FPGA)はRXF#とRD#によるハンドシェーク、送信(FPGA→FT2232H)はTXE#とWR#によるハンドシェークである。データバスは共通なので、一時に送受何れかのみの通信となる。つまり半二重だ。


RTLは以下のように記述した。


RXF#、TXE#ともにFPGAの内部クロックにとっては非同期信号になるので、同期化(FF2段受け)しているが、これはハンドシェークループの中では信号を遅延させていることにもなるため、通信速度の律速要因となってしまう。 以下はモジュールの単体シミュレーションの波形だが、これから受信の最大転送レートは133.34ns (7.5MB/sec)、送信の最大転送レートは106.67ns (9.37MB/sec)となった。 ただし、これはあくまでもモジュール単体での論理的最大値である。



FT245版のロジアナと従来のUART(8Mbps)版のロジアナとでバッファ長4Mの場合のデータのアップロード時間を比べてみた。

UART版は約20秒要している。
video

これに対し、FT245版は約3秒だった。
video

FT245版がUART版よりも高速ではあるが、単体シミュレーションで求めた送信の最大レートと比べると遅い。まだ、どこかに改善の余地があるのかも知れない。

※ 補足 (2014.6.23追記)
ロジアナのバッファ長は1サンプル単位で表現していて、1サンプルは32bit、つまり4バイトである。
したがって、バッファ長4Mはバイト数では16Mバイトということになる。 UART版は通信パラメータは語長8bit、1ストップビット、パリティ無しでボーレートは8Mbpsなので800Kバイト/sec。 16Mバイト転送に要する時間は16M/800K = 20[sec]となり上述の値と一致する。 一方、FT245版の方は論理的には9.3Mバイト/sec位は出る筈(但し、FT2232Hのデータシートでは8Mバイト/secが最大と書いてある)だが、現状は16M/3sec = 5.3Mバイト/secである。


2014年6月14日土曜日

my_FPGA_BOARD 6

前回のブログで告知した(※)MY_FPGA_BOARDの生板プレゼントですが、1名の方から応募がありましたのでその方に送付しました。

※  募集期間が終了したので、前回のブログから告知の部分は削除しました。


MY_FPGA_BOARDの設計データはホームページ (http://www.hi-ho.ne.jp/bravo-fpga/) で公開しました。


2014年6月8日日曜日

my_FPGA_BOARD 5 (動作確認)

このブログの統計情報によると、なんちゃってロジアナの記事がスペインやトルコや台湾等からよく見られているようだ。 こうして、「なんちゃって」というワードがそれらの地域に流布して行くのか。。。 数年後には向こうのエンジニア達が「ナン・チャッテ〜」とか言い出したりして。その光景を思い浮かべるだけで・・・、もう・・・、何故だろう目から熱いものが・・・ ってことは無いけど。

基板だが、しょうもないミスがもうひとつあった。
基板にシルクで設計年月を入れておいたのだが、西暦を1年間違えてしまっていた。
電気的な部分を重点的にチェックしたせいで、シルクの西暦は完全に見落としてしまったようだ。
こうして、しょうもないところでズッコケる癖がいつまでたっても治らない。違う意味で泣きたくなる。


さて、SDRAMだが、こちらは動作した。

前回のブログに書いた部品表ではSDRAMはAS4C4M16Sという128Mbの型番を記載してあるが、実際に基板に実装したのはAS4C16M16Sという256MbのSDRAMである。 RS componentsにAlliance MemoryのSDRAM AS4Cxx が驚異的な安さで出ていたので128Mbと256Mbを購入し、1枚目の基板には256Mbを実装してみた。

SDRAMのチェックは以前作成したLFSR方式のrw_chk回路を実装して動作させている。


アクセスの頻度は以下のような感じだ。

simulationの波形

拡大

さらに拡大

このrw_chk動作中の基板の消費電流は5V印加時で約190mAだった。

電源部の回路は以下のようにUSBからの電源とコネクタからの電源をダイオードスイッチを介して供給している。上記の測定ではまずUSBとコネクタから電源を供給した状態でPCから回路を起動してからUSBコネクタを抜き、電源の出力電流を読んでいる。

電源電圧の下限は約3.6Vだった。

ということで、電気的に致命的なミスは無いようだ。


2014年6月1日日曜日

my_FPGA_BOARD 4 (基板のASSY)

金曜日に基板が届いた。 どんな荷姿で届くんだろうと思っていたら、小さい箱だった。

内容物説明が何故かGiftになっている。(チェックが付いている)

早速、開梱


今回は、信号線幅は0.22mm、VIAは0.6mm(ランド径)/0.3mm(穴径)で設計したのだが、パターンは綺麗に仕上がっているようだ。



し、しまった。。。 年数を間違えてた。  orz



シルク印刷は部品面側は綺麗に出来ているのだが、半田面側は滲んでいる部分があった。

全ての基板が同じ訳では無くて良い物もあるので、データ作成の問題では無さそう。多分製造上の問題だろう。

もう1箇所、ミスが発覚してしまった。   写真の真ん中辺にC49があるが、その左隣の部品のReference文字が無い!!!   データを確認したところ、これはC47で、Reference文字はC49の枠内に置いてしまっていた。

LatticeのBreakout Boardとの比較

この外形だと、秋月通商で売っているアクリルケースにも収納できる。

Breakout Boardは微妙なところで入らない。


外観検査はこの位にして、部品実装に移った。 QFPやSDRAM等の大きな部品はすぐ実装出来たのだが、C・R類の実装に手間取って結局5時間かかった。


FPGA部   ハンダゴテで手付した割りには、うまく出来ていると思う。




FT2232HL部  少しズレてしまったが、隣接パッドとショートしていないのでこのまま行くことにした。


SDRAM部  ここはピン間ピッチが広いので簡単だった。

USBコネクタ部付近


+5Vの電源を供給して電圧レギュレータ出力を確認した。 (FPGAなblank、USBも繋いでいない状態)
コア電圧(+1.2V) 若干高めだけどまっいっか。

+3.3V

この状態での電流は約40mAだった。  FPGAに回路情報を書いて動作させればもっと多くなる筈。


回路情報をFPGAに書いて動作を見てみた。 これはロジアナの回路のピン配をこの基板用に変更したものだが、LEDを点滅する回路も含んでいるのでまずは、この部分の確認から行う。
FT2232HLのEEPROMがプログラムされていない状態、つまり、DescriptionにLatticeの文字列がない状態でLatticeのツールがちゃんとFPGAにコンフィグデータを書いてくれるか不安だったのだが、大丈夫の様だ。ちゃんと書き込みできた。
LEDはFPGAのINITとDONEピンに接続している。このピンはユーザーI/Oとしても使える。ALTERAの場合は、コンフィグ関連のピンをユーザーI/Oとして使う場合は設定が必要だが、Latticeの場合はDefaultでユーザI/Oとして使え、逆にコンフィグ専用にしたい場合に設定が必要な様である。

動いた。
video

次に、FT2232HLのEEPROMの書き込みに取り掛かったのだが、EEPROMの購入ミスが発覚した。  FT2232HLに接続するEEPROMは93LC46や56で16bitアクセスできるものでなければならないのだが、間違って8bit専用のものを買ってしまっていた。   仕方ないのでジャンク箱を漁ってみたら16bitタイプの93LC56が載ったジャンクのサウンドカードが出てきたのでそこから取り外して使うことにした。 結果、書き込み出来た。

書き込みデータの一部

FTDIのライブラリを使って書き込むのでプログラムはとてもシンプルだ。

この基板をPCに接続し、Linuxのlsusbコマンドで見ると以下のように見える。

ついでなので、ロジアナも書き込みを行った。

GUIプログラム起動時のPORT SELECTIONでは以下のように表示される。

ということで、ここまでは致命的な問題も無く出来た。 後は、SDRAM周りの動作確認になる。

この基板の部品表は以下の通りで、基板も含めて1枚あたり\4,000以下だ。ただし、C,R等の部品が購入できる数量が大きかったりするので全部の部品を新規に揃える場合はもっと上がることになるだろう。



GTX1050Ti と Tesla m2050 No.2 (BNN-PYNQのtrainingをやってみた)

BNN-PYNQのtraining(学習)をやってみた。  手順は https://github.com/Xilinx/BNN-PYNQ/tree/master/bnn/src/training に記載されており、特に判りづらい点はなかった。 ・ mnist.py 実行...