はじめに
筆者がいたASICの世界では、製品の仕様から論理設計はお客様の担当、論理設計から先が半導体メーカーの担当、という分担となる場合が多いです。
そのようなビジネスの場合、デバイスがお客様が作成したテストベクタ通りに動くことは半導体メーカーで確認できますが、仕様として正しく動くかどうかを確認するのはお客様の担当となります。
製品仕様をお客様が策定する場合、動作仕様を正しく半導体メーカーが理解するのは無理なんです。
そのような製品開発では、半導体メーカーの試作評価は、製造テストをにらんだLSIテスターのみ、ということになり、実装機を使った実使用条件での評価は行いません。
このようなASICの世界にいた筆者ですが、以前「2相クロックの罠」のエントリーで書いた評価用チップの評価以外に、2製品で実装機評価を担当したことがありました。そしてその２製品で、担当した機能ブロックにバグがありまして、まるで当時から将来このような記事を書けと言われていたかのような歩留まりの良さ（笑）でありました。
その２製品のうち、片方は筆者がバグを発見、片方はバグを発見できず、お客様の評価でバグが見つかった、という状況でした。
今回のエントリーでは、私がバグを見つけた、という製品について書きます。オーディオI/Fに潜んでいた、非同期のクロックドメインをまたぐデータ転送のバグに関する話です。
製品の概要
15年以上前の製品になりますが、とあるminiDV規格のデジタルビデオカメラ向けにMPEG4アクセラレーターLSIという製品を受注、開発しました。
miniDVカメラはminiDVテープというテープに映像を記録していきますが、解像度のあまり高くない短時間の映像を、MPEG1やMotion JPEGなどの圧縮形式で作成する機能がおまけで付いているものがありました。
このおまけ機能のために、MPEG4を使った圧縮伸張機能を、システム性能をあまり上げずに取り入れたいというのがこの製品の趣旨だったのではないかと思います。
ちなみに、今主流の家庭用ビデオカメラは、HD画質の高画質カメラだと思います。これらのカメラはAVCHDという規格の画像ファイルを、ハードディスクやフラッシュメモリーにはき出す作りになっていますが、このAVCHDのデータ圧縮に使われているH.264という画像圧縮の技術も、MPEG4が使われています。
何が起こったか？
そんなこの製品、お客様と共同で試作品の実装機評価を行うことになり、ファーストカットが出てすぐ、実装評価ボードにLSIを実装して機能評価を進めて行きました。お客様と共同で評価をすることになったのには、少々特殊な製品受注の仕方による理由があるのですが、ここでは触れません。
チップ内部ではPCMデータは16ビットデータとして取り扱われますが、チップの外とのインタフェースはInter-IC sound（I2S）と呼ばれるクロック同期シリアル転送になるため、このようなインタフェース回路が必要となります。
実装機評価は全体としては、ボード上に乗ったGNDノイズの影響でSDRAMのデータが化けるなどという評価上のトラブルがあったものの、それなりに順調に進んでいきました。しかし、私が担当するオーディオインタフェースは、妙なことになってました。
音声再生のテストデータとして作った正弦波のPCMデータを、製品から外付けのオーディオコーデックに送り込んでオシロスコープで観測したところ、波形が時間軸方向に不安定にずれる現象が発生していたのです。
不具合箇所はすぐにわかった
この現象発生を受けて、論理設計者に回路を追いかけてもらったところ、不適切な回路設計がすぐに見つかりました。（ただ、残念ながら私は当時から詳細な回路構成は把握して居ませんでした 。申し訳ありません。）
このオーディオインタフェースは、外付けのオーディオコーデックとのデータのやりとりを、外部から入力される転送クロックを使って行います。転送クロックは、外付けオーディオコーデックで作ったクロックを使ったと記憶しています。
この転送クロックは、製品の内部クロックとは完全に非同期のクロックとなりますが、少なくとも、製品のオーディオインタフェースの、シリアル転送用シフトレジスタまでは、転送クロックで動作するように設計すると思うので、転送クロックと製品内部の動作クロックの、クロックドメインの境界で、異なるクロック間のデータ受け渡しが発生します。
異なるクロックというのは、全く異なったタイミングで相関関係なく勝手に動くものです。その異なったクロックで動いている回路ブロック間でデータのやりとりをしようとするのは、直感的に考えてもどう動くか予測ができない、という状況になります。普通に単純なクロック同期でデータのやりとりをしようとすると、あるときにはデータのやりとりが上手くいくけど、あるときにはやりとりが上手くいかない、といった状況に陥ります。
さらに、それら異なるクロックの位相関係によっては、メタステーブルというFFの出力が発振してしまう現象が発生することがあります。メタステーブルについては、こちらに良い説明があります。
上記の理由から、異なるクロックドメインをまたぐデータ転送では、非同期受け渡しの仕掛けを入れる必要があります。方法は色々あるようですが、データの受け側で2段以上のFFでデータを受けて、メタステーブルによるデータ化けを抑える設計が一般的です。
このケースでは、この仕掛けが入っていなかったと記憶しています。非同期回路であることを認識してはいたが入れ忘れたのか、そもそも設計者に異種クロック混在の回路である認識がなかったのかはわかりません。
ここ最近は高位記述言語の記法チェックのツールが進化して、非同期インタフェースが存在していることを検出してくれるツールの仕掛けがあります。筆者が製品開発の取りまとめをしていた頃（すでに10年前ですけど）はConformal LECというツールが社内で使われ初めていました）。
しかしこの当時はそこまで記法チェックツールがやってくれていたかどうかわかりません。
修正したかどうかは覚えていません
問題のある回路記述はすぐに見つかりましたが、回路修正を実施したかどうか覚えていません。
2段受けすべきところをやっていなかった訳ですから、妥当な回路にするためにはもう1段以上のFFが必要です。つまり素子の追加が必要となります。
ASICの世界に於いても、回路修正が必要になるかもしれないという用心から、空きスペースに、色々な素子を入れておくものです。問題となる回路の近傍に使える素子があれば、配線層の修正だけで回路修正が可能です。
そのような修正に迅速に対応するために、試作ロットのウエハを何枚か配線工程の前で止めておいて、配線修正に備えるものです。
近傍に使える素子がない場合は、素子の追加をするためには、下地からの全層修正ということになります。フォトマスクは全て作り直しとなり、試作ウエハも頭から流し直しなので、費用、時間とも大変大きなオーバーヘッドとなります。
別の人が修正後にまともな正弦波の波形を出しているのを見た記憶もあるので、回路修正をしたのかもしれませんね。
なお、お客様と協議の上、製品が使用されるセット設計において、問題となる回路を使わない回避策があれば、回路修正を行わない、という方法をとる場合もあります。もっとも、半導体メーカー側の不手際でこのようなことになる場合は、製品単価の引き下げを要求される場合もあります。当然ですよね。
半導体メーカーの自主開発品の場合は、修正するか機能を製品仕様から削るか、市場のニーズを見ながら決めることになると思います。
論理検証で発見するのは難しい
この異種クロックの受け渡しは、動作不具合を論理検証で見つけることがなかなかできません。なぜなら、論理シミュレーションの世界は、非同期の周期関係にあるクロックドメインの動作を再現するのが難しく、誤動作を検出できるテストベクタを作ることができないからです。
データの受け渡しに関する動作不具合は、ある一定時間内に限って考えると、起こるかも知れないし起こらないかも知れない、という性質のものとなります。なにせ相手は非同期で動作する異なる周期のクロックですからね。
このような性格のものですから、非同期受け渡しの回路がどこに入っているかをしっかりと管理して、回路動作にふさわしい非同期吸収の仕方をする必要がありますね。
このコメントはブログの管理者によって削除されました。
返信削除