そろそろpolarfire編と銘打ったシリーズを終わらせたい…どらびです．
前回まででセンサ基板とその信号を正しく受けるためのブレイクアウトボードの改修が完了し，残るはソフト側のみ(のはず…)というところまで来ています．あとは，
・SERDES→(interconnect)→DMAの流れをビットストリームで組んであげて，u-dma-bufを使ってlinux側から信号を受け取ることができるのか
のみがpolarfire編の最後の壁として立ちはだかっています．
まあこれが終わったらPCIe2レーン使えるか検証が待っていると言えば待っていますが…
なくても最悪カメラとして動作させられるものは作れるので，PCIe2レーンフルで使えるかはわからないにしても，2レーン分のフットプリントを持った自作polarfireボードを起こすシリーズがこのシリーズの後に続くはずです．
あ…MIPI-DSIでディスプレイ映せるか問題もありました．まだまだ先は遠いですね…
ディスプレイなしでも最悪カメラとして機能はさせられるので…そこまでいけばモチベもより上がってくるでしょう…あとNT東京なりMFTなりに出しに行ける状態には持って行けるはず…
ディスプレイなし，M.2SSDなしは実質「1枚しか撮影できないフィルムカメラ」状態ですが，そもそもフルスペックで撮影すると1枚の撮影に数分かかるようなカメラなので…支障はあるけどどっちみちやろ感はある…
そんな先の話はさておき，今回の進捗です．
前回の記事からあまり日が経ってないように見えるかもですが，前回の記事が5月くらいまでがほとんどな内容が下書きのまま塩漬けされていたのをちょっと最近の情報も盛り込んで投下したから，というのが理由であって，6月に引越しして，ネット環境の立ち上げだの部屋の整理だので8月頭くらいまで趣味出来なかったブランク期間を介したりしているので，前回記事からは(一部)時間経過している内容もあったりなかったりします．
- 概要編
- 仕様決定編
- 回路設計編
- 機構設計編
- 初期試作&大爆死編
- 試作第二弾
- polarfire編①
- polarfire編②
- polarfire編③
- polarfire編④
- polarfire編⑥
- polarfire編⑤
引越し後からの進捗
JTAGデバッガ購入
以前までの環境からの一番の変化としてJTAGデバッガを入手しました．
公式の方に観測されるとまずい気はするものの…本物ではなく中華のパチモンです…
でも普通に動いちゃうんですよね…これが…
最近のリバースエンジニアリングの技量には驚きですが，一層ずつレーザーで焼いてアートワーク完コピとかできちゃうっぽいです．ICもレーザーでマーカ消したりしてるとは思うのですが，その辺をどうやって見つけてるのかは自分は詳しくは知らないです．がなんかうまいことやれるんでしょうね．
というわけで，これを活用してFPGA内のリアルタイムでのレジスタ値等を読めるようになりました．
実は裏で数日接続に苦労する件があるのですが，ダイジェストで
- 評価ボードのJTAG部分のプルアップ抵抗etcが破損していた
- 中華JTAGデバッガのピン配のラベリングが(恐らく)反対向きに取り付けられており，間違ったピン配のまま延々と接続失敗してた
(※ちゃんと確認すればラベリングは判別できるので，私の理解力の問題かも)
(※結局ロジアナで全ピンの動き見たりしながら配線合わせ込んだら動いた)
そんなこんなはまあどうでもよいので，使えるようになってからの話ですが，コレやってみると(※当たり前ですが)かなり強力で，途中から動かなくなったのかなとか，interconnectを通過してくれなくなっている時に，どこの値がおかしくて躓いているのか，わりかし直接的に観測することができます．
DMA転送デバッグ続編
というわけで新たに手に入れた強力な武器を元にデバッグを進めていきます。
interconnectでデータが止まっている問題のチェック
前回までの進捗でADCから正しくデータが飛んで来る、というところは確認できていますので、データが流れてこない原因については、今回は本当に純粋にFPGAの論理回路側にあると断言できます。
という訳でsimでテストデータを流した場合にどこで止まっているかを確認しつつ、該当するIPのデータシート側とにらめっこして一つずつ間違いを見つけていきます。
また、実機でもテストデータを流す機能がCCDコントローラにあるので、simと実機の動作が一致しているかも確認します。
これまた基板の時と同様で、初っ端から本番を想定した論理回路を組んでいたので、テストデータが最後まで流れるように都度一部の論理を細工しつつ確認しました。結果…
- interconnectのルーティング設定で定義されてないTDESTのデータが来るとDECODE_ERRを吐いてお亡くなりになる挙動が判明。本番仕様ではルーティングのため、パラレルデータの上位5bitのフラグが0x01~0x03の時だけデータが流れるようにinterconnect側を設定しつつ、テストデータではそれが再現できなかったので適当にしていたため、不整合でデータが流れてくれなくなっていた。
(※TVALIDも整理する術がなかったのでこの時点ではhighに固定していた。これも悪さをしていて、立ち上がった最初の状態が有効データとして送られてしまう状況だったので、1つ目のデータから必ずDECODE_ERRが吐かれてしまう仕様になっていた) - 一旦TVALIDはhigh固定のまま、TDESTによるルーティングを一旦ゆるく設定し、TDESTに何が来てもとりあえずルーティングされるように設定した。
(一応、テストデータではTDESTが0x15か0x0aの2パターン来るので、それらが別のルートに行くようにTDEST設定しつつ、一番最初に来るゴミデータを3つ目のルートに飛ぶように設定したり、若干工夫した。) - DMAコントローラがsim上ではかなり下準備をしないと正常に動作しないため、一旦DMAコントローラのTREADYを無視してinterconnectのI0TREADYをhigh固定にした。
この2点の変更(※他にも細かい修正はあったかもですが…メインとしては…)で2段のinterconnectをとりあえず流れるようになりました。
DMAコントローラの割り込み設定
この状態で、2段目のinterconnectとDMAコントローラのREADYを本番仕様にして実機動作させると、1度だけ実機でもDMA転送が行われていることが確認できました！！！
ただ、DMA転送が行われたタイミングで割り込みが入るようにプログラムしていたはずなのにそちらは動作せず、また1度のみ転送が実行されて、その後はうんともすんとも言わない状況になっています。
さらに、送られてきたデータもテストデータとは違う結果に…(※後述。これはこうなるのわかってました)
ということで更に次のステップに進みます。
お次はDMA側のデータシートを再び読み込んで、結果
- 転送完了時の割り込みは設定をonにしないと動かない
という訳でとりあえずonにはしました。が、他にも絡んでくる要素がたくさんあるので、一旦他をクリアにして、ちゃんと本番環境でもデータが転送される状況を作ってから戻ってきます。
デシリアライザ後のパラレルデータの整理
さて、次はCCDコントローラの仕様に合わせこむ作業になります。
CCDコントローラは基本的に各画素のRGB値を一つずつ16bit+5bitのフラグを7bit×3レーンのLVDSでデータを送る仕様です。
この21bitの1クロックで伝送される情報を1パケットとしたとき、この1パケットの内容に時刻tのデータと時刻t-1のデータが混在しているという超謎仕様があります。
なので、LVDS信号をパラレルに変換したのち、そのデータの一部を論理回路で遅延させて、時刻tのデータを完成させた上でinterconnectに繋ぎこむ必要があります。
また、先に述べた通り、上位5bitは今送っているデータが何のデータになっているかを示すフラグになっていて、ここを活用して
- 必要なデータか否か(RGBの有効なデータは0x01~0x03なので、それ以外は捨てたい⇒TVALIDの制御に使いたい)
- RGBごとにデータを振り分けるルーティング(TDEST)
- DMA転送をまとめて実施するためのTLAST信号の制御
を行うので、TLAST、TVALID信号も狙い通りの動きにするために論理回路を組む必要があります。
(TDESTはフラグをそのまま突っ込むだけなので追加の論理回路は不要)
というわけで組み込みました．ほぼほぼD-FFで構成されてます．(小さい白抜きの四角がすべてD-FF)
DMA CONTROLLER IP が使えない説浮上
上記までの進捗で，DMAコントローラには必要な情報がほぼ入るようになり，それぞれの信号もある程度のレベルではありますがロジアナやsimで確認済の状態となりました．
それでも依然としてCOREAXI4DMACONTROLLERからTREADY信号が発行されず，interconnectからのデータを受け付けてくれませんでした．厳密に言うとそのあとも1度だけDMA転送されたのですが，あまりにも再現性が悪く，考え点く限り色々試しましたが効果なしでした．
お手上げだったのでmicrochipのフォーラムを探したらこんな記事が…
Microchip PolarFire SoC Axi4Stream to Memory
というわけでここにきて大胆な決断ではありますが，COREAXI4DMACONTROLLERを使うのは諦めます．(※ここまで来て大胆な…とは書きましたが，DMA転送のデバッグができるようになったの本当にここ数か月の話なので，その結果今回のユースケースでは使えなさそうと判断するのはある意味妥当な判断の範疇だと思っています．)
で，色々調べなおしたらありました…いい感じのが…
Video DMA IP
当初予定してたIPが使えなさそうという事で，代わりを探したところ，polarfire SoCが載った別の表かボードであるpolarfire soc video kitのサンプルで「IMX334というイメージセンサから画像を取得する」というドンピシャなサンプルがあり，
その中で使われているのがVideo DMA IPというものでした．
ざっくり読んだ感じ，こちらの方が低レベルなIPで，転送に対する柔軟性(ex.TDESTによって転送先アドレスを振り分ける機能etc…)は劣るものの，シンプルな構成のようです．
というわけで早速組み込んで…雑に一旦動確してみよ…
え…
出来るんかい…
というわけでDMA転送のハードルもとりあえず一旦クリアできたのでしたｗ
とは言ってもまだ完全に狙い通り，というわけではなく，ノイズなのかなんなのか，意図していないデータも来ているので，引き続きデバッグはします．
ただ，ここ数回の記事にわたって困っていたADC→DMA転送までの道のりが大分見えてきたのと，文量が結構多くなってしまったので今回はこの辺で区切ります．
終わりに
冒頭でそろそろこのシリーズ終わりにしたいと書きましたが，ちょっと光明は射してきている感があります．
ファーストライトまでの道のりとしては
- 謎のカーネルパニックを阻止する(多分DMAで何かのリソースが埋まってしまってほかの処理できてないのが問題っぽいので，FIFOのdepth増やすなりの対応が必要っぽい．)
- 入ってくるデータが完全には想定通りじゃないのでデバッグ
- 1列の画像を正しく取得し，完了時に割り込みを受けられるようにする
- モータ制御(ブレイクアウトボードにドライバ挿せるように準備済．動確は必要．)
- 得られたバイナリをraw()れたバイナリをtiffあたりで保存してPCから表示可能な状態にする
あたりが主かな？まだ結構道のりありますが，後半はちらっと予習しているので，最初の3つがクリアできれば最低限は何とかなりそうかなと思っています．
コメント