雑多な趣味の記録帳

CUDA9.2+CuPy4

特に必要があった訳ではないのですが、CUDAとCuPyを新しくしました。

CUDAは普通にアップデートしただけです。

CuPyは古いバージョンを削除してから新しいのを入れようと思ったのですが、うまくCUDAを見つけてくれなくてインストール出来ません。結局Anacondaを削除して、最新のを再インストールしてからCuPyをインストールすることでうまく出来ました。

で、最近は使っていなかったのでよく覚えていないのですが、自作のBNNでは4~50%くらいのGPU使用率だったのが、CUDAのおかげかCuPyのおかげかは分かりませんが、GPU使用率が8~90%になりました。多分、処理速度も2倍近くになっていると思います。前のことはあまり覚えていませんが…

FPGA の zero-riscy の BNN アクセラレータをメモリマップ型に更新

BNN アクセラレータのメモリマップ型でスクラッチパッド RAM 統合型が完成したので、FPGA に載せて見たいと思います。

統合前は、ソフトウェア推論には大量のデータメモリが必要で、アクセラレータ付きの時は大きなアクセラレータ内蔵メモリが必要でした。どちらにも対応できるデザインは使用メモリが大きすぎたので ARTY A7 には乗りません でした。

今回の変更で、ソフトウェアが自由にメモリの使用量を分割できるようになったので、メモリの小さな(と言っても 220KB あるけど) ARTY A7 にも載せる事が出来ます。

がしかし… 結構大変でした。

結局はデザインのバグだった(FPGA用にメモリのRTLだけは別に作っているので…)のですが、Vivado のバージョンアップを疑ってみたり、自作の IP に readmemh で初期化するメモリがあってそこではまったりといろいろ時間がかかりました。

後者(readmemh)の問題は、下みたいなファイルをインクルードする方法に変えました。ところで、バイト制御付きの RAM を推論する方法ってないんですかね？

