Cosmo-Zが32chで安定して動作するようになった

Cosmo-Zは拡張基板を最大3枚重ねて、最大32chで動作するように設計したのですが、これまで、安定して動作してくれませんでした。

Cosmo-Zは、たくさんのADCからのデータをFPGAに集めるため、LVDSのシリアル通信を使っています。32chあれば、64対(128本)のLVDS信号に最大750MHｚの速度でデータを乗せて送ります。これをZYNQのISERDESでデコードしているのです。

問題は、ISERDESでデコードしたデータにノイズが乗ったり、ISERDESがそもそも正しいデータをデコードしなくなることでした。

現象１　メイン基板のみ（8ch）のときには125MHzまで動作するのに、16,24,32chでは80MHzどまりとなってしまう。周波数を上げると、データがめちゃくちゃになる。

現象２　計測データにノイズのようにスパイク状のFFFや000が乗ったり、データが大きく崩れる。

この問題に向き合って4か月。当初は拡張ボードの消費電力が大きすぎるのではないかとか考え、いろいろ試したのですが、どうも違う。消費電力の問題ではない。

ZYNQのLVDS入力で実はDIFF_TERMが使えないのかも・・と思ったりもしましたが、そうではない。HPポートでVCCO=1.8VにしてIOSTANDARD="LVDS"にすれば、DIFF_TERMは使える。DIFF_TERMを使っても、基板上に終端抵抗を実装してもこの問題は解決しない。・・

・・・そんなことをやりながら1週間ほど徹底的にデバッグして、ようやく原因がわかりました。

決めてとなったのは、ノイズが乗るときのデータの出方でした。

ノイズが乗るときや、データが壊れるときには、000やFFFといったデータが出現します。

もし、ISERDESとIDELAYの問題でサンプリングタイミングがずれる（あるいは反射などで波形が乱れている）とするならば、データが1bitずれたり隣のビットと混ざることはあるけれども、000やFFFになるということはないはずです。

000やFFFが頻繁に観測されるということは、ADCが出しているデータそのものに問題があるということだと考えました。つまり、FPGAのせいではない。

ADCが誤動作するのだということは、考えられる原因はクロックです。

使っているADCは、AD9633というものですが、データシートにはこのような絵が描かれています。

何がいいたいかというと、LVDSのクロックを与えるときには100Ωの抵抗で終端しなければならないということです。この終端抵抗を忘れていたためクロックの波形に反射が生じて誤動作してしまっていたのでしょう。

基板のスルーホール上にチップ抵抗で終端抵抗を実装してみたところ、見事に安定動作するようになりました。

拡張ボード上のADCからのデータも綺麗に受信できるようになりました。





今回得られた教訓は、

• 使いたいICで、LVDS入力は目的の抵抗で終端されていない可能性があるから、いつでも終端抵抗を入れられるようにしておく。
• 使いたいICで、LVDS入力にコモン電圧の規定もあるかもしれないから、いつでもカップリングコンデンサを入れられるようにすること

つまり、LVDSの信号やクロックは直結するのではなく、CやRを入れられる余裕を持たせておくということです。