雑多な趣味の記録帳

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 じゃなくても動きます。

zero-riscy から SD カードのファイルを読む

昨日はちゃんと読めているかと思った SD カードコントローラですが、FatFs 対応をしようとしていたらエラーで落ちました。

ここ を参考に正常な動作とどう違うかを予想してみます。とにかく、期待値が分からないのがきついです。

まずは、シミュレーションで見えていた読み出しがずれる問題 は別の形だけどやっぱりあるようで、上位の4ビットと下位の4ビットが入れ替わっていました。

それから、場合によって全然読めないこともあるようです。これは、いろいろ試しているうちに、fifo empty がネゲートされてすぐに読んではいけないらしいことが分かりました。デバッグ中は、無駄にいろいろ文字を表示していたので…

この2つをひとまずソフトウェアで対策すると、ファイル名決め打ちで開いたファイルの hexdump が出来ました。

で、今日は予定があるので本対策が出来ない… → 早く帰ってこれました。

[追記]

ビットの入れ替えは、理由は分からないけど上下を反転しました。

すぐに読んではいけない理由は、待ち時間が足りないだけではなくて、前のリードの残骸が残っているのも原因みたいでした。

CRC も FIFO に積んじゃっているのでしょうかね？

ほかに、CPUが遅いから見えてこないと思うけど、FIFO が空の時は RVALID を待たせる論理も追加しました。

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

SD コントローラは RTL モジュールなるもので作っています。

ここ を見て知ったのですが、入門書にはなんでこういう大事なことが書いていないのかな？

[追記 RTLモジュールはなんかいちいち Critical warning 出ますね。]

[追記 CD端子繋ぎました 初期化が済んだ状態から、カード取り出し→再挿入→初期化 です]

> status
4a
> status
7a
> status
5a
> open
OK: f_open
> status
4a

zero-riscy からなんでも良いので SD カードをアクセスしたい 4

SD カードの情報はなかなかまとまったのがないんだけど、Kingston の ここ からダウンロードできる仕様シートが参考になりました。

ほかには、FatFS の ChaN さんの ここ も参考になります。

では本題で、昨日の続き。
SPI モードで起動しているわけじゃないので、ACMD41 を BUSY がネゲートされるまで投げ続けると、CCS ビットが返事で返ってきます。

今どきは、デフォルトが Block Address ですよね。

CMD2, CMD3, CMD7, ACMD6 の順に投げると初期化完了です。

で、リードは CMD17。シミュレーションで読出しがずれる現象はカードのモデルが問題だったのかな？512バイトの最後2バイトが 55AA なら FAT の証拠らしいので、たぶん正しく読めていると思います。[追記 1バイトの中で上位4ビットと下位4ビットが入れ替わっていました。]

zero-riscy からなんでも良いので SD カードをアクセスしたい 3

3ステートバッファは自動に推論できなかったので IOBUF を手動で置いてみました。そして、IO にプルアップ属性を付けて、25MHz のクロックをつないで試してみます。SD カードクロックサイクルが4倍になるので、timeout も 4倍にします。

まずは、CMD0, CMD8 を入れてみます。Ver2 以上なら返事が返ってくるはずです。

ここで躓くようなら、今回の SD カードアクセス計画は失敗ってことで…

長かった。やっとここまでできた…

zero-riscy からなんでも良いので SD カードをアクセスしたい 2

とりあえず OpenCore の sd card controller の sdc_fifo を AXI Lite に変更したものと sdModel を zero-riscy のテストベンチにつないで、sdc_fifo/main.c の内容を実行してみました。

この組み合わせでは、カードの初期化(フォーマットじゃないよ)ではエラーは出ないみたい。でも、モデルは Ver2 のカードじゃないみたいなんだけど、実際に今どき手に入るカードって Ver2 以上ですよね？大丈夫かな？

初期化の後にカードを読み出すのですが、カードからはデータが出てきているみたいです。でも、コントローラが受け取るタイミングが変です。具体的には、最初にカードから0がたくさん出てきた後に所望のデータが出てくるのですが、コントローラは先行する0も受け取ってしまう模様。

これはコントローラとカードのモデルとどっちが悪いんだろうか？？とりあえず、実物で試してみようかなぁ？

そのためには、3ステートバッファをどう割り当てるのか調べなきゃいけないし、クロックが 100MHz なのも問題ですよね。

そういえば、プルアップはどうするんだろうか？Arty Z7 のスケマを見るとコマンドだけについていますね。シミュレーション動作を見ると、データにも必要な気がします(データ0 が Hi-Z から 0 へ変化するタイミングで転送開始)。やっぱりコントローラがおかしいのかなぁ？

まぁ、Pmod MicroSD アダプタには両方ともつけるの忘れたのだけど…

[追記

hoge_i

hoge_o

hoge_t

にすると、3ステートのIOバッファが推論されるみたいですね。できませんでした。

IOバッファにはプルアップ付けることもできるみたいですね。]

zero-riscy からなんでも良いので SD カードをアクセスしたい

以前、zero-riscy から ZYNQ PS の SD カードをアクセスしようと試みたのですが、初期設定がうまく出来ないのでとりあえずはあきらめた状態です。

でもやっぱり SD カードにアクセスしたいので、OpenCore の sd card controller を使ってみることにしました。Github にも同じものがあるみたいですね。

DMA を使うとややこしそうなので、本体は rtl/sdc_fifo/verilog 以下の物を使うことにしました。IF を WISHBONE から AXI Lite に変更します。

ところで AXI Lite って、リードリクエストとライトリクエストが同時に来ることってあるのでしょうか？とりあえずは無いことにして進めようと思います。

そして、制御ソフトのサンプルは sw/sdc_fifo/main.c があります。これは、全面的に逐語訳が必要に見えますが、やること自体はそのまま真似できそうです。

最後に、SD カードのモデル (master/bench/sdc_dma/verilog/sdModel.v) までそろっているようです。しかも、Github で最新のコミットログを見ると ”Ram image for the sd-card, contating part of a FAT16 filesystem. ” ってあるじゃないですか。

シミュレータだけでも結構楽しめそうですね。それが FPGA で動かなかった時のことを考えるとあれですが…

SD カード IP

ArtyA7 で SD カードを使うためには、Open Cores の sd card controller を使うのが良いかと考えています。

SD カードのアクセスは ArtyZ7 で成功してから ArtyA7 を試すつもりだったのですが、Zynq の PL から PS の SD カードのアクセスが一筋縄ではいきません。

MicroBlaze と SDK を使っても f_mount に失敗するので、PL からはアクセスできないのかもしれません。

しかたないので、先に ArtyA7 で試すことを考えてもいいのかとか悩んでます…

はんだ付けが必要ですが。