2003(EPF)が開催されている。Forum(MPF)の姉妹編にあたり、どちらも主催はIn-Stat/MDR。スケジュール構成などもほぼ同じである。初日と最終日にあたる16日と19日はセミナーで、間に挟まれた17日と18日がカンファレンスにあたる。EPFとMPFは何が異なるかというと、取り扱うプロセッサの種類だ。MPFはx86やPower/PowerPC、SPARCといった、PCやサーバシステムなどで使われるプロセッサがかなり多い(そうでないものも結構あるが)のに対し、EPFは完全に組み込み用プロセッサに特化したものになっている。Processor)が大集合といったイベントになっている。いうわけで、まずはメジャーどころのARMの発表をご紹介したい。Mathewson氏さて、今回ARMは妙に気合が入っていた。初日に3つの発表を行なったほか、ランチタイムにパネルディスカッションを開催したほど。ランチを目の前にしながらディスカッションに聞き入る参加者はほぼ皆無。場内はディスカッションとフォーク/ナイフの音が見事な不協和音を醸し出しており、パネラーが何をしゃべってるかさっぱり判らなかった(笑)。3.0に関する話題が発表された。Chip)を作る際に利用される内部バスのスタンダードで、現在のRevisionは2.0。Bus):低速なペリフェラルを接続からなっているが、3.0ではこれに加えてAXIと呼ばれるバス(厳密に言えばプロトコル)が追加になった。Interleaving【図4】といった機能を利用できるようになった。これらはいずれも、バスの利用率を上げることができる。AIXではバスの動作周波数も上げられるようで、特にSoCにおけるシステムパフォーマンスを引き上げる事に繋がる。CPUとメモリをつなぐだけならAHBでも十分なのだが(実際AHBはその程度のパフォーマンスである)、CPUと同じ位高速に動作し、メモリアクセスやI/Oアクセスを行なうコプロセッサがどんどん増えつつある現状では、AHBではすでにキャパシティが足りないということだろう。ちなみに先になぜ「厳密にはプロトコル」と書いたかというと、将来の発展形としてAIXのスイッチ【図5】も考えられるからで、しかもその際にMaster/Slaveデバイスのプロトコルは全く同じものになるそうである。AIXの実体が、いわゆるShared-Busになるのか、Xbar-Switchになるのかというのは今後のインプリメント次第で変わるから、という事である。ARMもSoCにおけるトータルパフォーマンスを真剣に考慮しなければいけないほど、最近のSoCに対する要求性能が上がってきた、という現われなのもしれない。【図2,3】アドレスとデータには、ユニークなIDをつけることになった。Version4)から追加されたものに“Thumb”と呼ばれる命令体系がある。これは16bit命令で、圧縮フォーマットになっていることが特徴的である。16bit命令ですむ処理に関しては、わざわざネイティブの32bit命令を使わなくても、このThumbを使うことで、プログラム密度を上げられ、消費電力を下げられ、しかも多少性能も上がるといういい事ずくめのフォーマットである。Logicと共同で)MIPS16という圧縮16bit命令フォーマットをわざわざ用意する羽目になったほどだ。かかわらず、案外にこれが使われることは少ないらしい。理由はいろいろあるが、煎じ詰めると「16bit命令しか使わないなら、(32bitの)ARMプロセッサでなく、16bitプロセッサを使ったほうが安くて消費電力も少なくて......という事のようだ。このあたりの対策(?)として今回発表されたのが、新しい16bitフォーマットである“Thumb2”である【図6】。対策、というよりはむしろ新命令体系というべきかもしれない。Thumb2では16bit命令と(よく使われる)32bit命令を混在させ、さらにいくつかの命令を追加したという、16/32bitの混在環境になっているからだ【図7】。これによる第一のメリットは、モード切替が必要でないこと。Thumb命令はモード切替が必要で、この結果16bitと32bitの混在は非常に面倒なことになっていたのだが、これが一掃されている。ちなみにアセンブラレベルで言えば、フォーマット自体は既存のThumbと互換性があるため、移行は容易だとしている【図8】。ARM命令のメジャーなものと、16bitのThumb命令、それに新命令を追加したのがThumb2である。ISAを統合したようなポジションに位置する。ISAには及ばないがThumbよりは高速で、コード密度は一番高くなっている【図9】。ISA並の成績を出しているケースもあり【図10】、要するにこれだけあれば16/32bitをまとめてカバーできるという話だ。V6のExtension(拡張)として提供されるという話で、将来のARM11に入るのか、それともARM12になるのかはまだ見えないが、ちょっと面白いことになりそうだ。0でないか)」の判断、下の例はif-then-else分岐である。最後は一転して、省電力への取り組みである。Processor”というトピックがわざわざ設けられており、このトピックの中での発表となった。ことPCの世界では、積極的な電圧制御を行なっての省電力メカニズムはすでにあたりまえになっている。IntelのSpeedStepを皮切りに、AMDのPowerNow!やTransmetaのLongRun、VIAのLongHaulあたりがその例で、EmbeddedでもIntelなどは積極的にこうしたメカニズムをXScaleに取り入れている。ところが、ARM自体はこうした取り組みがちょっと遅れていた。その理由の一つは、電力制御の考え方がちょっと異なるためだ。「使ってない時はクロックと電圧を下げる」のは構わないわけだが、問題は「電圧とクロックを下げた結果、処理が一定時間内に終わらない」のでは困る用途が少なくないことだ【図11】。アプリケーションが異なれば、電圧の与え方も当然変わってくるわけで、このあたりを考慮しなければならない、としている【図12】。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)が用意され、これがアサートされたら(ソフト側の信号ラインとは無関係に)電圧を上げる事ができる。Technology”というトピックと関連している。個別にご回答することはいたしかねます。