2021.05.26

MIPI CSI-2のRXでうまくいかない

Vivado 2020.2をインストールしてMIPI CSI-2のカメラ受信をしようとしているのですが、なかなかうまくいきません。

XILINXが提供しているコアにはMIPI CSI-2 RX Subsystemというのと、MIPI D-PHYというものの2つがあります。MIPI D-PHYはPHYのみですが、MIPI CSI-2 RX SubsystemはPHYの後ろにタイミング関係やRAW10などのパターンの変換などが付いていてVideoという例のバスが出てくる高度なものになっています。

MIPI CSI-2 RX Subsystemは、MIPI D-PHYにデコーダ回路を付けたものらしいので、まずは高レベルのRX Subsystemで試してみました。

これらのコアを使用して配置配線をするとBitGenやPlaterでエラーが出てしまいます。MIPIのコア自体にはIOSTANDARDの設定がされていないようなので、XDCファイルに

set_property IOSTANDARD LVDS_25 [get_ports cam_clkp_ip]
set_property IOSTANDARD LVDS_25 [get_ports cam_clkn_ip]
set_property IOSTANDARD LVDS_25 [get_ports {cam_dp_ip[0]}]
set_property IOSTANDARD LVDS_25 [get_ports {cam_dn_ip[0]}]
set_property IOSTANDARD LVDS_25 [get_ports {cam_dp_ip[1]}]
set_property IOSTANDARD LVDS_25 [get_ports {cam_dn_ip[1]}]

のように書いてIO規格を指定しなければなりませんでした。

データを受信するI/Oの規格はLVDSなのですが、IO電圧は3.3Vなので、このままだとエラーが出てしまいます。LVDS_25は受信だけなら3.3VのIOでもできるのですが、終端抵抗(DIFF_TERM)が入っているとIO電源電圧は2.5V要求されます。そこで、

set_property DIFF_TERM false [get_ports cam_clkp_ip]
set_property DIFF_TERM false [get_ports cam_clkn_ip]
set_property DIFF_TERM false [get_ports {cam_dp_ip[0]}]
set_property DIFF_TERM false [get_ports {cam_dn_ip[0]}]
set_property DIFF_TERM false [get_ports {cam_dp_ip[1]}]
set_property DIFF_TERM false [get_ports {cam_dn_ip[1]}]

のようにしてDIFF_TERMを無効にして、そのかわりに基板上にチップ抵抗を実装して

 

さて、MIPI CSI-2 RX Subsystemから出てくる信号をロジアナで観測したものの、すべての信号が全く出てきません。

Mipi1

唯一変化があったのは、rxbyteclkhsと、system_rst_outのみです。

rxbyteclkhsはだいたい69MHzくらいなのですがバースト的に動作しています。つまり、動いているときと止まっているときがあります。連続して送られてくるわけではないので、これをPLLの元にすることはできないでしょう。

 

信号が出てこない原因として考えられるのは2つあって、一つはMIPIのLPのほうをつないでいないということ。もう一つは基板の設計を間違えていてMIPIの差動信号のPとNが逆になっていることです。どうやらXILINXのコアにはレーンリバーサルの機能はないようです。

 

高度なRX Subsystemがだめなら低レベルのD-PHYだ、と思って、D-PHYをつないで全信号を内蔵ロジアナで見てみたのですが、

Mipi2

これもダメでした。

Mipi3

全信号がうんともすんとも言いません。

IPの設定はこんな感じです。

Mipi4

さて、次の手はどうしようかと悩むところです。

Trenz社製のMIPI RXコアを使うか、配線のPとNを入れ替えてみるか、どちらかですね。

 

| | コメント (0)

2021.05.25

Trenz社製品の情報をデータベースに入れて在庫と納期を検索できるようにした

TrenzElectronic社のWebショップの在庫を検索して、現在の在庫数、おおよその納期、世代交代前の型番、後継機種の型番を一括で表示するプログラムを作りました。

Trenz社のWebサイトは重いのでひとつひとつのページを見るだけで時間がかかるのですが、実は、特電では3年以上前からTrenz社の製品情報を毎日自動的にクロールして、在庫数や納期などの情報を取得して、独自のデータベースに入れていました。

