変容する民生機器設計：市場の厳しい要求に応えるために（4/4 ページ）

「検証」こそが大きな問題

　民生機器の設計に携わる多くの設計者が、「自分たちが直面している最も深刻な問題は検証だ」と指摘する。検証が開発時間の中で最も大きな割合を占めるケースは多い。ある設計マネジャによれば、その割合は2/3以上にもなるという。従って、時間の制約に対応するには、検証に関する対策を講じればよいということが分かる。また、多くの民生機器向け設計において、作り直しという手戻りが発生するのは致命的な問題となる。FPGAをベースとした方法で初期の要求を満たすことができたり、投入時期を数カ月遅らせることができたりするような市場と比べて、民生機器向けの場合、検証はより徹底的に行わなければならない。

　このような状況に対し、民生機器の設計チームがまず行うべきことは、計画を立てることである。Cadence社のHenricks氏は、「設計チームは2種類に分けられる。1つは検証計画を立てるチーム。もう1つはテープアウトの後も、延々と検証を行っているチームだ」と指摘する。ここでいう計画は、システムを構成する各ブロックごとの検証戦略と、システムとして統合した後の検証戦略の両方に対応していなければならない。その計画では、従来以上にカバレッジを利用する方法に頼ることになる。Cadence社のMcNeil氏によれば、「どこまでやれば検証が終了したと見なしてよいのかということが最大の問題だ」という。しかし、どこまでやれば検証は終了するのかというのは、いまだ答えの出ない問題である。カバレッジを用いる手法は目安にはなるが、決定的な根拠にはならない。

　検証時間を削減するには、個々のブロックにおいてテストベンチを再利用したり、以前の設計で用いたシステムレベルのテストベンチを適用したりするといった方法が効果的である。また、検証においても並行作業という手法が利用できる。システムレベルの機能検証から開始し、ブロックレベルのRTL/ネットリスト検証の進行に合わせて下位レベルへと検証を進めていくことにより、（絶対的な時間ではなく）日程面での時間を短縮することができる。非常に厳しいテストは、問題のある部分やカバレッジが低い部分に焦点を当てて実施できるとさらによい。

　検証計画において、アサーションを適切に用いることを義務付ければ、動的テストで大きな時間短縮を図ることができる。Henricks氏は、「この手法では設計を熟知していなければならない。設計におけるクリティカルな部分がどこであるかを知っておく必要がある」と語る。大部分がほかの企業からライセンス供与されたプラットフォームである場合は、その情報の質や量が問題となる可能性がある。

　民生向け製品の検証を困難にするほかの問題としては、システムの最終的な出力が映像や音声であることが多い点が挙げられる。この場合、完全に正しい出力など存在しない。出力は誤っているか、または相対的な品質評価におけるいずれかのレベルにある。主観的な判断では基準が甘くなってしまうことが多く、検証プロセスに問題が生じてしまう。FPGAベースの検証を並行して実施しなければ、期限間際になって主観的な判定によって却下されるというリスクを負うことになる。

　残念なことに、計画を立てたりツールを利用したりしても設計マネジャの悪夢は消え去らない。「設計の終盤になって、検証プロセスから生じる技術変更指示（ECO：engineering change order）が非常に多い」とHenricks氏はいう。この状況に対処するために、民生機器の設計では、クリティカルな機能をソフトウエアへ移行し、後から生じるバグを修正するために複数回のソフトウエアリリースを計画するということがよく行われる。その後、安定したソフトウエアモジュールをハードウエアエンジンに変換することによりコストを削減するのである。

　しかし、この戦略においても、設計の初期段階で、最も問題が多くテープアウト後の柔軟性を必要とする機能はどれかということを予測する能力が必要となる。このような能力は、経験を積むことでしか得ることができない。

プラットフォームの将来

　表1に、民生/産業機器それぞれの設計の特徴をまとめた。今日、民生機器の設計手法は数多く存在する。しかし、それらすべてが1つの傾向を見せ始めている。その傾向は、「プラットフォームの利用」ということで特徴付けられる。プラットフォームには、ASSPチップの形で提供されるハードウエアプラットフォームや、ブロック/フローの集まりであるIPプラットフォームなどがある。民生機器向けの市場ではプラットフォームがすでに広く普及しており、多くのIPベンダーやCPU/DSPベンダーがかかわっている。彼らは、最終的な製品に迅速に到達するために必要なIP、ハードウエア、ソフトウエア、サービス、トレーニングなどを総称して「エコシステム」と呼ぶ。

表1　民生/産業機器市場における設計の特徴

　設計に関するこの考え方は、業界に対し、必然的にさまざまな形で影響を与える。まず、検証がますます大きな問題になってきたことから、IPベンダーは簡単なテストベンチに頼るのをやめてアサーションベースの検証手法を用いるようになった。従来は、標準化団体までもが、読解不可能であいまいな1000ページにも及ぶ規格文書を作成していた。それが最近では、仕様記述言語によって、実行可能な仕様を記述することが求められるようになった。

　 2つ目に、EDAベンダーに対しては、民生機器の世界におけるより現実的なフローの提供が求められている。それは、まったく新しい設計に対してではなく、段階的な設計変更やプラットフォームに加える微調整に対して最適化されたフローでなければならない。たった1つのブロックを変更するために、すべての合成、配置、配線作業を設計チームにさせる必要はない。同様に、検証も段階的なものでなければならない。1カ所の変更によってほかの部分が変更されていないことが、ツールによって静的に実証できなければならないのである。

　 民生機器市場における厳しい要求は、ファブレス企業のあり方も変えてしまうかもしれない。Imagination Technologies社のKing-Smith氏は、「ファブレス企業の役割は、マーケティングおよびファウンドリとの関係構築へと移ってきている。IPの選択、統合、検証が、社外の特定のアプリケーション分野に向けて発展したエコシステムで行われるようになってきている」と述べている。

　 この新しい時代においては、システム開発でキーとなるのは最も強力なIPベンダーであるかもしれないし、デジタル著作権管理などの新しい規格に関する専門知識の所有者かもしれない（別掲記事「DRMは設計者にとって“悪夢”となるか」を参照）。このような動きは、発展し続ける民生機器市場におけるエンジニアリング設計のあり方を大きく変える可能性がある。