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

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を測る

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信号を見ることに成功

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に移植

特電の製品に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で動かしているので発熱が原因でしょうか。クロック入力のピンが壊れてしまいました。そのピンに外から信号を加えても固定値が強制的に出てきているようでびくともしない。バウンダリスキャンでも動かせない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

という感じでした。

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

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

特電の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メモリへ行く部分。

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

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

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

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

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

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

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

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

気になる特性ですが、

（7次チェビシェフLPF ノッチ付き）

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

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

（5次チェビシェフLPF ノッチ付き）

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

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

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

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

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

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

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

同様に測ってみました。

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

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

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

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

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

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

Artix-7を使用したシステムでは、DDR3メモリの最高書き込み速度はどのくらいまでいけるのでしょうか？

奥にあるのはデータロガーなどを作りたい場合、毎秒100MHzでサンプリングしたデータを8バイト分並列に書き込めるのか、それとも8chなら100MHzは超えられないのかという深淵なテーマです。

もちろんDDR3メモリは800MHzで動作させることはできますが、オーバーヘッドがあるので当然ながら800Mバイト/秒での書き込みはできないでしょう。

逆に、800Mバイト/秒での書き込みを実現するにはDDR3メモリのクロックはどのくらいあればよいのでしょうか。

この問題を特電Artix-7ボード(スピードグレード3)を使って検証してみました。このボードはArtix-7とDDR3メモリのほか、USB3.0からもDDR3にアクセスできるので、このような検証には便利です。

作ったシステムのBlock Designを下の図に示します。

オレンジ色の部分が今回の検証に使われているデータのパスで、右から順にMIG、AXI Interconnect、AXIソース(自作IP)が並んでいます。

MIGの設定ではクロック(DDR3メモリのクロック)を1875psにして533MHzのクロックを与えます。DDRなのでデータレートは1066Mになります。

ただし、MIGに与える入力クロックは400MHzにします。（この設定は毎回書き換わってしまう）

AXIソースというのは自作のIPコアで、任意のアドレスから、任意の長さの書き込みまたは読み出しトランザクションを発生させるコアです。最高速度でデータを出してくれます。

実際の波形を下の図に示します。

1回のトランザクションは256バースト(2048バイト)ですが2.05μ秒で完了しているので990Mバイト/sほど出ている計算になります。

AXIのインタコネクトやMIGのいたるところにFIFOが入っているので、瞬間最大風速的な速度は徐々に落ちていくと思われますが、最初の12トランザクションの平均速度は965Mバイト/秒でした。

DDRメモリにもレイテンシがあるし、AXIにもいろいろなハンドシェイクがあるので、数十サイクル分のオーバーヘッドはありそうです。一応、トランザクションが終わってLASTを送ってからBVALIDが返ってきたのを待って、次のトランザクションを始めているので、こういったオーバーヘッドは加味されていると思います。

瞬間的には960Mバイト/秒出ることはわかりましたが、あくまでも最初の12個のトランクザクションです。数百Mバイトの長いデータを書き込んだ場合はどうなるでしょうか？

FPGAの中に入れるロジアナは、BlockRAMの容量に制限されるのでミリ秒単位での計測はできません。

そこで、MITOUJTAGというツールを使って、JTAGバウンダリスキャンでFPGAの端子を見てみました。バウンダリスキャンを使えばFPGAやDDR3の端子の動きが見えるようになるので、長時間の計測が可能になります。

下の図は2秒周期で256Mバイト書き込みを行った際のDDR3メモリ関連ピンの動きです。

書き込みを行っている間は明らかに他の部分と異なり、特にWEとODTが激しく動いているのがわかります。WEはリフレッシュにも使いますが、ODTは書き込み時にしか使いません。

1回1回の書き込みの塊を詳細に見てみると、256Mバイトの書き込みに299ミリ秒を要していました。

つまり、256Mバイトという長いデータを書き込んだ時間から測って、256×1048576÷0.299≒897Mバイト/秒ということになりました。

