メディア

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

» 2007年02月01日 00時00分 公開
[Ron Wilson,EDN]

プログラミングによる対応

 プラットフォーム戦略においてもう1つ重要なのは、変更の可能性があるブロックを隔離することである。これは、単一の設計で複数の製品をサポートしたり、不確定な設計要求によるリスクを軽減したりするためだ。それには、内部の変更が設計のその他の部分に影響を与えないように、そのブロックを標準的なインターフェースでカプセル化することが必要となる。これは、以下のような手法により実現可能である。

・問題のブロックを単に別のチップに入れる

・新しいRTLコードに大きな変更を加えることなく特定のブロックに合成できるようなSoCをうまく設計する

・その機能を、プログラム可能なハードウエア/ソフトウエアに移行する

 将来的に変更の可能性がある部分は、ソフトウエアで実装するか、少なくともFPGAに実装すればよいという考え方は従来から存在した。実際、本稿の執筆に当たって筆者が話を聞いた人々は、次のように語っている。すなわち、消費電力や性能の観点からは最適な選択ではない場合でも、市場投入までの時間を確保し、後で修正できるようにするために、ソフトウエアで機能を実現する顧客が多いという。

 「テープアウト後に調整できるように、プログラミングが可能であるという性質を利用した設計が非常に増えてきている」と、Cadence社エンジニアリングサービスグループのディレクタPaul Russert氏は語る。ブロックの検証には時間がかかり、テープアウトに間に合わない恐れもあるので、このような対策は必要不可欠だといえる。

 しかし、プログラミング対応を可能にする方法については、まったく異なる意見が存在する(図3)。

図3 チップ内外での対応 図3 チップ内外での対応 デジタル著作権管理などの機能には、ソフトウエアやセキュリティレベルの高いハードウエアの複雑な組み合わせが必要となる場合がある。

 まず、可能な限りソフトウエアで実装するのがよいという意見がある。命令アクセラレータやDSPブロックの出現、あるいは組み込みCPUコア上の命令がさらに複雑になってきたことに従い、この方法を採用するケースが増えてきた。

 その一方で、プログラミング可能なハードウエアで実装するほうがよいという意見もある。IPベンダーの英Imagination Technologies社でマーケティング担当バイスプレジデントを務めるTony King-Smith氏によると、「当社の場合、クリティカルな状況では、拡張可能なパイプライン構成ブロックを用いてデータパスを構築する」という。ブロック自体がコンフィギュラブルであるため、それによって構成されるパイプラインはマイクロコードレベルでプログラミング可能となる。同社はこの柔軟性を、ドライバコードからマイクロコードまで、さまざまな抽象化レベルで顧客に提供している。その結果、スループットが高く、エネルギー効率の良い、プログラミング可能な要素が実現される。また、その柔軟性とプログラミングの容易性については、いくつかのオプションの中から選択できる。

  Newport Media社のAbdelgany氏は、以下のように異なるアプローチを主張する。

 「われわれは、できる限り消費電力を抑えた小さなチップを市場に提供したいと考えてきた。柔軟性に関しては、設計チームがチップに対して段階的に再設計していくことで対応している。これは容易な作業ではない。それでもなおプログラミング可能であることが必要となる部分がかなり生じるが、これは顧客の要求に応じるためであって、チップ開発者の利便性を図るためのものではない」。

並行設計による対応

 どのようなアーキテクチャを選択するにしても、設計チームがリファレンスデザインを変更することなく使用すると決めない限り、新たな実装のフェーズが発生する。民生機器の設計では、ここでも主に並行設計のためのさまざまな戦略をとることにより、課せられた制約に対応している。

 この分野において、最も直観的で、かつおそらく最もよく用いられる戦略は、以下の2つである。

・ハードウエアとソフトウエアを並行して開発する

・ハードウエアをモジュール化することにより、モジュール自体を並行して設計できるようにする

 これらは目新しい手法ではなく、多くの設計チームが採用している。今日では、複数の国にまたがって開発が行われるケースも多い。例えばカリフォルニア州の設計サービスチームが、英国から入手したIPブロックを利用してポケットサイズのオーディオプレーヤ向けのチップを設計したりするのである。そのようにして出来上がったチップは、インドの設計チームが開発した基板に実装されるかもしれない。さらに、そのインドのチームがサードパーティ製のカーネル上に作成したドライバのコードは、ルーマニアで開発されたものかもしれない。

 このような設計において重要なのは、各モジュールのインターフェースや仕様を明確に定義することである。モジュールをカプセル化できない場合には、アプリケーションエンジニアを客先に駐在させるしかない。実際、ブロック間のインターフェースが複雑になるほど、設計チーム間のやりとりを密にしなければならないと管理者は認識している。これが正しいことは直観的にも明らかである。

 「合理的なプロジェクト管理が必要だ」とAbdelgany氏は指摘する。「しかし、最終的にはエンジニアを客先に派遣することになるだろう。このレベルのアプリケーションサポートを提供できるからという理由で、われわれが顧客に選ばれたケースもある」と同氏は続ける。

 設計のアウトソーシングが関心を集めている今日、Abdelgany氏は上記のような最近の経験から、米国での事業展開に明るい見通しを持っている。「当社には中国、韓国、欧州系のエンジニアがいる。世界のほとんどどこへでも、アプリケーションチームを派遣することができる。多種多様な人種で構成されていることが、われわれの強みだ」と同氏は語る。

Copyright © ITmedia, Inc. All Rights Reserved.

RSSフィード

公式SNS

EDN 海外ネットワーク

All material on this site Copyright © ITmedia, Inc. All Rights Reserved.
This site contains articles under license from AspenCore LLC.