雑多な趣味の記録帳

年越し野沢

2泊3日で、３年ぶり？の年越し野沢。雪はたっぷりですが、夜に向けて体力温存します。

V-scale もくじ

V-scale というオープンソースマイコンを拾ってきて FPGA に乗せて遊んでました

今は zero-riscy に乗り換え中です。

FPGA と Verilator 使ったシミュレーションで kozos のブートローダを動かし、

FPU 命令追加の途中で放置しています。

V-scale とは : github

V-scale chip を作って FPGA に乗せる話 : github

＿コンソール付きのシミュレータが欲しい 端末 XMODEM

Verilog の開発環境の話

RISC-V の開発環境の話

乗算・除算器を改良した話 １ ２ : github

FPU 拡張を追加したい話

＿構想

＿演算器のモデル記述 FADD FMUL FMADD FDIV FSQRT : github

＿組み込み 転送 演算器

＿testfloat で検証したい

Interface 2月号

Amazon で買ったら今頃届きました。

年末年始で郵便局忙しいんですかね。

RISC-V ってなに？

いまさらながら考えてみると…

普通のCPUとしては今更感がある。

特殊な機能を持つIPを制御する名もないマイコンかな？と思っている時もありました。

でも「7th RISC-V Workshop」のニュースをいくつか見た後で、今はこんな感じかと思っています。

制御用のマイコンよりももっと密結合して、つまり特殊な機能を追加命令で実装して、主役は追加命令で、基本ISAなんて減点が少なければよい。

でも、今そこにいるプレーヤはみんな、自分のコアを持っているような気がする。

言い換えると、Rocket に命令を追加している人いない。

まぁ、Chesel がだいたい悪いんだろうけど…

Rocket が立派すぎてとっつきが悪いっていうのもあるのかな？

パラメタライズのし過ぎで、どんな設定もできるけど、どの設定もいまいちって気がしないこともないし…

だから、zero-riscy とか V-scale とか拾ってくるんだけど、本当は UCB のお墨付きコアを使いたいんです。

それとも、今のところは CPU を作る人しか RISC-V に興味を持っていないのかな？

BNN 推論環境のバイナリ化

zero-riscy 環境で最適化していた BNN の推論プログラムの変更箇所を、BNN 推論環境のリポジトリに戻しました。

志賀高原初すべり

志賀高原へ初滑りに行ってきました。

最近は全く体を動かしていないのでとっても不安でしたが、まあ何とか2日間無事に滑れました。

今シーズンはなんか上達できるかな？

Vivado 2017.4 リリース

Windows Fall Creators Update でも起動するようになったようです。

zero-riscy で3個目の推論プログラムが動きました

いよいよ XNOR とビットカウントを使って、最適化最終段階に入ります。

ビットカウントはネットで拾った下の計算。

// C or C++: use uint32_t

i = i - ((i >> 1) & 0x55555555);

i = (i & 0x33333333) + ((i >> 2) & 0x33333333);

return (((i + (i >> 4)) & 0x0F0F0F0F) * 0x01010101) >> 24;

恐ろしいくらいの最適化ですね。

もちろんこれは、論理演算だろうが掛け算だろうが同じ速度で計算するCPUならではの最適化法です。RTL 設計には当てはまらないのでご注意ください。

話を推論に戻すと、期待以上にだいぶ速くなりました。

置き場所としていまいちかもしれんせんが、Github の zero-riscy のテスト環境 に置いておきました。

ちなみに、

オリジナルっていうのは 32bit float だとこのくらいかなって鉛筆なめた数字で、

bin 値のみはパラメータはバイナリ型を int 型に詰め込んでデータサイズを削減しつつ、ワークメモリのほうは整数型を使っているバージョン、

bin 実行順はアクティベーション間の計算順序を幅優先から深さ優先に変更して保存するワークデータ数を削減しつつ、データ型も signed char に変更して使用メモリ量を削減したバージョン、

bin 完成はワークメモリもバイナリ型を int 型に詰め込んで、計算も XNOR + bit カウントに変更したバージョンです

zero-riscy で2個目の推論プログラムが動きました

推論プログラムで使うワークメモリを減らすために、アクティベーション間の計算順序を幅優先から深さ優先に変更しました。

ついでにアクティベーションデータは±1だけなので、char 型に変更してみたのが運の尽き、大変な目にあいました。

char 型って gcc のバージョンによって、デフォルトが符号付きだったり無しだったりするのでしょうか？

[追記 バージョン依存ではなく、ターゲットアーキテクチャに依存するようです。ご参考まで。]

WSL 上で実行するとちゃんと動くのに、RISC-V 用にコンパイルすると動かない。

逆アセンブルしてみるとなんかおかしい。この解析にとっても時間がかかってしまいました。

そんなわけで、XNOR とビットカウントを使った最適化はまた明日。

なんでか知らないけど、実行サイクル数もぐっと減っていますね。

zero-riscy で1個目の推論プログラムが動きました

Verilator を使って試行中なのですが、割り当てメモリがどんどん増えて、命令32KBとデータ512KBでデバッグしています。

とりあえず1データだけですが、103775576サイクルで完走しました。正しく計算できている模様です。

だいぶ遅いとはいえ、シミュレーションで流して見れるのはやっぱり便利です。Verilator えらい。

いまさらながら、使用メモリ量をざっと見積もってみました。

ここ においてあるソースファイルから、目立つバッファを抜き出しています。

パラメータと計算中のデータを置いておくメモリの合計で約480KBのメモリを使うみたいです。

データメモリを512KBにしたのでぎりぎり間に合っているかな？でもこのままだと、FPGAには乗らなさそうです。

データを置いておくメモリは全く最適化していないし、そもそも32bit整数型の必要もないはずなんですけどね。

やっぱりソフトウェアもちゃんと最適化たいと思いますが、まずはデータ削減のために演算順序を変えるところから。

アクティベーションからアクティベーションの間を幅優先から深さ優先に変更します。

これで必要な中間バッファががっつり減ります。

まぁ、本来なら中間バッファの再利用もしたほうが良いのでしょうけどね。

ワークメモリはこれくらいに減る予定です。

これなら Arty Z7-20 にも Arty A7-35 にも乗りますかね？

まだ試していませんけど…