IP Award OPEN Collaboration

　＞提携サイト
　NIKKEI MICRODEVICES
　Silicon Online

第７回LSI IPデザイン・アワード「IP優秀賞」受賞者インタビュー
H.264デコーダの開発には，検証用IPが欠かせない

［2005/06/14］

　企業部門のIP優秀賞は，アイベックステクノロジー（IBEXテクノロジー）が「H.264検証用IP」で受賞した。H.264は最近になって急速に普及しつつある，画像の圧縮伸長アルゴリズム。本IPは，H.264デコーダ・コアの検証用に開発された。パラメータをランダムに設定しながら，検証用のデータ・ストリームを生成する。短い検証期間で従来よりもはるかに多くの設計不良（バグ）を見つけ出せる。受賞者である扇谷氏と峯尾氏に，開発までの道のりと開発成果の概要を伺った。

（聞き手：福田昭＝テクノアソシエーツ特約記者）

第７回LSI IPデザイン・アワードの企業部門で
「IP優秀賞」を受賞した
扇谷信孝（おおぎやのぶたか）氏（左側）と
峯尾嘉征（みねおよしゆき）氏（右側）。
アイベックステクノロジー（株）の
LSI技術部LSI開発課に勤務。

Ｑ：本日はよろしくお願い致します。まず，「アイベックステクノロジー（旧社名：LSIシステムズ）」の業務内容を紹介してください。
	扇谷氏	アイベックステクノロジーは，MPEG（Moving Picture Experts Group）技術（注１）を得意とする企業です。MPEGの回路コアやMPEGボード，MPEGシステムなどを開発し，販売しています。売り上げの主な部分は，LSI設計の受託業務で占められています。設計受託業務も，主力はMPEG関連です。（注１）動画像を圧縮伸長する技術の一つ。

Ｑ：お二人のお仕事を教えてください。
	扇谷氏	LSI設計の受託チームにいます。私はここ数年はずっと，検証用IP（intellectual property）の開発に携わっています。
	峯尾氏	以前はLSI設計に従事していました。2004年に，検証用IPの開発業務に移りました。

従来の手法ではバグが取りきれない
Ｑ：これまでにも貴社は，MPEG2デコーダ・コアの検証用IPとMPEG4デコーダ・コアの検証用IPを開発してきました。検証用IPとは何をするものなのでしょうか。
	扇谷氏	デコーダ・コアに入力するデータ・ストリーム（ES）を生成するソフトウエアです。パラメータをランダムに設定しながら，データ・ストリームを自動的に生成してくれます。このデータ・ストリームを機能検証に利用することによって設計不良（バグ）を見つけ出すのです。

Ｑ：検証用IPが作り出すデータ・ストリームとは，どんな画像なのでしょうか。
	扇谷氏	デコードしても，画像としては認識できません。雑音にしかみえないデータです。検証用IPは，画像の品質をチェックするものではなく，デコーダの機能を検証するためのソフトウエアです。

Ｑ：従来の機能検証作業とは，何が違うのでしょうか。
	扇谷氏	従来の検証作業ではコンフォーマンス・ストリームと呼ぶ，適合性試験のために規格化されたストリーム・セットを使ったり，エンコーダ・ソフトウエアの出力ストリームを使ったりしていました。この方法だと，検証漏れが残り，設計不良（バグ）をなかなか取り除けませんでした。
	峯尾氏	バグを可能な限り多く見つけ出すには，パラメータをできる限り変動させたストリームを使って検証する必要があります。われわれが開発した検証用IPは，パラメータをランダムに動かします。通常のエンコーダでは作れないストリームを生成してくれるのです。デコーダ・コアの設計者が想定していないバグを早期に見つけられるという大きなメリットがあります。

Ｑ：ランダムにパラメータを動かすのであれば，ランダム関数を使えば良いのでは。
	峯尾氏	MPEGやH.264などの規格仕様では，パラメータが相互に関連しながら動くし，ストリーム上には現れない規格仕様に潜在するパラメータも多数存在し，それらにも制約があります。単純なランダムではありません。規格仕様の制約条件を組み込みながら，パラメータをランダムに動かさなければならないのです。
	扇谷氏	パラメータをエンジニアが直接指定することも可能です。指定した以外のパラメータは，検証用IPがランダムに設定します。ダイレクト・テストとランダム・テストの併用ということになります。

