2020.09.30

HDMIの信号をJTAGロジアナで見る

DigilentのDVI2RGBコアの出力をVideo In to AXI-4 StreamでAXI Streamに変換し、AXI Subset converterを入れて32bitにします。AXI Subset converterというのはSliceやconcatみたいなものなのでしょう。左側に8bitのゼロを詰めてくれるようですね。

Hdmicap0

こうして作ったブロックを2つ用意し、MITOUJTAGのJTAGロジックアナライザで見れるようにしました。

Hdmicap1

手近にあったノートPCのHDMI出力に基板をつなぎMITOUJTAGで見てみます。

下の図のような感じでAXI Streamらしき波形が見えています。

Hdmicap3

tvalidがHになっている期間を数えてみると1920クロック分ありました。そしてtuser(0)が'1'になってからtlastを数えると1080個あるので、tvalidがHSYNCの代わりになっていて、tuser(0)がVSYNCの代わりになっているのでしょう。

ただし、tuser(0)が'1'になってからの4ライン分はtvalidが39クロック分しかない短いラインが来ていました。そのあと、1080個の通常の画像ラインが来ています。最初の4ラインは何でしょうね?音声とかかもしれません。

Hdmicap2

それから、0x00A277という値が送られてきていますが、DigilentのDVI2RGBコアではRBGの順にならんでいるので、RGB=0,119,162という値になります。どんな色かというと、

00a277

昔懐かしい、Windows8のデスクトップの色ですね。

 

| | コメント (0)

2020.09.29

DigilentのDVI2RGBコアを使ってEyeSizeを測る

DigilentのHDMI/DVI受信コアを読んでみると、eyeSizeという信号を内部で作り出していることに気が付きました。

このコアはHDMIの信号をデコードするために、IDELAYのタップを少しずつ変えていって最適なところを探してくれるようなのですが、最適なタップ間の幅を測ることでeyeSizeを計測しているようです。この信号をコアの外に出して、MITOUJTAGのBLOGANAで見てみました。

Es1

下の波形のようにRGBそれぞれのeyeが開いている幅が数字で出ています。5bitなので0~31の範囲ですが、おそらくタップのビット数ですね。

Es2

1080pなら1.485Gbpsだから1bitの間隔は673ps。1タップは78psなので8ならば624ps。8が最大のはずです。Digilentのコアには各チャネルごとに位相を合わせる機能があるようなので、チャネル間の遅延はIDELAYで吸収できるのでしょう。

 

Cosmo-Kの2つのHDMI入力ポートで、2台のPCで、2種類のケーブルで試してみました。

Es3

まず、PCによってeyeのサイズが異なるがわかります。「このPCと相性が悪い」というのはあるのでしょう。

高級なケーブルよりも安く長いケーブルのほうが成績が良かったり、このあたりは一概にはなんとも言えませんが、HDMIの信号の品質をFPGAで測ることができそうです。

 

| | コメント (0)

2020.09.28

HDMI信号を見ることに成功

Cosmo-K DVIの論理合成が通るようになりました。

Hdmi2

何がなんだかよくわかりませんが、とても苦労しました。Vivadoが吐き出すエラーのほとんどはクロック関係だったような気がします。HDMIからデコードしたクロックと、高速シリアルデコード用のクロック、HDMI出力用のクロック、内蔵のMMCMで作ったクロック、JTAGロジアナのクロック・・非常にたくさんのクロックがあってリソースが競合していたようです。

HDMI受信の心臓部は下の図のようになっています。これはアルバイトの学生さんが2018年に作ってくれたデザインをベースにしています。DigilentのDVI2RGBコアでデコードし、v_vid_in_axis4に入れ、axis_subset_converterで32bit幅に拡張しているようです。

Hdmi3

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を使うようなデザインがよくないのかもしれません。

Cszdvi1

紆余曲折ありましたが、生のHDMI信号をMITOUJTAGのBLOGANA機能を使ってみることができました。

Hdmi1

1080pの信号を見てみたところ、HSYNCの周期は横2200ピクセル、VSYNCの周期は縦1125ラインでした。毎秒60回だとすると、2200x1125x60p=148500000となって、ピクセルクロックの周波数148.5MHzと一致します。

また、HSYNCは44clkの幅があって、VDEは192-2112clkの間まで出ていることがわかりました。