このデータベースをもとに高速に検索して、現在の在庫数などを表示できるようにしました。

例えば、TE0712という製品の在庫情報が知りたいというときには、zaikocheck.phpというプログラムを走らせると、

Trenzsearch1

というふうに、「TE0712」という文字列を含む製品すべての在庫と、予定納期、それから製品の新旧型番が一瞬でわかるようになりました。

Gigazee 「TE0720」という大ベストセラーな産業用FPGAモジュールのファミリがあるのですが、これは供給が追い付いていないので、現時点で在庫が全くありません。ですが、TE0720で検索すると、

Trenzsearch2

と、次回製造のロットで納期が早いものは、TE0720-03-2IFC3、TE0720-03-62I33FL、TE0720-03-62I33FAあたりだなということが分かります。

 

また、TrenzElectronic社のFPGAボード製品は、最近の改版によって名前が不規則に変化しています。

例えば、TE0720-03-2IFC3はTE0720-03-62I33FLに変わったのですが、旧製品の型番に含まれる-03は基板のリビジョンで、2IFC3は2Iがスピードと温度グレード、C3はコネクタが短いもの、という意味です。しかし、62I33FLになって、さっぱり意味が分からなくなりました。6はおそらくFPGAのサイズ、2Iが温度とスピード、33Fは不明。

型番の意味はわからないのですが、データベースを検索して製品型番のチェーンを自動的に調べるツールを作りました。TE0720についての型番の変化を調べてみると、

TE0720-03-14S-1C     => TE0720-03-31C33FA
TE0720-03-1CF => TE0720-03-1CFA => TE0720-03-61C33FA
TE0720-03-1CF-S => TE0720-03-1CFA-S => TE0720-03-61C33FAS
TE0720-02-1CR => TE0720-03-1CR => TE0720-03-61C530A
TE0720-02-1QF => TE0720-03-1QF => TE0720-03-61Q33FA
TE0720-03-1QFA => TE0720-03-61Q33FA
TE0720-02-1QF => TE0720-03-1QFL => TE0720-03-61Q33FL
TE0720-02-2IF => TE0720-03-2IF => TE0720-03-62I33FA
TE0720-03-2IFA => TE0720-03-62I33FA
TE0720-02-2IFC3 => TE0720-03-2IFC3 => TE0720-03-62I33FL
TE0720-03-2IFC8 => TE0720-03-62I12GA => TE0720-03-62I33GA
TE0720-03-L1IF => TE0720-03-64I63FA
TE0720-02-L1IF => TE0720-03-L1IF => TE0720-03-64I63FA

と、なりました。

このツールはWebサイトに組み込んだので、Trenz製品の一覧と、型番の変化を知りたい場合は

trenz.jp/chain.php

のページを見てみてください。

| | コメント (0)

2021.05.24

Trenz社の全FPGAボード製品のデータを掲載しました

特殊電子回路ではドイツTrenzElectronic社の代理店を行っていて、日本語での製品紹介サイトを作成しています。

Trenz社では2020年ごろからTE07xxおよびTE08xx製品のアップグレードが始まって、TE0720-03-61C33FAなど、新しい型番の製品への移行が始まりました。

しかし、これらの新しい型番の製品の登録が遅れていてたため、日本語サイト内に製品情報がない状態が続いておりましたが、本日すべての型番の登録を行い、当サイト内で製品情報を参照することができるようになりました。

大ベストセラーであるGigazeeファミリの製品情報はもちろん完全に登録しました。

Te07200361c33fa

 

製品情報を見てみると、いつのまにかRFSoCの新製品や

Rfsoc

CRという新しいモータコントローラのシリーズや、

Cr00140

この時期に製品がものすごく増えています。

全部で450アイテムくらいありそうです。すごい開発力です。

 

| | コメント (0)

2021.05.23

XILINXのPCIe 7x 1.9コアでクラッシュする

2016年ごろに作ったPCI ExperssのボードのFPGAのデザインが、SuperMicroというメーカーのマザーボードを使った特定のPCでクラッシュするという現象がお客様から報告されました。

 