reg [7:0] ram [0:8*1024-1] = {
8'h17,

略

8'h00};

しかし、Vivado ってやっぱりなんか使いにくいです。

mbed (yotta だけど) とか使ってみた後だと余計にそう感じます。

ちなみに、ARTY Z7 なら余裕です。github 更新しました。

メモリマップ BNN アクセラレータを小型化する

BNN アクセラレータはかなり高速なのですが、それにデータをくべる CPU が鈍足なので性能を生かしきれいていません。

回路の量はさほど気にはしていないのですが、メモリアクセス幅が 1024bit っていうのは、無駄遣いするのはちょっとなぁと思います。そんなわけで、アクセラレータを時分割動作に変更しようと思います。

具体的には、現状 32bit 幅の回路を 32個インスタンスしていますが、これを 8個に減らして 4サイクル繰り返し動作にします。メモリアクセス幅は 256bit になります。実際は、8サイクル動作(128bit)にしても大した性能低下はないと思っているのですが、将来 CPU が高速化することを夢見て…

上が 32bit 分のアクティベーションを作る波形です。上から、クロック、BNNのリクエスト、データRAMアクセスリクエスト、ユニットビジーの負論理、BNN動作中、の信号です。まだスカスカです。

左から、最初に1個が BNN 初期化、3+3+4 の波が 9画素分の畳み込みとプーリング、それを4回繰り返した後にノーマライズとアクティベーションのちょっと長めの波が来ます。

この変更で、今までウェイト制御を気にせずに済ませていたメモリアクセス論理(ペリフェラルだけは気にしていたけど)にウェイト制御を追加しました。

セットアップも含めた1枚の画像を推論するプログラムの実行時間が 1637165 サイクルから 1639325 サイクルになりました。

ちなみに自由度は減りますが、カーネルサイズ3x3固定、入力チャンネル数32bitに固定したらこれくらいにはなります。

メモリマップ BNN アクセラレータをデータスクラッチパッド RAM と統合する

メモリマップの BNN アクセラレータがそこそこ動いているようなので、データスクラッチパッド RAM と統合したいと思います。

128KB のメモリを普通のデータ RAM としてアクセスするときは 0x80100000-0x80120000 でアクセスします。

BNN アクセラレータは 1ワードが 1024bit なのですが、32bit ストア命令でアクセスしたいので 1024bit 毎に アドレスが 4だけ増加します。割り当てアドレスは 0x80180000-0x80181000 かな？

今回は BNN メモリに 80KB 割り当てることにしたので、RAM として使えるのが 0x80100000-0x8010c000 で、BNN メモリは 0x80180600-0x80181000 になります。

せっかくなので、BNN メモリは ELF ファイルに書かれた値で kozos ブートローダが初期化するようにしたい思います。ちなみに BNN メモリは、0x8010c000-0x80120000 を使って、通常のメモリライトで初期化可能です。

ld.scr には

MEMORY

{

略

ramp(rw) : o = 0x8010c000, l = 0x00014000 /* 80KB */

略

SECTIONS

{

略

.param : {

_param_start = . ;

*(.param)_eparam = . ;

} > ramp

と書いて、param.s にこんな感じでデータを並べます。

.section .param,"aw"

.word 0x26698990

略

こうしておくと、プログラムのロードと一緒に BNN アクセラレータのパラメータの初期化が出来ます。

github 更新しました。

今のところ zero-riscy がのんびり動くので大丈夫なのですが、そろそろウェイト制御を追加したいと思います。

zero-riscy の BNN 命令を メモリマップされたアクセラレータに変更する 2

zero-riscy の BNN アクセラレーションは、今までは追加命令として実装していましたが、メモリマップされたIPに変更しようと思います。

まずは、8bit 行列積ユニットと一体だった BNN アクセラレータを分離しました。

かなりいい加減な形で新 IP を置いていますが、何とか動いているようなので、github を更新しました。

この先はデータSRAMと合体して、パラメタメモリとデータメモリを共有する予定です。

zero-riscy の BNN 命令を メモリマップされたアクセラレータに変更する

zero-riscy の BNN アクセラレーションは、今までは追加命令として実装していましたが、オペランドをよく見ているとメモリアクセス命令ととっても似ていることに気が付きました。

そんなわけで、8bit 行列積ユニットと一体だった BNN アクセラレータを分離して、データ SRAM と一体構造に変更しようと思います。

使い方は、今まではアセンブラで

.global bnn_acc
bnn_acc:
.word BNN_ACC_OP|RS1_A0|RS2_A1
ret
こう書いて、Cからはこんな感じで使っていましたが、

extern int bnn_acc(int,int);

bnn_acc(f+c*fyi*fxi+fy*fxi*ci+fx*ci+fc,in[fy+(y+yy)][fx+(x+xx)][fc]);

今後はこんな感じになります。

volatile static int *ACC = 0x80180000;

ACC[f+c*fyi*fxi+fy*fxi*ci+fx*ci+fc] = in[fy+(y+yy)][fx+(x+xx)][fc];

頻繁な関数呼び出しから解放されるし、レジスタの割り当ても自由になると思います。

FPGA の zero-riscy でアクセラレータ命令付きの推論をする

zero-riscy 環境では、ブートrom 16KB、命令ram 16KB、データram 128KB を積んでいます。 データram が大きいのは bnn の学習結果を乗せるためです。

そして、アクセラレータ回路は専用のパラメタメモリを 1024bit×568ワード 積んでいます。

他にも細かいのがあるかもしれませんが、全部合わせると 36Kbit のブロックRAMを 69 個使うみたいです。

ちなみに、アクセラレータ回路がなければ 40.5 個使います。

ところが、Arty に載っている Artix7-35 は、ブロックRAMを 50 個しか積んでいません。

アクセラレータを使うときは、データramを減らしても良いと思うのですが、それもいまいち面倒ですし…

そんなわけで、ブロックRAMを140個積んでいる Arty Z7 に移行しようと思います。

ブロックデザインはこんな感じ。

さすがにアクセラレータを使うと結構速くなって、もしかすると UART の表示ネックになってるかな？って感じもします。

FPGA の zero-riscy で推論する

FPGA 上の zero-riscy で SD カードを読めるようになったので、BNN の推論プログラムを動かして見たいと思います。

今までだって、シミュレーションと同じことなら FPGA 上でもできたと思うのですが、せっかく FPGA 上で動かすなら、1画像だけじゃなくて、もっとたくさんの画像で試したいですよね。でも今までは、大量データを FPGA で扱う方法がなかったのです。それが、 SD カードインタフェースの追加で、やっと可能になりました。

さらに、プログラムのロードもメモリ利用効率の悪い XMODEM を使った kozos ブートロードでは出来ないと思い、SD カードからのブートも追加しました。

とりあえず、BNN の最適化までを済ませたソフトウェア推論で試してみました。

Core i5 と比べるとものすごく遅いですねぇ。

パラメタメモリを内蔵した BNN アクセラレータを積んだ zero-riscy は、今のサイズのデータメモリと共存するにはメモリ使用量が多すぎて Arty A7 には乗りません。Arty Z7 に引っ越すかな…

kozos on zero-riscy に SD BOOT 機能を追加したい

zero-riscy シミュレータにダミーの SD CARD (ファイルアクセス)モジュールを追加して、偽の f_mount, f_open, f_read, f_lseek 関数を実現しました。この4個の関数を使って kozos のブートローダに SD カード上の ELF ファイルを読み込んで実行する機能を追加します。使い方は、

run(スペース)ファイル名

で、sdcard/ ディレクトリ下の ELF ファイルを読み込んで実行します。

まだ、FPGA + 本物の FatFs では試していませんが…

zero-riscy シミュレータにファイルアクセス機能を追加したい

FPGA で SD カードを読めるようになったので、シミュレータにもファイルアクセス機能を追加したいと思います。

UART のエミュレーションでは、IP のレジスタレベルのエミュレーションでした(FPGA で 使う UART IP を変えちゃったので今は互換性ないですが)。

このときは CPU 自体が信用できなかったのでそうしましたが、今回はすでに FPGA でファイルアクセスが出来ているっぽいので、FatFs 関数レベルの互換にします。サポートするのは f_mount, f_open, f_read, f_lseek があれば、まずはよいですかね。いずれはディレクトリの読み出しもしたいですが。

そんな訳で、ダミーモジュールにはファイル名や読み出しサイズなどを設定するためのレジスタインタのフェースだけを設けて、テストベンチから無理やり FatFs の機能を実現したいと思っています。f_read なんかは、転送サイズにかかわらず 0 サイクルでファイルの中身がメモリにコピーされちゃう優れものです。

ごく普通にホスト OS のファイルアクセス機能を使うだけなので、FAT じゃなくても動きます。