カンファレンス会期：5月17日～18日(現地時間)

会場：米カリフォルニア州サンノゼ
DoubleTree Hotel

　前回は一般的なDSP搭載プロセッサについてご紹介したが、次はもう少し変わったものをご紹介したいと思う。

●Tarari T9000

Tarari,VP Engeneering & CTOのJeff Carmichael氏

　まずご紹介するのは、「Tarari T9000」である。実のところ、これは本当にDSPか? という疑問が湧くもので、SPFでは扱いに困った挙句“Cool Processor”(このCoolは冷えているという意味ではない)に分類された。とはいえ、内部構成を冷静に観察すると、動き方としてはGPP+DSPにかなり近いものがあるので、あえてここでご紹介したいと思う。

　さてこのT9000、Tarariの言葉を借りれば“Content Processor”なる代物である。大分類としてはネットワークプロセッサになるのだが、いわゆるパケットのルーティングなどが目的ではなく、XMLなどの文法パースや変換などを行なうという、ちょっと変なものである。

　T9000がターゲットとしているのは、XMLベースのアプリケーションが動作するサーバなどである。こうしたアプリケーションサーバでセキュアなXMLデータのやりとりをする際のアクセラレーションを行なうというのが、この製品の目的だ。具体的には、スライド「Content Processor Advantage」で紹介されたような処理をターゲットにしている。

XMLのパースやSSLといった処理を全部汎用プロセッサで行なうから重くなる、というのがTarariの主張である	SSLなどでの暗号化/復号化、正規表現解析や文法解析、圧縮/伸長といった処理は、アルゴリズムが複雑なことや、しばしばビットストリームのハンドリングになることもあり、処理は重い。またXMLは記述が冗長なので、これも処理に時間がかかる。こうしたものに焦点を当てたのがT9000である

　T9000の内部構造はスライド「Tarari T9000 ASIC Architecture」で示された。ちょっと目新しいのは、Grammer Processing AgentだのCompression Agentだのといった、あまり見慣れないユニットが高速な内部バスでContent Processing Controllerと接続されていることだ。このContent Processiong Engineの内部はスライド「T9000 Content Processing」で紹介された。ここは完全にコンテンツ処理がメインのエンジンで、まずストリームの圧縮/伸長を行ない、その後文法解析などを行なうという仕組みだ。

このAgent、説明を聞く限りでは、データストリームから各々のAgentが対応すべき要素を抜き出し、Context Processorに送り込むという処理を行なうようだ。要するに(大きな意味での)Context Perserの働きをしているわけだ	Agentから渡されたデータを処理するのがこのエンジン部

　このT9000、当然ながら単独でネットワークの処理を全部こなせるわけではないので、実際の搭載例はスライド「T9000 Integration-Server Architecture」、「T9000 Integration-Network Devices」に示したような構成を考えているという。TCP/IPのハンドリングや、展開した後のデータの処理はT9000の知るところではないから、こうしたものをハンドリングするために、別のGPPが必要になる。

サーバーに適用した例。TCP Offload Engine搭載のEthernetコントローラを組み合わせ、適切なドライバを書けば、Ethernetから直接T9000にDMAでデータを送り込み、結果をメインメモリに書き出すという効率の良い構成も可能だろう	Tarariがメインに考えているのは、むしろこちらの構成ではないかと思う

　これはある意味片手落ちともいえるが、いまさら新たな汎用プロセッサを作ったところでマーケットシェアを確保するのは大変だし、意味が無い。それよりも、既に存在する膨大なサーバーマーケットにうまく適用できるアクセラレータとして構成するほうが賢明、という判断は非常に正しいと思う。

　ところでなぜここでT9000を取り上げたかというと、T9000がちょうどCellと対比する形になっているからだ。Cellは「強力かつ柔軟性に富むGPP」+「柔軟性に富み、高性能/消費電力のDSP×8」という構成に対し、T9000は「強力な、特定用途向けのDSP」+「特定用途向けの、高性能/消費電力のGPP×11」という構成になっている。

　GPPはこの場合Agentであって、本当にGeneral Purpose Processorと呼べるのかやや疑問な面はあるが、機能を考えるとDSPとも言えない。Cellは、強力なメインプロセッサが処理を回しつつ、単純な処理をDSPにオフロードするというイメージなのだが、T9000は強力無比なDSPが、処理を途切れさせないように11個のDSPにデータストリームを取ってこさせるというイメージであって、GPPとDSPの主従関係が完全にひっくり返っているところがなかなか面白い感じである。GPP+DSPにはこういったソリューションもある、という例の1つと思っていただければいいだろう。

●InterQoS Multimedia Processor

InterQoS System,DirectorのRon Hui氏

　InterQoS Systemが発表したMultimedia Processor(プロセッサ名称は公開されていないので、以下“MP”と表記する)は、別の意味で注目すべきプロセッサである。同社は名前の通り、ネットワークプロセッサをメインとする会社であって、マルチメディア向けの製品はこれが初めてになるが、この新しいプロセッサをちょっと面白いコンセプトで設計した。