この状況を再現するため、特電の倉庫にSuperMicroのマザーを積んだデスクトップPCを取りに行って、CERN CentOS 7という謎ディストリビューションのLinuxをインストールし(インストール中にいろいろダウンロードするので1日以上かかった)たりしていました。

 

調べてみると、BAR0などのメモリ空間にアクセスしつつ、別のシェルでlspciを実行するとハングアップするという感じでした。

落ちる前にはBARからの読み出しでFFFFFFFFが返って来るので、感触としてはBARにアクセスするトランザクションがcompletionを返す前にコンフィグリクエストが来ると、どちらかのcompletionを忘れてしまうんじゃないかと思える挙動です。

 

使っているXILINXIPコアは2016年ごろのpcie 7x 1.9)です。当時のツールはISE14.7かVivado 2016かという選択でしたが、Vivado 2016は使う気にならなかったので、ISEを使っていました。

Ise

そのため、ISE 14.7に入っていたpcie 7x 1.9コアを使っていたのですが、pcie 7x 1.9はPCI Expressのトランザクション層のほぼ生のパケットが出てくるので、PCI Expressをしばらく触っていないと信号の意味を忘れてしまいます。ISEなので膨大な量の信号がテキストベースでインタフェースされているので、どこがどうつながっているのかを把握するだけでも一苦労です。

 

そう考えるとVivadoってすごいですね。配線がどこがどうつながっているか視覚的にわかります。それになんといっても、

・・・
-- Management Interface
cfg_mgmt_di : in std_logic_vector (31 downto 0);
cfg_mgmt_byte_en : in std_logic_vector (3 downto 0);
cfg_mgmt_dwaddr : in std_logic_vector (9 downto 0);
cfg_mgmt_wr_en : in std_logic;
cfg_mgmt_rd_en : in std_logic;
cfg_mgmt_wr_readonly : in std_logic;
-- Error Reporting Interface
cfg_err_ecrc : in std_logic;
cfg_err_ur : in std_logic;
cfg_err_cpl_timeout : in std_logic;
cfg_err_cpl_unexpect : in std_logic;
cfg_err_cpl_abort : in std_logic;
cfg_err_posted : in std_logic;
・・・ 

みたいな100個以上ある謎の信号を扱わなくていいのですから。

Vivado 2019.2に入っている比較的新しいコア(XDMA 4.1)Vivado 2019.2で作ったサンプルデザインで試したところ、全くハングアップしなくなりました。

Xdma

 

なお、XDMA 4.1は中心にpcie 7x 3.3が入っていて、AXIラッパとDMA回路が入ったものです。

pcie 7x 1.9コア が悪いのか、pcie 7xの周辺回路が悪いのかわかりません。pcie 7xの入出力信号を追いかけるのはとても時間がかかる作業となるので原因究明は行いません。まぁ、おそらく未処理のMemRdコンプリーションとCfgRdが重なるとバグるのでしょう。

 

とにかく、新しいVivadoで再設計するのが最も近道のようです。

 

| | コメント (0)

2021.05.19

RasPi Camera V2とFPGAをつないで何らかの信号が出ることを確認

Raspberry Pi Camera V2 (imx219) と特電Artix-7ボードを接続し、I2Cでカメラレジスタを設定してみました。

Raspicam3

I2Cのシーケンスは、Trenz社のZynqberryにおけるRasPiカメラコントロールプログラムrpicamに含まれているsensor_config.hのI2Cシーケンスから調べて、ステートマシンで作ったI2Cコントローラから送り出しています。

Raspicam2

 

すべてのI2C書き込みを終えると、MIPI CSIから何か信号が出てくることが確認できました。

Raspicam1

MITOUJTAGのバウンダリスキャンでI/Oの端子の信号を見ているので、FPGAの中にはロジアナのコアなどを埋め込まなくてもすぐに見られるのがとても楽です。手をかざしてみたりすると密度が少し変化するのが見えます。

| | コメント (0)

2021.05.17

Raspi CameraのI2Cから読み出し

RasPiカメラV2をFPGAで扱うため、まずはI2CのコントロールロジックをVHDLで開発しています。

どうせならちゃんとしたコアを作ろうと思い、NACKリトライまで付けています。

3層のステートマシンが階層間でREQやACKを渡して、精巧な歯車のように連携して動作するコアです。

