○承前 - 打ち合わせってのはこんなもんです

NuCoreの連載もぼちぼち終わりが見えてきたなぁ、というある日の事。どこぞの発表会の帰り、編集部のW氏と蕎麦を食べながら「次は何にしましょうかねぇ」なんて話をしていた。

「んー、ちょっとNuCoreでPCから離れてちゃってますし、このあたりで普通のPCの話に戻りませんか?」
「普通のPCっていってもねぇ、んじゃCPUの中のフリップフロップ回路について熱く語るとか」
「いやあの、もう少しマクロな話を。こう、例えばバスなんてどうですか? 最近色々なバスが出てきて判りにくいですし」
「バスねぇ。んじゃ、S-100バスから順に説明してゆくとか」
「いやあの、もう少し最近のものから始めていただけると」
「XTバス?」
「いや、もう少し現在の」

大体において打ち合わせなんてこんなもんである。まぁこうした真剣な(?)打ち合わせの末、バスについて少し語ってみようという事になった。お付き合いいただければ幸いである。

○History - 繰り返すトレンド

「バス」を広義に捉えると、「デバイスとデバイスを繋ぐインタフェース」という事になる。ただ、狭義に捉えると「複数(3つ以上)のデバイスを繋ぐインタフェース」という解釈もありえる。つまり、Point to Point接続はバスと呼ばない、という考え方である。このあたりはこの後の議論でゆっくり触れてゆくとして、とりあえずトレンドを見てみると
・SerialとParallel
・SynchronousとAsynchronous
・PacketingとBurst
・Sequential TransactionとMulti Transaction
etc...
と、バスを規定するパラメータがたびたび入れ替わることが特徴である。例えばPCの拡張バスを考えてみよう。XT Bus(8bit)→AT Bus(16bit)→EISA Bus(32bit)という進化は、ひたすらバス幅を増やす方向の進化だったから、これは素直にParallel化と捉えられる。ところがEISA Bus→PCI Busの場合、動作速度の高速化(8MHz→33MHz)やMulti Transaction(Delay Transaction など)、それに一部のPacketingが含まれる。さて、ここからPCI Expressへ進化する際、Parallel→Serialの変化が起きている。

つまり、33MHzの信号線を32本並べる代わりに、2.5GHzの信号線1本に集約するという方式である。ところがPCI Expressの場合、1本の実効転送レートは125MB/secでしかなく、これでは全然スピードが足りない。そこでどうするかというと、またもやSerial→Parallelの変換である。つまりPCI Expressの信号線を複数本並べて同時に転送する事でトータルの転送速度を稼ぐという仕組みで、こうなると何がSerial Busなのか全然理解できなかったりする。ちなみPCI Expressは今後10年程度の間、主要なインタフェースの座につく事がほぼ約束されているが、その後となると、もはや銅配線を使っての接続は難しいと考えられている。

これに向けて、光インターコネクトの研究が進んでおり、適切な光送受信モジュールさえあれば1～2桁の高速化が可能といわれている(実験室レベルでは100Gbpsオーバーはあたりまえだし、バックボーン向けに10Gbpsクラスのモジュールは既に商品化されて広く利用されているが、コンシューマ向けに考えると現状では大きさとコストが論外なレベルである)。恐らくこれが実用化される頃には、PCI Expressは5GHz動作で8xもしくは16x、つまり信号で言えば16bitもしくは32bit幅が一般的になっていると思われ、ここでまたParallel→Serialの遷移が発生するという次第だ。こうした繰り返しが、バスには良く見られる。

似たような話は他にもある。元々は68Kのバスとして使われていたが、その後は工業用の汎用バスとして広く利用されるようになったVME Busの場合、昔はAsynchronousモードで、その後Synchronousモードが追加されたわけだが、当初、Asynchronousモードの特徴の説明はというと「Asynchronousだから高速」だったのが、Synchronousモードが追加されるときには「Synchronousだから高速」に変わっており、あまりの豹変振りに笑った記憶があるのだが、こうした話は珍しくない。技術が進化するにつれ、当時は合理的だった方式が非合理的になってしまい、こうした交代が発生する。

この例にしても、原理的にはAsynchronousの方が高速なのである。Synchronousの場合、どうやっても1クロック分の時間単位での動作となるから、例えば0.5クロック分でトランザクションが終わったとしても1クロック分待たされる訳で、この点では、無駄に待たないAsynchronousの方が高速に動作する「可能性がある」。が、実際にはバスインタフェースもSynchronous回路で動作しているから、バスだけAsynchronousで高速化してもインタフェースが追いつかないし、むしろAsynchronousで必要とされるハンドシェイクのハンドリング(Synchronousだと、例えば2クロック待って処理を始めるという事ができるが、Asynchronousではこうした処理は不可能なので、いちいち通信ハンドシェイクが必要である)がオーバーヘッドになる可能性の方が高い。ただ、将来仮にAsynchronous回路が普及したら、今度はAsynchronousのバスが普及し始める可能性が高いといった話だ。

こうしたバスの様々な特性に関し、切り口を色々変えながら順に紹介して行きたいと思う。

バックナンバー
http://pcweb.mycom.co.jp/column/sopinion.html