結論としてはDDR3を1066Mで動かせば、毎秒800Mバイト以上でデータを書き込むことは可能です。

メモリバスとAXIバスの総合的な帯域は84%程度のようですからDDR3 1000Mでもいけるかもしれませんね。数字の端数が出ない分、計算がすっきりするかもしれません。

特電Spartan-7ボードのデバイスドライバで署名エラーが出る

特電Spartan-7ボードをお買い上げいただいたお客様から、ドライバのインストールができないというご連絡をいただきました。コード52というエラーで、署名が検証できないとのことだったのですが、EVコードサイニング証明書を使って正しく署名をしたはずでした。

このことで長いこと悩んでいたのですが、ようやく原因が判明しました。

その答えは自分の過去のブログにがありました。

http://nahitafu.cocolog-nifty.com/nahitafu/2017/08/windows10-4e3e.html

つまり、Windows 10のドライバはEVコードサイニング証明書（普通の証明書の2倍の値段）で署名するだけではダメで、

• 昔から存在するドライバ（特電のSpartan-6ボードやArtix-7ボード、MITOUJTAGの付属ケーブルは7年以上前に署名されたドライバを使っているため、最新のWindowsでも問題なく動きます。）
• Microsoftに認証されたドライバ
• カーネルの起動時に読み込まれるドライバ

しか受け付けてくれません。

この問題を回避する一番簡単な方法はOSのセキュアブートを無効にすることです。

セキュアブートとというのは、私も正確には理解していないのですが、OSのブート時からすべてのカーネルモードドライバがマイクロソフトの署名によって正当性のあるプログラムであることが裏付けられている動作状態なのでしょう。たぶん、UEFIがMicrosoftのブートローダかどうかを署名で確認して、ブートローダが署名されたカーネルモジュールかどうかを署名で確認して・・という著名のチェーンで認証されたカーネルモジュールしか組み込まないようにしているんじゃないでしょうか。

セキュアブートは一般的にはBIOS(UEFI)の設定でOFFにすることができます。設定の場所はUEFIによってそれぞれですが、私のPCではUEFIの設定画面の中でOSの種類を「Windows以外」にすることでOFFにできました。

最も正しい解決方法は、作ったドライバに対してマイクロソフトの署名をもらう方法なので、そのやり方も調べないといけなさそうです。

30MHz以上でゲインが落ちる特性を打ち消す邪道フィルタ

OPアンプの特性なのか、30MHzくらいから予想よりも早くゲインが下がる問題を何とかしたいと思います。

そこで考えたのが、出力OPアンプの手前に50MHzくらいにピークを持つLCフィルタを入れたらどうかということです。

回路はこんな感じで、

特性は

です。

本当はOPアンプの前に入れる緩めのLPFだったのですが、50Ωで終端をしなかったためピークが出る特性となってしまいました。　

失敗は発明の母ということでこのピークを積極的に使ってみましょう。

全体の回路はこちら。

名付けて邪道フィルタ。

変なコンデンサを入れてノッチを聞かせたため、すでにチェビシェフじゃなくなってるし、さらに高域のゲインを補償するためにわざとピークを出す。こんな邪道なフィルタです

シミュレーションはこちら。

実際のOPアンプはシミュレーションよりも早く減衰するので、これなら30MHzあたりで減衰する特性と打ち消しあってくれるんじゃないか・・と淡い期待をして実験してみました。

実際に測ったものがこちらです。

意外といい感じとみるか、汚いと見るか、人それぞれです。フィルタの前にある16Ωという抵抗を調整することでピークの高さを調整できます。

ですが、やはりボツですね。

そもそもOPアンプの出力をLCフィルタに通すとシミュレーションどおりにならない原因がつかめていないのに、特性を打ち消すようなピークを作るというやり方でうまくいくとは思えません。

分かっているものを一つ一つ積み重ねていくやり方でなければなりません。

低リップルのチェビシェフフィルタを試してみる

