開発日記2020年9月
HDMIの信号をJTAGロジアナで見る
2020.09.30
DigilentのDVI2RGBコアの出力をVideo In to AXI-4 StreamでAXI Streamに変換し、AXI Subset converterを入れて32bitにします。AXI Subset converterというのはSliceやconcatみたいなものなのでしょう。左側に8bitのゼロを詰めてくれるようですね。
こうして作ったブロックを2つ用意し、MITOUJTAGのJTAGロジックアナライザで見れるようにしました。
手近にあったノートPCのHDMI出力に基板をつなぎMITOUJTAGで見てみます。
下の図のような感じでAXI Streamらしき波形が見えています。
tvalidがHになっている期間を数えてみると1920クロック分ありました。そしてtuser(0)が'1'になってからtlastを数えると1080個あるので、tvalidがHSYNCの代わりになっていて、tuser(0)がVSYNCの代わりになっているのでしょう。
ただし、tuser(0)が'1'になってからの4ライン分はtvalidが39クロック分しかない短いラインが来ていました。そのあと、1080個の通常の画像ラインが来ています。最初の4ラインは何でしょうね？音声とかかもしれません。
それから、0x00A277という値が送られてきていますが、DigilentのDVI2RGBコアではRBGの順にならんでいるので、RGB=0,119,162という値になります。どんな色かというと、
昔懐かしい、Windows8のデスクトップの色ですね。
DigilentのDVI2RGBコアを使ってEyeSizeを測る
2020.09.29
DigilentのHDMI/DVI受信コアを読んでみると、eyeSizeという信号を内部で作り出していることに気が付きました。
このコアはHDMIの信号をデコードするために、IDELAYのタップを少しずつ変えていって最適なところを探してくれるようなのですが、最適なタップ間の幅を測ることでeyeSizeを計測しているようです。この信号をコアの外に出して、MITOUJTAGのBLOGANAで見てみました。
下の波形のようにRGBそれぞれのeyeが開いている幅が数字で出ています。5bitなので0～31の範囲ですが、おそらくタップのビット数ですね。
1080pなら1.485Gbpsだから1bitの間隔は673ps。1タップは78psなので8ならば624ps。8が最大のはずです。Digilentのコアには各チャネルごとに位相を合わせる機能があるようなので、チャネル間の遅延はIDELAYで吸収できるのでしょう。
Cosmo-Kの2つのHDMI入力ポートで、2台のPCで、2種類のケーブルで試してみました。
まず、PCによってeyeのサイズが異なるがわかります。「このPCと相性が悪い」というのはあるのでしょう。
高級なケーブルよりも安く長いケーブルのほうが成績が良かったり、このあたりは一概にはなんとも言えませんが、HDMIの信号の品質をFPGAで測ることができそうです。
HDMI信号を見ることに成功
2020.09.28
Cosmo-K DVIの論理合成が通るようになりました。
何がなんだかよくわかりませんが、とても苦労しました。Vivadoが吐き出すエラーのほとんどはクロック関係だったような気がします。HDMIからデコードしたクロックと、高速シリアルデコード用のクロック、HDMI出力用のクロック、内蔵のMMCMで作ったクロック、JTAGロジアナのクロック・・非常にたくさんのクロックがあってリソースが競合していたようです。
HDMI受信の心臓部は下の図のようになっています。これはアルバイトの学生さんが2018年に作ってくれたデザインをベースにしています。DigilentのDVI2RGBコアでデコードし、v_vid_in_axis4に入れ、axis_subset_converterで32bit幅に拡張しているようです。
AXISになるまえのPixelClockドメインの信号をJTAGロジックアナライザで見てみたいと思い、HDMIコアが出す波形をBLOGANA(MITOUJTAGに付属のJTAGロジックアナライザ)を入れただけのモジュール「rgb_blogana」を作って通すと、なぜかクロックがらみのエラーが出ます。
[Place 30-120] Sub-optimal placement for a BUFG-BUFG cascade pair. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule. < set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets hdmi_repeater_i/clk_wiz_3/inst/clk_out1] >
こんな感じのエラーがたくさんでます。BUFG-BUFGの接続に何の問題があるのかわかりませんが、CLOCK_DEDICATED_ROUTE FALSEを設定すればよいようです。
MMCMが局在しているのかなと思い、MMCMをPLLに変更したりだ適当にやっていたらちゃんとビルドが通るようになりました。一か所に集中してBUFGを使うようなデザインがよくないのかもしれません。
紆余曲折ありましたが、生のHDMI信号をMITOUJTAGのBLOGANA機能を使ってみることができました。
1080pの信号を見てみたところ、HSYNCの周期は横2200ピクセル、VSYNCの周期は縦1125ラインでした。毎秒60回だとすると、2200x1125x60p=148500000となって、ピクセルクロックの周波数148.5MHzと一致します。
また、HSYNCは44clkの幅があって、VDEは192-2112clkの間まで出ていることがわかりました。
2018年にVivado 2017.2で論理合成していたときにはこの基板はHDMIの1080pの受信がうまくいかなかったのですが、今のデザインではうまく受信できているようです。ツールが変わったのが原因か、それともクロックの質が良くなったのが原因か。
Cosmo-K DVIのデザインをVivado 2019.2に移植
2020.09.27
特電の製品にCosmo-K DVIというのがあります。
HDMI 2入力、HDMI 2出力なFPGAボードなのですが、2018年に作った8台で特性が悪く、1080pの信号を受信できなかったので原因を調べることにしました。
まずは、当時Vivado2017.2で作ったプロジェクトをVivado2019.2で開こうとしたら、アップデートはできたもののclk_wizなどのIPが変わっていて、配線がぶちぶち切れてしまっていました。
そもそも、2017.2→2017.3へのアップグレードもできない。これはclk_wizのClock Souceの設定で、Single not Clock Capable Pinという設定が2017.3からなくなってしまったことが原因でした。
2017.3、2017.4・・と順番にアップデートしていって2018.3→2019.3で再びWarning。axi subser converterで何らかのパラメータがどうのというエラーが出ます。また、Video Timing Control(v_tc)からいくつかの解像度がサポートが外されてしまったようで、1280pという解像度が使えなくなっています。
Vivado 2017.2では動いていたデザインが、2019.2ではとにかくエラーが出まくります。
[Place 30-126] Unroutable Placement! A BUFIO can only drive loads in the same IO bank. The following BUFIO clock loads are placed too far from the BUFIO to be routable. hdmi_repeater_i/hdmi_out_0/rgb2dvi_0/U0/ClockGenInternal.ClockGenX/GenMMCM.SerialClkBuffer (BUFIO.O) is provisionally placed by clockplacer on BUFIO_X0Y15 hdmi_repeater_i/hdmi_out_0/rgb2dvi_0/U0/DataEncoders[2].DataSerializer/SerializerMaster (OSERDESE2.CLK) is locked to OLOGIC_X0Y202 hdmi_repeater_i/hdmi_out_0/rgb2dvi_0/U0/DataEncoders[2].DataSerializer/SerializerSlave (OSERDESE2.CLK) is locked to OLOGIC_X0Y201 hdmi_repeater_i/hdmi_out_0/rgb2dvi_0/U0/ClockSerializer/SerializerMaster (OSERDESE2.CLK) is locked to OLOGIC_X0Y212 hdmi_repeater_i/hdmi_out_0/rgb2dvi_0/U0/ClockSerializer/SerializerSlave (OSERDESE2.CLK) is locked to OLOGIC_X0Y211 hdmi_repeater_i/hdmi_out_0/rgb2dvi_0/U0/DataEncoders[0].DataSerializer/SerializerMaster (OSERDESE2.CLK) is locked to OLOGIC_X0Y204 hdmi_repeater_i/hdmi_out_0/rgb2dvi_0/U0/DataEncoders[0].DataSerializer/SerializerSlave (OSERDESE2.CLK) is locked to OLOGIC_X0Y203 hdmi_repeater_i/hdmi_out_0/rgb2dvi_0/U0/DataEncoders[1].DataSerializer/SerializerMaster (OSERDESE2.CLK) is locked to OLOGIC_X0Y208 hdmi_repeater_i/hdmi_out_0/rgb2dvi_0/U0/DataEncoders[1].DataSerializer/SerializerSlave (OSERDESE2.CLK) is locked to OLOGIC_X0Y207
こんな感じのエラーが多いですね。クロックリソースに詳しくならないと対処法が理解できません。エラーメッセージにはCLOCK_DEDICATED_ROUTEを付けろと警告がいっぱい出てきます。中でも理解しがたいのは「MMCMの出力は上か下しか駆動できない」というものです。へぇ～そうなの？
何とかエラーなく通るようになりましたが、
動かしていると、いきなりFPGAが壊れました。
HDMI 1080pとDDR3を1600MHzで動かしているので発熱が原因でしょうか。クロック入力のピンが壊れてしまいました。そのピンに外から信号を加えても固定値が強制的に出てきているようでびくともしない。バウンダリスキャンでも動かせない。
とほほ。そろそろ厄除けのお参りにいったほうがいいかもしれない。
BGAの実装不良の犯人はまさかのレジストだった
2020.09.24
特電のCosmo-K DVIという基板があります。
この基板、HDMIが2入力、2出力あって、基板裏面にMIPI CSIのコネクタがついているという「ステレオ画像処理FPGAボード」なのですが、2019年の1月に製造した8台のうち4台に不良が出てしまい、あまりのショックにそれ以来開発を止めてしまったボードです。
USBを通じたメモリテストをすると、このようにイメージに縦じまが出ます。
8台中4台にこのような縦じまが出るわけですが、さらに2台はDDR3メモリも初期化に失敗するという始末。
4台の不具合の内訳は
- (A) DDR3メモリ不良 USB3.0のバスのどこかがショート
- (B) DDR3メモリ不良 USB3.0のバスのどこかがショート
- (C) USB3.0のバスのどこかがショート
- (D) USB3.0のバスのどこかがショート
JTAGバウンダリスキャンを使って、ピン間のショートを調べてみると、AE5番端子を操作するとAF5も一緒に動くので、基板かはんだ付けのどちらかがショートしているな・・とわかるわけです。
しかし、実際の基板をX線検査してもらっても、それらしきショートは見つからなかったのです。
ショート個所は全部同じで、バウンダリスキャンによれば以下の部分が怪しいという判定結果でした。
さて困った。基板か、はんだ付けか、それとも部品自体の不良か・・
基板屋さんに送り返してFPGAを外してもらったのですが、それでもUSBインタフェースのショートが直らなかったので、半ばあきらめかけていました。
1年半ぶりに基板を徹底的にデバッグをして、ようやく原因がわかりました。
FPGAが外された基板をよーく見てみると、
ピン間2本通したところのレジストが少しだけ削れているのです。上写真はUSBインタフェースチップの部分。
次の写真はFPGAからDDR3メモリへ行く部分。
ちょっとだけレジストが欠けて銀色になっているの、わかりますか？
設計したパターン的にはちゃんとデザインルールは守って設計しているのですが、ほんのわずかにレジストがずれたか薄かったかで剥けちゃったのかもしれません。
手元に残っていた生基板をテスターで調べてみると、一枚はレジストがはがれていて、もう一枚は正常でした。
なにはともあれ原因が判明してよかったです。