2か月振りの投稿とは，私にしては随分と速いペースでの投稿で自分もびっくりです．←
どうもどらびです．
前回の投稿は育休中に書いたもので，お休みをフル活用(そのための休みではないけども)した結果，使用するHWを大幅変更しました．今回はそれを使いこなすまでの途中経過になります．
あと一歩というところまで来た気が個人的にはしていますが，同時にここから長期戦になりそうな兆しが見えてきているのもあり，また来年度初め頃に人生の一大イベントがまた控えている都合でしばらく触れない期間がありそうな予感がするので，忘れない内に色々備忘録として残しておきたいのです．
というわけでいつも通り本編へ
システム全体像
前回の記事でもざっくりとした構成を書いていた気もしますが，現状の構成予定を再度ざっくりまとめておきます．canvaのテンプレから色味が近いの拾ってきたらポップな感じになって草．
センサからADCでLVDS3レーンのデジタルデータに変換し，それをFPGA(+SoC)で受けます．
具体的にFPGA内ではデシリアライザでパラレルデータに変換したのち，AXI4Sinterconnectで色ごとにデータを分類した上で各色のデータをFIFOで貯め，ある程度溜まったらDMAで一気にDDRに転送．
linux側でDDRのデータを読んでSSDに保存していく．というのを想定しています．
書きながら思いましたが，現状は上記のやり方でいいかなと思っていますが，今後M.2 SSDを載せられるようにした場合，一度DDR(MSS)を介してまたFPGA側に存在するSSDにデータを転送するよりも，直接SSDに向かってDMAできた方が速いだろうしDMAを介する必要もないような気もしてきています．実現できるのかどうか全くわかりませんが．
ただ前者のやり方の方が速度面で困ることがない限りは確実で安定していると思う(何よりSSDが刺さってなかろうが最低限データの確認ができる)ので，しばらくは前者のやり方を目標に作っていくと思います．
ただ，このシリーズの記事で何度か書いたような気もするのですが，1枚の写真で何も考えないと16GBくらいの容量を食うはずなので，SSDがないとまともに運用することすらできないんじゃないかという見込みがあり，いつかどこかでM.2のことを真剣に考える必要があるのは間違いありません．
FPGA側のデザイン
開発環境の準備
polarfire自体初めて触るので，まずは環境を整えました．右も左もわからないので下記リンクに沿って環境を整えるのにvirtualboxでUbuntu環境を立ちあげました(後にこれが原因で若干躓いたので要注意)
で，諸々触って慣れた後，上記サイトで紹介されている環境が古いものなのが合成時に影響しているのでは？と思う案件があったので最新に更新しようと思ったのですが，その際license Daemon周りで散々振り回された挙句オチとして「仮想環境ではDaemonがバグる」と判明したので素直にWindowsに戻ってきました．このしょうもない足踏みの間にマレーシア出張を挟んだりでトータル1か月くらい動きが止まってました．クソ．
gatewareのデザイン
とりあえず今は「最低限写真としての体裁を成す」ことを目標として進めており，より具体的に言えば前回記事時点で出来ていなかった「ADCの動確」ができるところまでを目指し，beagleV-Fire(以後BVFと略記)を改造することなく，capeを追加するだけでデータのキャプチャまでを実現する．というところに向けて進めています．
そのためにはM.2云々やらwifiやらは不要という事で，デザインも見えにくくなるので一切合切全部潔く捨てて，最低限GPIOだけ組んである状態のデザインをベースにデシリアライザ～DMAまでを行うためのデザインを作ってみました．
が後述しますがまだこいつの動確は出来ていません．よって画が撮れる状態まで至ってないのですが，なんとなくADCが動かせていそうな事はオシロ等を使って確認しております．
(余談ですが2020年頃，zynqで作ろうと思っていたころはオシロも用意してなかったのに自作基板まで作って一発で動作させようと思っていたのマジでキチガイ過ぎました．猛省です．)
ざっくり新規で作っている部分を載せておくとこんな感じで
一番左のブロックでLVDSを受けて21bitのパラレルデータにしてます．これはセンサから各ピクセルのデータがR→G→B(順序は設定で入れ替え可)の形で送られてきており，下位16bitが各色の値，上位5bitで今送っている16bitがどの色か，また有効なデータか，などを示したフラグとなっています．
上位5bitで有効なデータを篩ったうえで色事に分け，次のAXI4Sinterconnectに流します．ここでは色ごとにFIFOをかました上でAXI4 StreamのデータからAXI4のデータに変換して次に受け渡す役割を担っています．データ幅も16から64に増やしてます．
次も同じくAXI4Sinterconnectで，なぜわざわざ2段にしてるんだって話なんですが，データを色事に分解すると，出口を3つに分けるしかないのですが，後段のDMAコントローラではTDESTを使ってフラグ管理した上で，それぞれのフラグに沿って違うアドレスにDMAできます．なので，一旦色事に分けたデータをTDESTだけ振り分けて1つのAXIバスに流してあげることで，一個のDMAコントローラで3色の情報を個別に転送できるわけです．リソース削減になっているかはわかりませんが，個人的にはわかりやすくていいのかなと．
デシリアライザはsim等も活用して何度も確認しているので恐らくそれっぽい動きをしているとわかっていますが，そこから後ろ，特にDMAの挙動に関しては今後動作確認の上変更する可能性は十分にあります．なので参考にされる方がいらっしゃいましたらご注意の上，自己責任でパクってください．
SW側のデザイン
linux側の処理
今後長期戦になると言った部分が主にここに集約されています．
やはりFPGAそのものはシーケンシャルな動きしかさせないのであれば何とか動かせるようになってきた感があるのですが，どうしてもそれをMSS(zynqで言うPS，要はマイコン側)からSWを介して制御するところのハードルが大分高いです．
polarfire上ではデフォルトでUbuntuがインストールされており，特にそこに不満はないので，このままUbuntuで開発していくつもりです．Ubuntu上でFPGAを制御しようとなると，適切にFPGA側のデザインを作った上で，そのデザインで決めたアドレスにアクセスし，そこに対して操作を行う形になります．が，繊細なメモリ空間に手を付けるわけなので，デザイン側，SW側ともにうまくいっていないと，アクセスした瞬間にストールします．デバッグログとかも出せないので，何がどう悪くて止まったのかの切り分けが非常に難しく，そこに苦戦している感じです．
UIO
そもそも組み込みLinuxに関してはずぶの素人のなのでUIOというものも今回初めて知りましたが，FPGA+SoCにおいてLinux(マイコン)側からFPGAにアクセス(ここでいうアクセスはGPIOの制御や，今回のようにデシリアライザして得たデータを取得するなど，とにかくFPGAに関する情報を得るあるいはFPGAの制御を行うありとあらゆる行為を指します)する場合，FPGAとマイコンで共有する物理メモリ空間にアクセスすることによって実現します．(メモリのアドレスに物理とか仮想とかあるのですが，正直自分も詳しくないのでここでは割愛します．)
そして，UIOというのはUser Space I/Oの略称のことで，この仕組みを使う事であらかじめ指定した物理メモリ空間に特段の権限等なしでアクセスすることができるようになります．
で，結論から言うとBVFを使いたい人は下記公式ページのデモ紹介から詳細なサンプルの説明を見ることができます．
できるのですが…2024年6月時点でBVFを購入されている方は，多分プリインストールされているLinuxをアップデートできません．UIOを使用するにはデバイスドライバが必要なのですが，そのデバイスドライバがインストールされていません．
というのも，この記事が追加されたの結構最近(2024/9~10月ごろなはず)で，その頃にFWが一度更新されています．もっと厳密に言うと更新というよりmpfs(polarfire SoCシリーズ)向けの最新FWでBVFが正式？に対応し，
それに伴ってmicrochipが出しているpolarfire SoC向けのlinux用のサンプルコードが使えるようになったのが大きいのではないかと思われます．半分以上予想みたいなものですが．
いずれにしても少なくともBVFが話題になりかけた直後に購入している人は対応しないとデモに沿って進めてもUIOデバイスが見えないのではないかと思います．
ちなみに次に述べるDMAとともに，この辺はまだ問題解決してません．これをやるとYoctoというのに触れなければならず，どうせそれで1記事になるやろという事で今までの分をとりあえず記事にしてるわけです．そういうからくりです．
DMAの処理
RISC-Vを選んだ弊害がここにきて出てきたのですが，DMA用に連続したメモリアドレスを確保してくれる便利なデバイスドライバがRISC-Vに現状未対応でした．ただ開発者が日本人，どころか奇跡の相互フォローだったのでちょっとお願いしてきました．ホント最近個人でモノづくりしててもSNSで協力してもらったり，アドバイスもらったりできるのは便利になったなあというのを実感します．
ちなみにikwzmさんがすごすぎて，この2日後にはRISC-Vでコンパイルが通る最新版が出てきましたが，当の私はせっかくの日曜日に熱を出してダウンするポンコツっぷりも相まって，先の項目でも述べた通り，この辺はまだ解決できておりません．
終わりに
今回は全体像をなんとなく改めて紹介したくらいで，見た目上あんまり進んでないように思うかもしれませんが，データを読み込むところまであと一歩というところに来つつあるかなと個人的には思っています．実は裏でADCの動確ほぼ取れてたりするのですが，実際データ拾ってきて画像化してみないとブログにするにはインパクトが足りないこともあり，書くに書けないジレンマがあるんですね～
というわけで，次回はそう遠くない内にlinuxイメージをビルドする話を書きたいと(今のところは)思っています．でもYoctoも沼深そうなんだよなあ…
コメント