会場：Fairmont Hotel(サンノゼ)
会期：6月16～19日(現地時間)

　6月16日から19日まで(現地時間)の4日間、サンノゼはFairmont Hotelを会場に、Embedded Processor Forum 2003(EPF)が開催されている。昨年10月に、同じFairmont Hotelで開催されたMicroProcessor Forum(MPF)の姉妹編にあたり、どちらも主催はIn-Stat/MDR。スケジュール構成などもほぼ同じである。初日と最終日にあたる16日と19日はセミナーで、間に挟まれた17日と18日がカンファレンスにあたる。

　EPFとMPFは何が異なるかというと、取り扱うプロセッサの種類だ。MPFはx86やPower/PowerPC、SPARCといった、PCやサーバシステムなどで使われるプロセッサがかなり多い(そうでないものも結構あるが)のに対し、EPFは完全に組み込み用プロセッサに特化したものになっている。例えばカンファレンス初日に出てきたメーカーは ARM/MIPS/SuperH/TI/Infineon/NeoMagic/Octera といったあたりで、PCユーザーには、普段あまり縁のないプロセッサやDSP(Digital Signal Processor)が大集合といったイベントになっている。

　というわけで、まずはメジャーどころのARMの発表をご紹介したい。

●AMBA 3.0 ～よりBurst性能を上げる方向に～

英ARM SoC Degign Center ManagerのVruce Mathewson氏

　さて、今回ARMは妙に気合が入っていた。初日に3つの発表を行なったほか、ランチタイムにパネルディスカッションを開催したほど。もっとも、ランチを目の前にしながらディスカッションに聞き入る参加者はほぼ皆無。場内はディスカッションとフォーク/ナイフの音が見事な不協和音を醸し出しており、パネラーが何をしゃべってるかさっぱり判らなかった(笑)。

　ま、それはともかく。まずは同社のBruce Mathewson氏より、AMBA 3.0に関する話題が発表された。「AMBA」とは何かを理解していただくためにはココを見ていただくのが早いかと思うが、要するにARMコアベースのSoC(System on Chip)を作る際に利用される内部バスのスタンダードで、現在のRevisionは2.0。AMBAの実体は

・AHB(Advanced High-perfomance Bus):高速なペリフェラル同士やプロセッサを接続
・APB(Advanced Peripheral Bus):低速なペリフェラルを接続

からなっているが、3.0ではこれに加えてAXIと呼ばれるバス(厳密に言えばプロトコル)が追加になった。詳細はココ。

　このAXIを使うことで

・Outstanding Transaction【図1】
・Out of Order Transaction【図2,3】
・Data Interleaving【図4】

といった機能を利用できるようになった。これらはいずれも、バスの利用率を上げることができる。またAIXではバスの動作周波数も上げられるようで、特にSoCにおけるシステムパフォーマンスを引き上げる事に繋がる。単にCPUとメモリをつなぐだけならAHBでも十分なのだが(実際AHBはその程度のパフォーマンスである)、CPUと同じ位高速に動作し、メモリアクセスやI/Oアクセスを行なうコプロセッサがどんどん増えつつある現状では、AHBではすでにキャパシティが足りないということだろう。

　ちなみに先になぜ「厳密にはプロトコル」と書いたかというと、将来の発展形としてAIXのスイッチ【図5】も考えられるからで、しかもその際にMaster/Slaveデバイスのプロトコルは全く同じものになるそうである。つまりAIXの実体が、いわゆるShared-Busになるのか、Xbar-Switchになるのかというのは今後のインプリメント次第で変わるから、という事である。

　ARMもSoCにおけるトータルパフォーマンスを真剣に考慮しなければいけないほど、最近のSoCに対する要求性能が上がってきた、という現われなのもしれない。

【図1】データの到着を待たずに、次のリクエストを出せる(Outstanding)がサポートされた	【図2,3】アドレスとデータには、ユニークなIDをつけることになった。これを使うことでアドレスの発行とデータの送出が同じ順序である必要がなくなった

【図4】データを適当に分割して送出することもできるようになった	【図5】“AXI Multi-layer Bus Matrix”と称しているが、要するにAXIスイッチである

●Thumb2 ～16/32bit環境の混在～

発表を行なった、英ARMのCPU Architect、Vladimir Vasekin氏

　ARM9(厳密に言えばARM Version4)から追加されたものに“Thumb”と呼ばれる命令体系がある。これは16bit命令で、圧縮フォーマットになっていることが特徴的である。つまり、16bit命令ですむ処理に関しては、わざわざネイティブの32bit命令を使わなくても、このThumbを使うことで、プログラム密度を上げられ、消費電力を下げられ、しかも多少性能も上がるといういい事ずくめのフォーマットである。このThumbの影響は大きく、ライバルたるMIPS Technologyが(LSI Logicと共同で)MIPS16という圧縮16bit命令フォーマットをわざわざ用意する羽目になったほどだ。

　にもかかわらず、案外にこれが使われることは少ないらしい。理由はいろいろあるが、煎じ詰めると「16bit命令しか使わないなら、(32bitの)ARMプロセッサでなく、16bitプロセッサを使ったほうが安くて消費電力も少なくて……という事のようだ。

　このあたりの対策(?)として今回発表されたのが、新しい16bitフォーマットである“Thumb2”である【図6】。対策、というよりはむしろ新命令体系というべきかもしれない。Thumb2では16bit命令と(よく使われる)32bit命令を混在させ、さらにいくつかの命令を追加したという、16/32bitの混在環境になっているからだ【図7】。

　これによる第一のメリットは、モード切替が必要でないこと。Thumb命令はモード切替が必要で、この結果16bitと32bitの混在は非常に面倒なことになっていたのだが、これが一掃されている。ちなみにアセンブラレベルで言えば、フォーマット自体は既存のThumbと互換性があるため、移行は容易だとしている【図8】。