Ｑ：検証用IPはどういったプラットフォームで動くのでしょうか。
	扇谷氏	機能検証ツール（注２）に組み込んで動かします。（注２）米Verisity Ltd.（現在は米Cadence Design Systems, Inc.に買収されている）の機能検証ツール「SpecmanElite」。ハードウエア記述言語よりも抽象度の高い独自仕様の記述言語「ｅ」を利用する。なおアイベックステクノロジーの検証用IPは，ｅ言語で記述されている。

H.264では検証用IPを先行して開発
Ｑ：H.264では，MPEG2のときと何か違いがありますか。
	峯尾氏	H.264では追加された符号化ツールが数多くあるため，MPEG2よりもパラメータの数が大きく増えました。このため，デコーダ・コアがMPEG2よりも複雑になっています。
	扇谷氏	そこでH.264ではデコーダ・コアの開発に先行して，検証用IPを開発しました。

Ｑ：検証用IPを先に開発したのですか。
	扇谷氏	MPEG2のときは，デコーダ・コアの開発が先でした。このため，デコーダ・コアの開発段階でバグをなかなか取り除けませんでした。検証用IPを開発して設計検証に利用したところ，これまで見つからなかったバグを，簡単に発見できたのです。そこでMPEG4のデコーダ・コア開発では，検証用IPも同時に開発しました。そしてH.264では，検証用IPを先に開発したのです。先に検証環境を準備しておくことで，デコーダ・コアの開発期間を短縮できます。

H.264の規格仕様を熟知する
Ｑ：H.264検証用IPの開発では，どのような点で苦労されたのでしょうか。
	峯尾氏	H.264の規格自体を理解する作業が大変でした。規格仕様書の内容をすみずみまで理解し，すべてのパラメータの関係や制約を把握しなければならないからです。

Ｑ：開発された検証用IP自体の確からしさは，どのように確認したのでしょうか。
	峯尾氏	技術者に良く知られているエンコーダ・ソフトウエアとデコーダ・ソフトウエアがリファレンスとして存在していますので，このリファレンス・ソフトウエアを活用しています。検証用IPが生成したデータ・ストリームをリファレンス・ソフトウエア（デコーダ・ソフトウエア）に入力し，正常に出力するかどうかを計算値と比較するのです。　出力せずに異常終了したり，出力結果が意図した値と食い違ったりしている場合は，リファレンス・ソフトウエアまたは検証用IPのどちらかにバグが存在していることになります。そこでどちらかを修正し，再びデコーダ出力を計算値と比較し，再び修正するという繰り返しです。

Ｑ：開発期間はどのくらいでしたか。
	扇谷氏	2004年４月から開発を始め，１年と少しかかっています。

Ｑ：検証用IPの市場への供給は。
	扇谷氏	すでに始めています。

Ｑ：話題が変わりますが，過去に「MPEG2 ビデオデコーダ検証用IP」の開発で第５回のIP賞を，「MPEG4ビデオデコーダ検証用IP」の開発で第６回のIP賞を受賞されていますね。そして今回はH.264の検証用IPで，さらに上のランクであるIP優秀賞を受賞されました。
	扇谷氏	H.264のデコーダ・コアは，開発がこれから本格化します。応募のタイミングが良かったことが優秀賞に結びついたと考えています。MPEG2のデコーダ検証用IPを開発したときには，MPEG2デコーダ・コアはすでに枯れた技術になっていましたから。

Ｑ：過去にIPアワードを受賞されたことで変化は何かございましたか。
	扇谷氏	お客様のわれわれに対する，信頼感が上がったと感じています。MPEGやH.264などの規格仕様や検証手法に精通しているとご認識いただいているようです。

Ｑ：本日はどうもありがとうございました。

受賞論文の一覧はこちら

図１：検証用IPを使用した検証手順
検証用IPは，シミュレーション用のデータ・ストリームを生成する（中央の橙色部分）。設計者はシミュレーションを実行し，バグを修正するとともに，カバレッジを解析する。カバレッジ解析でテストホール（検証漏れ）を見つけ，未検証部分を対象としたデータ・ストリームを作成する。
図１：検証用IPを使用した検証手順

図２：操作画面の例
右下のウインドウで赤いマークが，未検証の個所を示す。緑のマークは検証済みの部分。