力技で分離した結果どうなったか、というと信号線が倍増することになった。図1はUSB 1.1/2.0の場合の配線の模式図である。USB 1.1/2.0では信号線が一対と、他に電源供給用に5Vが提供される関係で、ケーブルは4本の信号線から構成されることになる。これがUSB 3.0になると、SSTX(送信)とSSRX(受信)で各一対、それとUSB 3.0の信号専用にグランドが追加されたわけで、信号線は9本にまで膨れ上がる(図2)。
Photo01は、USB 2.0のケーブル断面図、Photo02がUSB 3.0のケーブル断面図となるが、ご覧のとおり配線がより複雑化している事が判る。通常のケーブルでは問題ないだろうが、いわゆるスリムケーブルの類はUSB 3.0向けに作るのは中々困難になるだろう。
Photo01: Universal Serial Bus Specification 2.0のFigure 6-11より抜粋 |
Photo02: Universal Serial Bus Specification 3.0のFigure 5-15より抜粋 |
話を戻すと、こうした形でUSB 3.0に関しては信号を完全に分離したわけだが、この配線はPCIe Gen2 Cableを基本にしてはいるものの、実は完全に一緒ではない。というのは、例えばPCIe x1の場合であっても必須の配線は信号そのもの以外に、
- CREFCLKp/CREFCLKn: 受信側(Downstream)のPLLに供給するクロック信号。これもDifferentialなので、2本となっている、
- CPRSNT#: ケーブルの存在確認(Present)を示す信号。ケーブルが抜けていると、これがHighになる。
- CPERST#: リセット信号(Platform Reset)を示す信号。
- CPWRON: Cable Power Onを示す信号。
- SB_RTN: Sideband Returnを示す信号。
- CWAKE#: Cable Wakeを示す信号。システムがPower ManagementでWAKEをサポートする場合、必須となる。
オプション扱いが、
- +3.3V Power: これはケーブル経由で3.3Vを供給するためのもの。
- PWR_RTN: +3.3V Powerを使う場合のRetual Path。
といった配線が用意される。このうちCREFCLKについてはもう少し説明が必要だろう。PCI Expressでは、データの送受信そのものには外部のClock Sourceを必要としない。8B/10B Encodingを使って、データ信号そのものにClockを埋め込んでいるからだ。そのため、Clockを使わずにSynchronous Transferが可能になっている。
それはいいのだが、送信側の8B/10B Encoderや受信側の10B/8B Encoder(というか、10B/8B Decoder)は、(タイミングがずれている事は構わないが)同じ周波数で同期して動作しないと正しくデータが受け渡せない事になる。そこで通常送信側がReference Clockと呼ばれるClock Sourceを用意し、これを送信側と受信側の両方に供給する形になる。このReference Clockを送るのがCREFCLKn/pにあたる。他にもResetだのWakeだのといったものは、TLP/DLPの形で送るのではなく、別途信号線を用意して充てており、こうした結果PCIe Cableではx1の場合でも18ピンのコネクタが使われる事になっている。
が、こんなに大量の信号線は当然USB 3.0では収まりきらない。このためUSB 3.0ではPCIe Cabelをベースにしつつも、
- Reference ClockはHost/Device/Hubが自前で持つ。
- 制御信号は全てパケットの形で送る。
という形にすることで、必要な信号線をデータの二対(と、Common GND1本)で済ませる事ができるようになった。このあたりはUSB 2.0と同じ発想である。
話を戻すと、こういう形で配線を分離したため、当然ながら中間に入るHubに関してはちょっと面倒な事になった。図3はHubが間に入った場合のケースだが、Hub内部も当然ながらUSB 1.1/2.0と3.0で別々に構成を行う必要がある。加えて、1.1/2.0は原則としてリピータで構成すれば良い事になる。というのは、
- Downstream(Host→Device): 全てのDeviceにBroadcast。
- Upstream(Device→Host): 全てのMessageはHostのみに転送。
という形になっているからだ。ところがUSB 3.0ではDownstream/Upstream共に1:1での通信となるため、特にDownstreamの場合、HubはHostから来たMessageの宛先を見て、適切なDeviceにそれを送り出すというSwitchの動作が必要になる。
(続く)