一番最下層のステートマシン「state_l」は、Start ConditionやStop Condition、Tx、Rxなどの処理を行います。

中間のステートマシン「state_m」は、state_lに指示を出してReadやWriteといったシーケンスを行います。

上位のステートマシン「state_h」は、書き込みたいアドレスとデータのシーケンスをROMから取ってきてstate_mに指示を出します。

このくらいの規模の回路だとHLSやソフトウェアを使うよりRTLの方が楽ですね。

まず、シミュレーションでちゃんと意図したように動いているのを確認します。

I2c_sim

 

実機でやってみると、何かおかしい。

I2CのReadのときにはStart→Devアドレス送信→サブアドレス送信→Start→Devアドレス送信→受信→Stopというのを行うのですが、FPGAが受信するときにNACKで返さないとI2CのターゲットがStopを受け付けずに次のを送ってくるなどして少しハマりました。

無事、RasPiカメラV2のI2CからのACKが確認できて、MODEL_IDが0x02 0x19と正しく読めるようになりました。

Raspicam4

ターゲットから返って来る波形を目でみて確認しているのですが、I2Cのクロックを100Hzくらいまで落とせば、ILAとか入れなくてもMITOUJTAGのバウンダリスキャンでI/Oの波形が見えます。

デバッグ回路をわざわざ入れる必要がなく、すぐに確認できるのが便利です。

| | コメント (0)

2021.05.14

Artix-7ボード用のHDMI&MIPI拡張基板を動かす

特電Artix-7ボード用に作ったHDMI&MIPI拡張基板というのがあります。

Np10881

数年前に開発した基板なのですが、FPGAのサンプルデザインを用意していなかったので、この機会にうごかしつつサンプルデザインを整備しようと思いました。

このようにArtix-7ボードとぴったり重なって、HDMIの入出力や、MIPI CSIカメラをつなげるこことができるというボードです。

Np10882

昔作ったKintex-7用のHDMI出力回路をもとにArtix-7用のHDMI出力を作ろうとしていたのですが、

Hdmiout1

XILINX IPのVideo Outがunderflowを起こして信号が出てきません。

Hdmiout2

これは帯域が足りない場合です。

DDR3の内容をHDMIに表示するような場合、DDR3のMIGから出てくるクロックをベースにAXIを動かしますが、クロック400MHz(DDR800)で動かした場合、デフォルトの4:1の設定ならばui_clkは100MHzで出てきます。

HDMI 1080pは148.5MHzで32bit(xRGB)のバス帯域が必要なので、VDMAの出力のAXI Streamが100MHz 32biのバスだと足りないのです。なので、ui_clkの設定を2:1にして200MHzで出すようにします。

XILINXのVideo IPはわかりにくいのですが、何度もハマるとだんだんコツがわかってきます。

出来上がった回路はこのような感じになりました。

Hdmiout3

USB3.0を通じてDDR3メモリに書き込んだデータをHDMIから出力できるようになりました。

Np10883

| | コメント (0)

2021.05.11

14bit ADCのノイズのヒストグラム

ADCの無信号時のヒストグラム表示時に、標準偏差から求めたガウシアン曲線を同時に表示できるようにしました。

14bitのADCの生データは、12bitの場合よりも大きくなります。

Noise_14bit

このヒストグラムを取ってみると、だいたい±2~3本くらいかなという感じになります。

Hist14bit

リアルタイムに平均と標準偏差を計算し、滑らかなグラフを同時に表示できるようにしてみました。

Hist14bit_2

ノイズのヒストグラムはだいたい正規分布になっているのですが、少し左に寄ったり右に寄ったりするのは、ADCのINLやDNLというやつなのでしょう。出やすい値、出にくい値というのがあるのです。

標準偏差は1.99~2.4LSBと幅があるのですが、なぜでしょうね。

今回のADCは14bitなので1LSB=61μVです。よってADCの計測した値の誤差はチャネルによっても異なりますが、間を取って2.2LSBとすればだいたい±0.13mVといえます。

なんと!

12bitのADCの場合も誤差は0.13mVだったので、ビット数が増えても誤差は変わっていないのです。

 

| | コメント (0)

«高速ADCのヒストグラムと標準偏差