SoCの時代に何が大事か．
SoCを含め現代の回路設計で一番(?)大事なのはバスらしい．一番大事なのかはともかくバス周りが悩みの種になっているのは間違いない．

個々のモジュールの演算性能がどんなに高くても，それを繋ぐバスが混み合っていてはデータの入出力がままならず，性能は発揮できない．特に最近は動画像等といった帯域を猛烈に必要とする場合が多い．せっかく高性能のコーダを組み込んだのにバスが混みあっていてデータの入力が追いつかないなんて事は十分ありうる．

例えばちょっと古い事例だがEmotionEngineの内部バスはこんな風になっている(後藤弘茂のWeekly海外ニュースより)．128ビットCPUコアと巨大なベクトル処理ユニット2基と画像デコード用のIPUが128ビットバスに接続している．詰め込めるだけ浮動演算ユニットを詰めたといえるこのEEの浮動小数点のピークは6.2GFLOPSと言われている．が，その性能を出すためには勿論絶え間なくVPU0,VPU1にデータをメモリから転送し続けなくてはならない．当然CPUコアもキャッシュミスを起こしたりライトバックでメモリへアクセスしに行く．さらにIPUでも動かそうものならもうバスの大混雑は確実である(私予想)．そのためCPUコアにはSPRAMという内蔵メモリがあったり，CPUコアとVPU0，VPU0とVPU1にPoint to Pointぽいバスがあったりして，メインストリートの混雑を避けるような細工がしてある．

これは回路設計の観点から見れば至極真っ当な方法である．しかしながら，潜在能力が高まったことは確実でも，この複雑なモデルはソフトウェア設計の立場から言えば最悪である．例えばVPUへのデータ転送はDMACによって行うことになっているのもその一つだ．回路設計者から言えばいちいちVPUからCPUに割り込みをかけてもらってメモリ転送するのはCPU資源の無駄である．何故ならCPUコアはキャッシュがヒットしている間は大人しくローカルバスの中で完結しているので，その間にDMAがメインメモリからVPUへメモリを転送してくれれば動作が並列になる．それにCPUで割り込みを受け付けてからメモリ転送するのは，コンテキストスイッチ等も含めて無駄な時間が生まれる．なので，DMACを駆使して周辺モジュールへデータの供給を行うという発想はバスの使用効率を高めるという点で良い．

しかしながら，これはプログラマにとっては得体の知れないDMACを仕様書を睨みつつ操作するという面倒なことになる．もしPIO転送で済むなら，VPUのIOの番地だけ知っていれば済むことなのに…VPUだってプログラマから見れば同様に得体の知れないものだ．このプログラミングはソフトウェアの本質から外れていると感じられるだろう．
SPRAMやその他の特殊な仕掛けも同様でソフトウェアプログラマにとってはウザいだけのものかもしれない．なぜウザいと感じるのかと言えば，一般的なソフトウェア言語というものは結局フラットなメモリとそれに対する演算をモデル化しただけの単純極まりないものだからである．このため特定の処理に特化したハードは，シンプルなソフトウェア元来のモデルと乖離してしまい，匠の領域に到達しないことには殆ど制御不能になってしまうのである．

これを回避するには，単純にそういったソフトから見た特殊な仕掛けを隠してしまうライブラリを用意すれば良い．
それか，うまいことペリフェラルやバス構成をソフトウェアと親和性の高い形でモデル化すればいい．普通コンパイラってCPUコアに対応するわけだけど，ペリフェラルを含めたものを大きなCPUと考えてコードを吐くコンパイラがあれば面白い．CPUだって制御回路がALUやレジスタファイルにどうデータを流し込むかを決定するのだから，一段枠を大きく考えればCPUはペリフェラルにどうデータを流し込むかを決める制御装置だ．なんとかなるんじゃない？ならない？ならないか．普通にライブラリ書いたほうがいいか．いいかも．よく分からん．

あと僕はPS2のプログラムの経験は全くなくさっきのブロック図しか知識がないので，結構適当なこと書いてますので，そこのところよろしくお願いします．


さらに関係ないけど，こういったバスの設計は高密度化した都市部の効率的な輸送網の設計と似てるよね．どこに線路引いてどう電車を走らせようか，みたいな．久しぶりにSimutransしたくなってきた．

暖かくなってまいりました． 最近うちではゴキブリの赤ちゃんをよく見かけます． これくらいのサイズなら指先ひとつでダウンさせられるので楽です． というか，どこで繁殖してるんだこいつら． 近日，隠れ家を暴いて全員アウシュビッツ送りにします．