メディア

RF回路のIP化は可能なのか?課題と新技術のせめぎ合い、結論はいかに…(1/3 ページ)

次世代のスマートホンなど、高度な携帯機器向けSoCには、ベースバンド回路、アプリケーションプロセッサ、アクセラレータ、メモリーなどが集積される。ただし、必要なのはそれだけではない。これらに加えて、無線接続用のRF回路を複数集積しなければならないのだ。そして、その作業は容易ではない。そこで必要になると考えられるのはRF回路のIPの再利用である。果たしてこれは実現可能なのだろうか。

» 2008年10月01日 00時00分 公開
[Robert Cravotta,EDN]

何が問題なのか?

 今日のSoC(System on Chip)開発では、定められた期間内に複雑な設計を完了するために、IP(Intellectual Property)の再利用が必須となっている。すでに、デジタルの世界ではそのための手法が確立されている。あらゆる種類のアプリケーションにおける高速I/OやSERDES(Serializer/Deserializer)など、非常に周波数の高い一部の回路ブロックではIPの再利用は当たり前のものとなった。

 しかし、無線アプリケーションのRF(Radio Frequency)回路については、設計の再利用は実質的には未知の分野である。その理由は何だろうか。そして、この状況を打破する方法はあるのだろうか。あるいは、モバイル機器向けの次世代SoCの多くでは、引き続きRFブロックはカスタム設計としなければならないのだろうか。

■回路の面積

 上述した一連の疑問が生じる原因の1つは、モバイル向けSoCチップにおける面積の問題である。RF回路では、製造プロセスルール上の最小寸法でトランジスタを設計することはない。また、インダクタやコンデンサを小さくすることも難しいので、回路面積が大きくなる傾向にある。それだけでなく、高度な携帯機器では、SoC上に多くの無線機能を搭載する必要があるので、チップ面積の問題がより顕著になる。

写真1 IEEE802.11nに対応したRF回路 写真1 IEEE802.11nに対応したRF回路 Broadcom社の「BCM2055」のチップ写真。IEEE802.11nのドラフト仕様に準拠するRF回路ICであり、4×4のMIMOに対応する。かなり複雑な回路が集積されており、チップ面積も大きい。

 例えば、マルチバンドの電話機やインターネット端末として機能する機器について考えてみよう。このような機器では、使用条件に応じて最適な接続方法が選択される。携帯電話ネットワークへの接続用にはLTE(Long Term Evolution)、Wi-Fiアクセスポイントへの接続用にはIEEE 802.11n MIMO(Multiple-input/Multiple-output)、あるいはBluetooth、ワイヤレスUSB、ないしは独自の短距離/広帯域幅プロトコルに対応した実装用に少なくとも1つのUWB(Ultra Wideband)、位置情報を取得するためのGPS(Global Positioning System)などに対応することになるだろう。いずれも重要なものだが、特にIEEE 802.11n MIMOなどは占有面積がかなり大きくなる(写真1)。

 これらの無線機能は、最初のうちはすべて別々のチップに集積されることになるだろう。しかし、すべてとは言わないまでも、いくつかの機能についてはSoCへの移行が求められるようになるはずだ。ただし、パワーアンプやアンテナスイッチなどの大信号向けRF回路だけは例外で、SoCには搭載されない可能性が高い。

 一般的な無線システムにおける小信号RF回路にはそれほど多くのバリエーションがあるわけではない(図1)。というよりも、最新の無線機能においてもほぼ同一の構成がとられる。だからといって、RFブロック全体や個々の機能を再利用することが容易だというわけではない。

図1 一般的なRF回路ブロック 図1 一般的なRF回路ブロック 典型的な双方向無線機能における主な機能ブロックを示している(提供:BerkeleyDesignAutomation社)。

 特にRFに関する専門知識の乏しいSoC設計チームの場合、実際にRF回路の設計を再利用するとなれば、サードパーティ製のIPを利用したいと考えるだろう。RF回路は非常に複雑で、チップ上での占有面積が大きく、リスクが高いからだ。しかし、現在のところ、サードパーティ製のIPは広く利用されているわけではない。今後もしばらくは、RFブロックの一部またはそのほとんどが、サードパーティのIP開発者ではなく、SoC設計チーム自身によって実装されることになるだろう。

 このような状況が生じていることには、いくつかの大きな理由がある。そもそも、IPを再利用可能なものとするには、作成者と利用者の合意の下、その中身が両者に明確に理解されていなければならない。明確に定義されたポートを備えることはもちろんだが、ポートを行き来する信号についても、各種ブロックの機能との関係や、信号の特性の許容範囲がはっきりと定義されている必要がある。このような基本的な定義がなければ、再利用可能なIPとはならない。ところが、以下で説明するように、こうした要件のすべてがRF回路のIPにおいては問題になるのである。