　スライド「SOC Architecture」がそのMPのブロック図である。これだけ見ていると、さして新しいものではない。1個のRISCプロセッサ＋8個のDSPという組み合わせで、これにさまざまな周辺回路を組み合わせたSoCを構成することで、さまざまなIA機器に応用しようという目論見である。このRISC+DSPという構成に至る理由として、シングルCPUだけで構成しようとすると色々無理があるため、RISC+DSPが一番合理的としている。

構成自体は至ってコンサバティブ	1つのCPUで全部まかなう場合、ハードウェアでチューニングするほうが効果的ではあるが、コストもかかる	ハードウェアで行なう場合、RISCよりはVLIWの方が性能が上げやすいが、DSP(写真中ではSPと表記される)を併用すればより効果的である。逆に言えば、DSPを使う限り必ずしもVLIWである必要はないということになる

　ここまではそれほど面白い話ではない。面白いのはここからだ。InterQoSでは、MPの構成のうち、RISCコアに関しては自社開発を止め、OpenCodes.orgで配布されているOpenRISCを採用した。これにより、開発環境はgccを始めとする多くのオープンソースのツールがそのまま利用できるし、周辺回路も(OpenCodes.orgで配布されている)さまざまなものが利用できるため、メリットが多いとしている。

　ここのDSPコアに関しては、自社開発のものをそのまま使うのか、それとも(例えばOpenRISC 1200で配布されている)フリーのDSPコアを使うのか明確にしなかったが、多分目的に応じてどちらも利用できるようにするというところだろう。

　DSPで必要な処理をうまくオフローディングできるなら、GPPには高い性能は不要である。であればライセンスがゆるく、それほど性能は高くないにしても消費電力の低いGPPで事足りる。無駄にロイヤリティなどを払わず、必要なら回路に手を入れることも可能なOpenRISCを使うというあたりは、なかなか興味深い選択肢である。今回は実装での規模も示されたが、Xilinxの「Virtex II 3000」で100MHz駆動、ASICを起こせば32PEの構成で200MHz駆動が可能としている。

プレゼンテーションを見ると“Complete free”が目立つが、講演ではむしろそれ以外のメリットを強調していた	そうなるとどこで金を取るかという話であるが、InterQoSの場合はDSPコアや(ハンドオプティマイズに匹敵する)自動チューニングツールの提供、あるいはシステム全体のチューニングということになる。こうしたIPの分野でも、設計そのものやライセンスではなく、サービスだけでペイするというビジネスモデルが本格的に動き始めている	回路規模としてはこんなものだろう。使われているRISCコアは恐らく「OpenRISC 1000」の方だと思われるが、コアの性能としては大体同クロックのARM7と同程度以上とされており、本格的な処理は無茶にしても、DSPのコントロールには十分程度だろう

　実はこれに先立ち、SPFの最初のセッションでIn-Stat/MDR(SPF2005の主催者)のTom R. Halfhill氏のOverview Presentationである“High-Performance Licensable-IP Processor Cores:Analysis”というセッションの中で、こうしたフリーのCPU Coreの話が出てきている。

　ここで挙げられたのはOpenRISCではなく、SPARC V8互換の「LEON3」というコアであるが、こちらもGNUに準拠したフリーなコアであって、CPUコア自体を販売するビジネスには大いに脅威とされている。プレゼンテーションの中では、現状はまだそれほどの脅威ではないとされているが、今回のInterQoSはまさしくスライド「Leon is Not a Significant Threat-for Now」に挙げられている項目をテーマにビジネスをしようとしているわけで、これがうまくいくかどうか、ちょっと楽しみではある。

LEON3はFPGAで125MHz、ASICにすれば400MHz以上で動作し、性能的にはARM9以上とも言われている	確かに組み込み向けにはこうしたサポートが必要ではあるが、SPARC互換にしたことで、ある程度のソフトウェアは既存のものを利用できるので、それなりに力のある会社ならばCPUのロイヤリティなしに製品を作れることになる。これは今後大きなトレンドになると予測されており、多くのIPベンダーは自社の長期戦略の見直しを迫られつつある

□SPF2005のホームページ(英文)
http://www.instat.com/spf/05/
□関連記事
【5月24日】Spring Processor Forum 2005レポート
～さまざまなDSP搭載プロセッサ(その1)
http://pc.watch.impress.co.jp/docs/2005/0524/spf05.htm
【5月23日】Spring Processor Forum 2005レポート
～組み込みプロセッサとしてのCell
http://pc.watch.impress.co.jp/docs/2005/0523/spf04.htm
【5月18日】Spring Processor Forum 2005前日レポート
http://pc.watch.impress.co.jp/docs/2005/0518/spf01.htm

(2005年5月30日)

[Reported by 大原雄介]