著者：tombrady
SERDES（Serializer/Deserializer）には、独特かつ興味深く、時に課題になり得る側面が存在します。それは、ペアの形で機能する2つのICを使ってすべてのリンクが構成されるというものです。それにより、デバッグの対象になる変数の数は2倍になります。ただ、ペアで使用される2つのICにより、リンクの全体像をより正確に把握することが可能になるとも言えます。ここで言う2つのICとはシリアライザとデシリアライザのことです。シリアライザは、ビット・ストリームをリンク上に送信する役割を担います。一方、デシリアライザはリンクからビット・ストリームを受信します。前回の記事では、ピクセル・クロックの検出方法について説明しました。ピクセル・クロックは、シリアライザにデータが入力されたことを表します。今回は、このピクセル・クロックと対を成すデシリアライザ側のビデオ・ロック信号について説明します。この信号は、ビデオ・データがデシリアライザを通過していることを表します。
ビデオ・ロック信号
ビデオ・ロック信号は、デシリアライザが有効なビデオ・データを一貫したストリームとして受信しているか否かを表します。GMSL（Gigabit Multimedia Serial Link）では、リンクがロックされるとビデオのロックの処理が始まります。十分な量のビデオ・データのパケットがデシリアライザを通過すると、ビデオ・チャンネルがロックされます。そして、同チャンネルは出力用のPHY（物理層）から有効なビデオ・データを送信します。
VIDEO_LOCKビット
シリアライザ側で使われるPCLKDETビットと同様に、GMSLのすべてのデシリアライザにはVIDEO_LOCKという便利なビットが用意されています（図1）。これは、ビデオがストリーミングされていることを表します。VIDEO_LOCKビットは、ビデオ・チャンネルがロックされるとアサートされます。ただ、同ビットはデータが有効であることを示すものではありません。そうではなく、デシリアライザがデータを出力しているか否かを簡単に確認するためのものです。
図1. VIDEO_LOCKビットの詳細。デシリアライザIC「MAX96716A」のステータス・レジスタを例として示しました。
VIDEO_LOCKビットをモニターすれば、デシリアライザがロックされていて、ビデオ・データが出力されているかどうかをすぐに把握できます。同ビットが0の場合、ビデオ・データは出力されていません。したがって、その状態でプロセッサがビデオ・データを受信するときの潜在的な問題について調べても意味のある結果は得られません。
デシリアライザの各ビデオ・パイプには、独立したVIDEO_LOCKビットが用意されています。それらは、個々のビデオ・ストリームの追加の情報を提供するためのものです。図1において、個々のVIDEO_LOCKビットのレジスタ・アドレスは左上に示されています。これはシーケンシャルなビデオ・パイプについて説明するためのものです。図1の例における0x1FCは、デシリアライザのパイプYのレジスタです。また、0x21CはデシリアライザのパイプZのレジスタです。この表記は、GMSLに対応するデバイスのデータシートで広く用いられています。つまり、デバイス内のビデオ・パイプに似た機能ブロックについても、同じレジスタ・セットが使用されているということです。
デバッグの手順
デバッグの際には、まずPCLKDETが1になっていることを確認します。つまり、シリアライザが何らかの種類のビデオ・ストリームを受信していることを確認するということです。それに続いてVIDEO_LOCKビットをチェックします。この作業は簡単に実施できます。
前回の記事で説明したデバッグ手法では、カメラ／センサーに対応する評価（EV）キットを使用しました。今回は、ディスプレイに対応する評価キットを使用することにします。それを利用して、GMSL対応のディスプレイに最適なシリアライザ「MAX96751」とデシリアライザ「MAX96752」のデバッグ方法を示します。その方法では、カメラに対応するICと同じレジスタ・ビットを利用します。
ここで図2をご覧ください。この例では、よくあるブラック・スクリーンの問題が生じています。つまり、ディスプレイ・パネルの画面には何も出力されていないように見えます。
図2. ブラック・スクリーンの問題が生じているディスプレイ
最初のステップとしてやるべきことは、シングルボード・コンピュータ「Raspberry Pi 4」のHDMI（High-Definition Multimedia Interface）ソースからビデオ・データを受信しているか否かを確認することです。
図3から、ソースは何らかのデータを出力しており、シリアライザはピクセル・クロックを検出していることがわかります。シリアライザの機能により、これだけでリンクの半分のデバッグが完了したことになります。
図3. PCLKDETが1の場合の例
次に行うべきことは、デシリアライザがビデオ・データを受信しているか否かの確認です（図4）。VIDEO_LOCKビットを確認した結果、ビデオ・データがシリアライザを通過していないことがわかります。つまり、デシリアライザ側に問題がありそうです。
図4. VIDEO_LOCKが0の場合の例
図5からわかるように、ロック・ビットはリンクがロックしていることを表しています。また、エラー・ビットはエラーが生じていないことを示しています。以上のことから、何らかの設定上の誤りが見落とされていると推定できます。
図5. GMSLのリンクの状態。リンクはロックされており、エラーも発生していません（GMSLのエラーについては、今後投稿する記事の中で取り上げる予定です）。
そこで、設定用のスクリプトの内容を見直すことにしました。その結果、ビデオ・ストリームのIDが誤って変更されていることがわかりました。これが原因で、デシリアライザはビデオ・データのパケットを全く受信していなかったのです（図6）。
図6. 設定の確認。単純な設定ミスによって、ストリームを受信できていないことが判明しました。
必要な修正作業は、デシリアライザに対して適切なストリームのIDを設定することです。それにより、問題なく映像が表示されるようになりました（図7）。
図7. 修正作業を行った結果。システムが適切に動作するようになり、ディスプレイに映像が表示されました。
まとめ
ここまでの説明により、シリアライザとデシリアライザの機能を利用すれば、リンクで何が起きているのかを容易に把握できることがわかります。VIDEO_LOCKビットはPCLKDETビットと対を成すものです。これらを利用することにより、リンクのどちら側で問題が発生しているのかを効率的に絞り込むことができます。
あらかじめ用意されている基本的なビットからは、たくさんの情報が得られます。GMSLを使用していて何らかの問題が発生したら、まずは上述した2つのビットの値を確認してください。その後、設定上の問題を解消するには、やや複雑な作業が必要になるかもしれません。ただ、アナログ・デバイセズのGMSL対応製品には、接続の検証に役立ついくつかの便利なツールが組み込まれています。次回の記事では、そのうちの1つである「Video Pattern Generator」を取り上げる予定です。
GMSLのデバッグについて詳しく知りたい方は、こちらのページを参照してください。