■不十分な規格

 1つ目の問題は、規格に関するものだ。確かに、検証用のIPや相互運用性のテストの仕組みが用意された明確なエアインターフェース規格がいくつも存在する。しかし、問題は無線機能の実装にある。米Berkeley Design Automation社のCEO(最高経営責任者)であるRavi Subramanian氏は、「そうした無線規格に準拠するトランシーバのアーキテクチャは、まだ発展途上の段階にある。無線機能をどのように構築するかということは、それを提供する予定の市場に依存している」と指摘する。例えばUWBの無線ブロックは、構造的にはIEEE 802.11の無線ブロックによく似ているが、詳細に見れば異なる部分がある(図2)。

図2 UWBトランシーバの回路ブロック 図2 UWBトランシーバの回路ブロック UWBエアインターフェースをサポートするための機能ブロックが追加されている(提供:MIPS社)。

 米Synopsys社でミックスドシグナル製品部門のマーケティングディレクタを務めるNavraj Nandra氏は、「規格自体も、期待されるレベルで明確に定義されているわけではない」と指摘する。加えて、同氏は「国が異なれば1つの無線規格に対する実装方法が異なる場合がある」とも述べる。例えば、米国のWiMediaは帯域グループ1を使用する。ほかの国ではそれよりも高い周波数帯域のグループを使用するので、異なる設計が必要となる。

 なお、Subramanian氏は、「SoC上にCMOSで新たな無線機能を搭載することができるなら、そのことはその企業にとっての強みとなる」と指摘する。その上で、同氏は「高性能なRF回路の搭載は、製品における重要な要素であり、製品の差異化を可能にするものだ。RF回路をIPとして購入できるようになったとしても、実際には購入しないだろう」と続けた。

■複雑なインターフェース

 では、RF回路のサブブロックのライセンス購入についてはどうだろうか。そうしたブロックと同じくらい高速なPLL(Phase Lock Loop)であれば、サードパーティからライセンス購入することは可能である。しかし、Nandra氏によると「サブブロックを購入することもあり得ない」という。「RF回路に必要な機能ブロックははっきりしている。すなわち、RFフロントエンド、ミキサー、データコンバータなどといった具合だ。問題なのは、それらを明確にブロックとして分割する方法や、それらの間のインターフェースが定義されていないことだ。例えば、PCI(Peripheral Component Interconnect)Expressでは、PHY(Physical Layer)層とMAC(Media Access Control)層の間のインターフェースとして業界標準の仕様が存在する。しかし、RF回路では、機能ブロック間のインターフェースは定義されていない」と同氏は述べる。

 米MIPS Technologies社のワイヤレスシステムグループ担当エグゼクティブバイスプレジデントを務めるCarlos Leme氏は、「この部分のインターフェースは非常に複雑だ。単に接続すればよいというものではない。ブロック間を行き来するRF信号の負荷とインピーダンス整合の要件をすべて調べる必要がある」と述べる。

■課題は山積み

 加えて、RF回路の各ブロック内の機能も明確には定義されていない。また、RF回路の分割は非常に複雑な作業になる。「ブロックの各種仕様は互いに関連している」(Leme氏)からだ。

 さらには、「熟練したRF設計者でも、回路のある部分で大きくなってしまったノイズを、別の個所で解消しようとするケースがある」(同氏)という。そのため、RF回路を構成するサブブロックIPの市場が拡大することはなかった。IPの提供元が、常に設計チームと密接に作業しなければならないからだ。「IPとは、そのような開発形態で作り出すものではない」(Leme氏)のである。

       1|2|3 次のページへ

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.