2018年にVivado 2017.2で論理合成していたときにはこの基板はHDMIの1080pの受信がうまくいかなかったのですが、今のデザインではうまく受信できているようです。ツールが変わったのが原因か、それともクロックの質が良くなったのが原因か。

 

| | コメント (0)

2020.09.27

Cosmo-K DVIのデザインをVivado 2019.2に移植

特電の製品にCosmo-K DVIというのがあります。

Cskdvi

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の出力は上か下しか駆動できない」というものです。へぇ~そうなの?

何とかエラーなく通るようになりましたが、

Cskdvi2

動かしていると、いきなりFPGAが壊れました。

HDMI 1080pとDDR3を1600MHzで動かしているので発熱が原因でしょうか。クロック入力のピンが壊れてしまいました。そのピンに外から信号を加えても固定値が強制的に出てきているようでびくともしない。バウンダリスキャンでも動かせない。

とほほ。そろそろ厄除けのお参りにいったほうがいいかもしれない。

 

| | コメント (0)

2020.09.26

AgilentのE4432Bが壊れたので分解した

長年使っていたAgilentのE4432Bが壊れました。もともと中古で30万円くらいで買って、いろんな回路の周波数特性を調べるのに重宝していたのですが・・・( ノД`)シクシク…

E4432b_1

突然、信号の出力が極端に弱くなってしまって40mVくらいしか振幅が出なくなりました。信号は出るのですが、振幅がとても低いうえになめらかに変化してくれないのです。ディジタル的な何かの線が切れたんじゃないかと思うのですが・・

開けて自分で直せないかなと思うのと、せっかくなので後学のために高額な機器を分解してみようと思い、やってみました。

まず、ケースを開けます。後ろにある4つの足と、側面の手持ちのバンド、底面にある足を外して、包んでいる胴体を抜きます。

E4432b_2

中からまたケースが出てきます。何やらスロットに挿すモジュールやコネクタの意味を図解で説明してくれていますね。

E4432b_3

では左側の大きな天板を外していきます。

E4432b_4

底面に見えるのはDSPが乗った基板。左にあるのは波形発生器っぽいボードです。

写真の下側にある金属製のモジュールから同軸ケーブルが何本かはえています。

↓の同軸ケーブルは、信号出力モジュールと背面パネルをつないでいます。

E4432b_5

下の写真のくねくねしたパイプは、金属パイプ製の同軸ケーブルです。出力信号であるRF(~3GHz)はすべてこの金属製同軸ケーブルになっています。

E4432b_6

壁面から出てきた信号が灰色のモジュールに入って、またパイプが出てきて左側のモジュールに入っていきます。おそらく変調器とRFパワーアンプじゃないかと思うのですが、よくわかりません。Made in USAと書かれています。マイコンとかどこの国でも作れるやつは中国製もありですが、やっぱり心臓部はアメリカ製ですね。とにかく、これは開けちゃいけない感が漂う風格のブラックボックスでした。

右側にある金属製の塊の部分は横から開くようになっていて、スロットに金属製のモジュールが刺さるようになっています。

E4432b_7

上から順番にOutput Board、Reference Board、Synthesizer Boardということなのですが、ご覧のような金属の塊のモジュールがささっていて、開けちゃいけない感じがするので中身は確認していません。

E4432b_8

 

高級計測器を分解してみてわかったのは、

  1. 外側の筐体が受けた衝撃は、内側の筐体には直接伝わらない(背面のフレームに伝わる)
  2. 背面のフレームが受けた衝撃も、内側の筐体に伝わらない(二重三重のフレーム構造)
  3. 重要なモジュールは金属ケースに入っている
  4. 基板は着脱式で、別の基板は直角に交わる
  5. 前面の操作パネルに与えた衝撃は、本体基板には直接伝わらない

という感じでした。

高級計測器が重いのは、二重三重のフレーム構造になっているからなのでしょう。基本的に鉄でできているので重いし、ノイズ対策の効果もあると思います。基板と基板が直角に交わるのは、メインテナンスが容易になるだけではなく、ノイズ対策の意味もあるのかもしれません。

 

| | コメント (0)

2020.09.24

BGAの実装不良の犯人はまさかのレジストだった

特電のCosmo-K DVIという基板があります。

1544234124_cskdvi_top

この基板、HDMIが2入力、2出力あって、基板裏面にMIPI CSIのコネクタがついているという「ステレオ画像処理FPGAボード」なのですが、2019年の1月に製造した8台のうち4台に不良が出てしまい、あまりのショックにそれ以来開発を止めてしまったボードです。

USBを通じたメモリテストをすると、このようにイメージに縦じまが出ます。

Grad

8台中4台にこのような縦じまが出るわけですが、さらに2台はDDR3メモリも初期化に失敗するという始末。

4台の不具合の内訳は

  • (A) DDR3メモリ不良 USB3.0のバスのどこかがショート
  • (B) DDR3メモリ不良 USB3.0のバスのどこかがショート
  • (C) USB3.0のバスのどこかがショート
  • (D) USB3.0のバスのどこかがショート

JTAGバウンダリスキャンを使って、ピン間のショートを調べてみると、AE5番端子を操作するとAF5も一緒に動くので、基板かはんだ付けのどちらかがショートしているな・・とわかるわけです。

Bscan

 

しかし、実際の基板をX線検査してもらっても、それらしきショートは見つからなかったのです。

20u1

ショート個所は全部同じで、バウンダリスキャンによれば以下の部分が怪しいという判定結果でした。

Err5_20200925114301 Err2_20200925114301

さて困った。基板か、はんだ付けか、それとも部品自体の不良か・・

基板屋さんに送り返してFPGAを外してもらったのですが、それでもUSBインタフェースのショートが直らなかったので、半ばあきらめかけていました。

 

1年半ぶりに基板を徹底的にデバッグをして、ようやく原因がわかりました。

FPGAが外された基板をよーく見てみると、

Usb

ピン間2本通したところのレジストが少しだけ削れているのです。上写真はUSBインタフェースチップの部分。

次の写真はFPGAからDDR3メモリへ行く部分。

Photo_20200925114501

ちょっとだけレジストが欠けて銀色になっているの、わかりますか?

設計したパターン的にはちゃんとデザインルールは守って設計しているのですが、ほんのわずかにレジストがずれたか薄かったかで剥けちゃったのかもしれません。

Photo_20200925114801

手元に残っていた生基板をテスターで調べてみると、一枚はレジストがはがれていて、もう一枚は正常でした。

なにはともあれ原因が判明してよかったです。

 

| | コメント (0)

2020.09.20

7次のチェビシェフフィルタを作成

万能フィルタ基板を使って7次のチェビシェフフィルタを作成しました。

リップル0.1dB、等リップル帯域60MHzで設計したLPFに85MHzくらいのところにノッチが入るようにコンデンサをいれたものです。

結構面倒くさそうな回路ですが、万能フィルタ基板を使えば簡単につくれます。

Chev7

7chev_sch

気になる特性ですが、

Chev7_1
(7次チェビシェフLPF ノッチ付き)

↑このように75MHzあたりで50dBダウンする特性が得られました。

 

同じ設計仕様で5次のものと比べてみると、

Chev5_1
(5次チェビシェフLPF ノッチ付き)

断然、キレがよくなっていますね。

ただ、シミュレーションでは透過域はまったくの平らなのですが、

Chev7_sim

実際には0~50MHzくらいの範囲でも周波数とともに若干(3~6dB)緩やかに下がっているのです。

この原因はよくわかりませんが、測定機器の出力インピーダンスが周波数とともに上昇して50Ω以上になっているのではないかと推測しています。

| | コメント (0)

2020.09.19

Artix-7のDDR3の読み出し速度はどのくらいか

前回の記事では、DDR3メモリを1066MHz(533MHz)で動かせば、毎秒900Mバイト程度の速度で書き込みができることを示しました。

それでは読み出しはどのくらいまで行くでしょうか?

同様に測ってみました。

下の図は256Mバイトの読み出しシーケンスの最初の部分です。AXI SRCコアから発行された2048バイトの読み出しのトランザクション12個が25.697usで完了しているのがわかります。

このことよりスタート時点の最初の速度は950Mバイト/秒くらい出ていそうです。

Axiddrrd1

次に256Mバイトの転送全体の波形を示します。

Axiddrrd2

256×1048576バイトを0.299秒で転送しているので、速度は897Mバイト/秒となります。

やはり、読み出しであっても900Mバイト/秒くらいの速度が出ることが確かめられました。DDR3メモリの速度は1066Mなので、読み出しでもバス帯域の84%を使えるようです。

 

| | コメント (0)

«Artix-7のDDR3メモリ書き込みの最高速度はどのくらいか?