Digikeyで購入したインダクタとコンデンサが届いたので、5次チェビシェフフィルタのリップルを0.1dBに抑えて試してみました。

作ったフィルタがこちら。

万能基板の在庫がなくなってきたので、今ある基板を切って使っています。

部品サイズも小さくなり、いろいろと勝手が変わるのでちょっと作りにくいです。早く「万能フィルタ基板」が仕上がらないかな。

回路図はこちら。

コイルに並列にコンデンサを入れてノッチを入れてみると・・

うほっ！すごい切れ味。50MHz→90MHzで約50dBダウンです。

シミュレーション結果はこちら↓

実測のほうがゲインが落ちる周波数が少し早い気がします。

このLCフィルタをCosmo-Z Miniの出力につないで、DACからDDSでさまざまな周波数の正弦波を出し、フィルタを透過してきた信号の振幅を測ってみました。

一昨日まで使っていた1dBチェビシェフフィルタと比べると明らかにリップルが減っていて改善されています。

しかし、RedPitayaのリップル特性にわずかに負けています。これは出力OPアンプの違いかもしれません。

チェビシェフフィルタを使うとOPアンプ出力インピーダンスの周波数依存性により、インピーダンスがマッチングできずにリップルが増大してしまうのかもしれません。

RedPitayaも同じように30MHzから下がり始めていますね。なぜなんでしょう。私の測り方に問題があるのかもしれません。（同軸ケーブルの定在波とか）

万能フィルタ基板の設計

5次のチェビシェフLPFはいろいろと実験をしつくした感じがありますが、そうすると7次のチェビシェフやBPFなど、いろいろなフィルタを作ってみたくなりました。

毎度毎度、万能基板に銅箔テープを貼って作るのも大変なので、汎用の「万能フィルタ基板」というものを考えてみました。

7次のLCフィルタまで実験できるよう、2012サイズの部品を7個乗せられるようになっています。

基板の表面はこんな感じ。

サイズは33.6mm×10.2mmで、両面基板です。

↑GNDが共振しないようにランダムにViaを打っています。

回路はとてもシンプルです。使わない部品は基本的にオープンにしておけばOKです。スタブが出来ていましまいますが100MHzくらいまでの実験であれば全く問題ないでしょう。

裏面には何も部品を乗せず、つるつるです。

部品のパッドはすべて2012サイズで設計しましたが、2012サイズのパッドなら1608や1005の部品を乗せることもできるからです。

製造するときには面付して作ることになると思います。

さて、どこの基板業者に出そうかな。

RedPitayaとCosmo-Z Mini+LPFのDAC特性の比較

RedPitayaとCosmo-Z Miniで1MHz~50MHzの正弦波を発生させて、LCフィルタを透過した後の信号レベルを比較してみました。

RedPitayaのLCフィルタはRedPitayaの基板に乗っているもの。Cosmo-Z MiniのLCフィルタは一昨日作成した5次のチェビシェフ with ノッチLPFです。

Cosmo-Z Miniのリップルが気になります。さんざんシミュレーションしてわかったことですが、出力バッファのインピーダンスとフィルタのインピーダンスが合っていないとリップルが大きくなる傾向があります。

RedPitayaのほうも30MHzくらいからゲインが下がり始めていますが、全体的にRedPitayaのほうが高周波特性が伸びているので、出力OPアンプの差かもしれません。RPはAD8021という200MHzクラスのを使っていて、Cosmo-Z MiniはTHS4041という165MHzクラスのものを使っています。

ノッチを入れるのであれば元のフィルタの特性はゆるくても何とかなってしまいますので、RedPitayaのLPFはチェビシェフではなく、バターワース or ベッセル＋ノッチの構成なのかもしれません。下にRedPitayaの出力LCフィルタの特性を測ったものを示します。

アンチエイリアシングフィルタにチェビシェフを使うのは、良策ではないのかもしれません。

高調波とサイドローブはRedPitayaに勝てたので、あと一息です。

まだまだ改良するべき点は多そうです。