【図6】32bit ARM命令のメジャーなものと、16bitのThumb命令、それに新命令を追加したのがThumb2である。特徴的なのは、今後の拡張のための余地が残されていることである	【図7】hw1とhw2という識別情報で、Thumb命令なのか、Thumb2なのかが区別される

　第二のメリットは、追加された新命令により、分岐などが高速になったことだ

　こうした結果、Thumb2はThumb命令と32bit ARM ISAを統合したようなポジションに位置する。実行速度という点では32bit ARM ISAには及ばないがThumbよりは高速で、コード密度は一番高くなっている【図9】。また、ベンチマークによってはほとんど32bit ARM ISA並の成績を出しているケースもあり【図10】、要するにこれだけあれば16/32bitをまとめてカバーできるという話だ。このThumb2はARM V6のExtension(拡張)として提供されるという話で、将来のARM11に入るのか、それともARM12になるのかはまだ見えないが、ちょっと面白いことになりそうだ。

【図8】上の例は「値が0か(or 0でないか)」の判断、下の例はif-then-else分岐である。if-then-elseでは多少レイテンシが(32bitに比べ)大きくなる可能性はあるが、プログラムサイズは常に最小になっていることが判る	【図9】32bitをサポートする割に性能が低い気もするが、これは16bit命令での結果	【図10】こちらは32bit命令を多用した、EEMBCのBenchmark Suiteの結果。ほぼ32bit ARM ISAと並び、Thubmと比較して大幅な性能向上が得られている

●ARM IEM(Intelligent Energy Management) Technology ～省電力への取り組み～

英ARM Proncipal Research EngineerのKrisztian Flautner氏

　最後は一転して、省電力への取り組みである。今年のEPFでは、“Low Power Embedded Processor”というトピックがわざわざ設けられており、このトピックの中での発表となった。

　ことPCの世界では、積極的な電圧制御を行なっての省電力メカニズムはすでにあたりまえになっている。IntelのSpeedStepを皮切りに、AMDのPowerNow!やTransmetaのLongRun、VIAのLongHaulあたりがその例で、EmbeddedでもIntelなどは積極的にこうしたメカニズムをXScaleに取り入れている。ところが、ARM自体はこうした取り組みがちょっと遅れていた。

　その理由の一つは、電力制御の考え方がちょっと異なるためだ。「使ってない時はクロックと電圧を下げる」のは構わないわけだが、問題は「電圧とクロックを下げた結果、処理が一定時間内に終わらない」のでは困る用途が少なくないことだ【図11】。アプリケーションが異なれば、電圧の与え方も当然変わってくるわけで、このあたりを考慮しなければならない、としている【図12】。

【図11】理屈は簡単なのだが、どうやって電圧を定めるかが難しい	【図12】Acrobat ReaderとMP3デコード、サウンドコントロールという3種類のタスクを実行した場合のCPU利用率のプロファイル。特にサウンドコントロールの場合、処理自体は軽いが一定時間内に処理が終わらないといけないわけで、単純に電圧を下げて事足れりとはできないようだ

　一応今回、ソフトウェアとハードウェアの両面から電圧制御を行なうメカニズムの実装例が発表されたが、これで十分と思っているわけではないようだ。実際、今後の課題としてOSやソフトからのAPIのサポートや、ファブリケーション側の問題、必要ならOff-chipパワースイッチの利用も考えているそうで、まだまだ先は長そうだ。

　実のところ、先が長い理由はもう一つある。【図14】でもちょっと触れられているが、ARMはソフトコアを提供するのがメインな会社で、実際のチップの製造は複数のファウンダリで行なわれている。このファウンダリ任せなところが面倒なのである。つまりプロセスごとに電圧特性とか周波数特性などがかなり変わってくるから、ARM側では完全に制御しきれないというのが正直なところなのである。

　IntelやAMDなどがこれをモノにしている理由は、自社でFabを持ち、このあたりをFabにあわせて最適化しているからだし、TransmetaやVIAにしても、ファウンダリはTSMCのみと決めている以上、基本的にはそれほど面倒でない。

　ところがARMの場合、例えば【図13】で、PANIC信号のアサートにあわせてVccが急速に上がるわけだが、この上がる度合いはファウンダリやプロセスによって異なるし、その際にどのくらい急速にクロックを上げられるかも、やはりファウンダリやプロセスに依存することになる。こうなるとISRルーチンが起動されるまでの最悪値が保証できない(ファウンダリやプロセスによって異なる)という事になってしまう。レスポンス性能とかトランジション特性を無視すれば話は簡単なのだが、リアルタイム向けプロセッサにそれは許されない話で、このあたりが状況を難しくしているのは間違いなさそうだ。

　というわけで、いろいろ考えさせられたARMの発表だった。

【図13】下の4本の信号は、ソフトウェアから制御ができるもので、これを利用して電圧の制御ができる。それとは別に、ハードウェア的に急に電圧を上げるための信号ライン(PECPANIC)が用意され、これがアサートされたら(ソフト側の信号ラインとは無関係に)電圧を上げる事ができる。イメージとしては、IECPANICは割り込みコントローラと連動し、ISR(Interrupt Service Routine)が動作する時には自動的にアサートされ、割り込みが解除されたらネゲートするというところだろうか?	【図14】最後に出てくるNSのOff-chip Power switch technologyというのは、この発表の直前にNSが行った“PowerWise Adaptive Voltage Scaling Technology”というトピックと関連している。これはこれでかなり面白いので、別途紹介したい

□Embedded Processor Forum 2003(英文)
http://www.mdronline.com/epf/

(2003年6月19日)

[Reported by 大原雄介]