물리층에 PCIe Gen2을 사용하는 것으로, 링크 속도는 500MB/sec을 확보하는 목적은 섰지만, 그 상위를 어떻게 할 것인가? 이라고 하는 것이 다음 되는 문제다. USB 1.1/2.0의 프로토콜을 그대로 구현하는,이라고 하는 안은 비교적 빠른 시기에 포기된 것 같다. 이유는

·전이중통신이 가능한 USB 3.0로, 반이중통신을 기초로 한 USB 1.1/2.0의 프로토콜을 사용하는 것은 낭비가 지나치게 많다.

·반이중인 것을 제외해도, 처음부터 USB 2.0의 통신 방식에는 낭비가 많으므로, 이것을 생략하고 싶었다.

·성전력을 위한 구조를 USB 1.1/2.0에서는 구현하고 있지 않고, 이것을 추가로 구현하면, 기존의 USB 1.1/2.0의 프로토콜과의 호환성이 손상되는 가능성이 높다. 그것이면, 처음부터 새 프로토콜을 구현한 쪽이 더 빠르다.

이라고 하는 부근과 생각된다. 1개째와 세번째에 대해서는 비교적 이해하기 쉬울 것이지만, 두번째에 대해서는 조금 설명이 필요하자.

　도1은, USB 2.0의 경우의 패킷의 교환의 예를 제시한 것이다. 여기에서는, USB HDD와 같은 것으로부터 데이타를 읽어내는 케이스를 생각해 본다.

　USB에 있어서, 모든 디바이스는 자발적으로 동작을 행할 일은 없다. 이것 때문에, USB호스트측에서의 리퀘스트를 받고, 처음으로 동작하게 된다. 이것 때문에, 호스트에게서 「있는 블록을 읽어내서 호스트에게 전송해라」라고 하는 요구(I/O Req)이 우선 호스트에게서 디바이스에 보내진다. 이것을 받은 디바이스는 「그 명령을 받았다」라고 말한다 ACK을 되돌리고나서, 실제로 자신의 디바이스의 액세스를 행하게 된다.

　그러나, HDD액세스에는 당연 그나름의 시간이 걸리게 된다 (그것이 어느 정도 회부될 것인가,라고 하는 것은 디바이스I/F는 물론 호스트도 모른다). な 의에서, 디바이스가 실제로 HDD액세스를 걸고, 데이타를 받아들이고 있는 사이도, 호스트는 정기적으로 「이미 데이타의 전송 준비를 할 수 있었는가? 」이라고 하는 질문(Result Request)을 디바이스I/F에 대하여 계속해서 보낸다. 물론 액세스의 한창은 아직 준비가 되어있지 않으므로, 이 경우 디바이스는 호스트에게” NRDY(Not ReaDY)”을 매회 돌려 보내는 셈이다.

　일간에 HDD로부터의 읽어내기가 종료, 호스트에게 돌려 보내는 준비를 할 수 있으므로, 그 다음에 온 Result Request에 대하여 디바이스는” RDY(ReaDY)”을 돌려 보낸다. 이” RDY”이 돌아오면, 처음으로 호스트는 데이타의 전송 요구(Xfer Req)을 디바이스에 보내고, 이것을 받아서 디바이스가 DATA를 되돌리는 라고 하는 것이다. 여기에서 아는 대로, USB에서는 전송을 폴링으로 감시하고 있기 때문에, 이것에 따른다 CPU의 부하가 무시할 수 없다.

　USB HDD를 사용할 때에 지독히 CPU부하가 걸리는,이라고 느껴지는 사람은 제법 있었다고 생각한다. 필자의 경우, 힘이 약한 머신(Core Solo 1GHz를 탑재한 후지쯔(富士通)의 LIFEBOOK U)에 USB 2.0대응의 마우스를 접속하면, 갑작스럽게 CPU부하가 건으로 올라가버려, 오히려 쓰기가 떨어져버린다라고 하는 경험을 한 것이 있지만, 그 이유의 대부분을 차지하는 것이 이 폴링 라고 하는 것이다.

　더해서 말하면, USB 2.0에서는 호스트와 모든 디바이스가 사실상 1개의 공용 선으로 연결되어 있는 모양이 된다. 그러므로, USB HDD의 폴링중은, 다른 디바이스가 전송을 행하거나 할 수 없는 셈이어서, 이것도 프로토콜상은 낭비가 많다.

　그러면 USB 3.0에서는 어떻게 될 것인가? 이라고 하면, 도2과 같은 전송이 가능해진다. 우선 I/O리퀘스트를 호스트에게서 디바이스에 보내는 것은 함께이고, 그 후 1회 호스트에게서 디바이스에 Result Request를 보내는 곳도 함께다. 문제는 그 앞이다. 호스트측은, 한번 NRDY가 돌아오면 나머지 일은 그 상태로 대기하게 된다. 한편 디바이스측은 그대로 HDD액세스를 행하고, 필요한 데이타를 취득한 단계에서 호스트에게 변경해서 RDY를 보낸다. 이것을 받아서 호스트는 Xfer Req를 전송, 이것의 대답이라고 하는 형태로 디바이스로부터 읽어낸 데이타가 보내지게 된다.

【사진1】Protocol Layer의 신기능.전회의 도에서 말하면, 위에서 2번째, Transaction층에 관계되는 부분이다

　이방식에 의해, USB 3.0에서는 CPU부하를 극적으로 줄이고, 이기는 전송 효율을 대폭 올리는 것에 성공했다. PCIe에서는 이것을 「Asynchronous notifications」라고 칭한다 (사진1). 보통 Asyncronous notifications에서는, 통상의 데이타 선과는 달리 새치기 통지를 행하기 위한 Interrupt Line을 준비하고, 이것을 사용해서 통지를 행한다 (PCI라든가 ISA등이 이 대표 예)방식을 취한다. PCIe의 경우, 새치기 선은 준비하지 않는 대신에 이러한 비동기통신 전용 패킷을 준비하고, 새치기등은 이쪽을 사용한다고 하는 형태로 구현하고 있지만, USB 3.0에서는 NRDY와 RDY를 조합시키는 형태로 이것을 실현되고 있는 부근이 smart하다.

　게다가 이것을 응용하는 형태로, Out of order completion도 구현되었다. 이것은 무엇인가? 이라고 하면, 도3과 같은 전송이 가능하게 되었다고 하는 것이다. 도2에서는 전송 명령이 1개만이었지만, 이 다음에는Req 1∼Req 3이라고 하는 3개의 읽어 냄 요구를 차레로 투입하는 것을 생각해 본다. USB 2.0의 경우에서는, 도1이 3개 sequential에 늘어선다 (끝 소요시간은 단순에 3배) 모양이 되지만, USB 3.0로 먹지 않고 통합해서 3개의 리퀘스트를 순차 투입하는 것이 가능하다. 에서, 이 리퀘스트는 순차 HDD에 투입되는 셈이지만, HDD측도 SATA라고 NCQ를 지원하고 있는 가능성이 있기 때문에, 그렇다면 반드시 넣은 순서대로 데이타가 나온다고는 할 수 없다. 그렇다고, 넣은 순서지게 사이에 buffer를 씹게 하는 것도 보틀넥(bottleneck)이 늘어나는 것 뿐이다.

　거기에서 USB 3.0에서는, I/O가 끝난 순서대로 이것을 되돌리는 것이 가능하다. 도3의 예로 말하면, Req 2에 대응한 I/O # 2이 조금 시간이 걸리고, 먼저 Req 3에 대응한 I/O # 3이 끝난 케이스를 상정하고 있다. 이 경우, 디바이스는 각각의 I/O가 끝난 타이밍으로 호스트에 대하여, 각각의 RDY를 그자리에서 되돌릴 수 있다. 이것에 따라서 호스트는, Req 1→Req 3→Req 2이 순서서 Xfer Req를 발행하고, 각각의 결과를 받는 라고 하는 것이다.

　이러한 메커니즘이 가능하게 된 것은, 처음부터 송수신을 분리할 수 있었던 것과, 또 하나는 Peer-to-Peer에서의 접속 형태에 바꾼 것이 크다. USB 2.0의 경우, 송신과 수신이 1개의 선에서 공용되어 있었기 때문에, 송수신이 부딪치지 않도록 호스트가 USB의 트리 전체를 관리하고 있어, 이 결과로서 디바이스로부터 호스트에게 「자발적으로」 데이타를 보내는 것은 불가능했다. 그런데 USB 3.0에서는 송신과 수신이 분리되었으므로, 호스트가 데이타를 보내고 있는 한가운데라도 디바이스로부터 데이타를 보내는 것이 가능하게 되고 있다.

　또 하나 중요한 것이, Peer-to-Peer의 접속이 되고 있는 것이다. 이것은 물리적인 이야기라고 하는 것 보다도 논리적인 이야기다. 예를 들면 도4과 같은 구성을 생각해 보자. 여기서 호스트가 있는 리퀘스트를 디바이스1에 보내자로 한다. 그 경우, 호스트는 리퀘스트를 Root Hub(호스트 안(속)에 있는 빨간 원)에 보낸다. 그러자 무조건으로 Root Hub은 그 리퀘스트를 부하의 전 포트에 보내고, 게다가 그 부하로 있는 Hub도 역시 전 포트에 복사해서 보내므로, 결국 도5과 같이 브로드 캐스트(broadcast) 하고 있는 것과 같게 된다. 물론 각 디바이스는 받은 리퀘스트의 보낼곳을 보고, 자신앞이 아니면 파기하기 때문에 실해는 없는 것이지만. 반대로 리퀘스트에 대한 리스폰스에 관해서는, 보낼곳이 호스트해 이루어져 (USB에서는 디바이스→디바이스라고 하는 전송은 원칙으로서 불가능하다. 이것이 가능한 것은 USB On-The-Go라고 하는 별규격이다)로부터 도6과 같이 낭비에 Broadcast 할 일 없고 전해 진다. 단, USB 2.0에서는 복수의 디바이스가 동시에 Response를 되돌리는 것은 (당연) 상정하지 않고 있으므로, Hub의 스펙에도 이러한 기능은 담아지지 않고 있다

　이것에 대하여, USB 3.0에서는 브로드 캐스트(broadcast)가 원칙으로서 폐지되었다 (전 디바이스에 통지를 행할 필요가 있는 PowerDown이라든가 Reset와 같은 관리용에, 전용의 브로드 캐스트(broadcast)의 모드가 일부러 신설되었을 만큼이다). な 의에서 호스트→디바이스도 디바이스→호스트도, 기본적으로는 항상 Peer-to-Peer가 되고, 관계 없는 디바이스에 대하여 낭비에 패킷을 보내버릴 수 있는 것은 없어졌다. 이것 때문에, USB 3.0의 Hub은 빈틈없이 보낼곳을 보아서 라우팅하는 것 이외에, 복수의 포트로부터 호스트에 적합한 패킷을 받았을 경우, 이것을 정확히 취급할 수 있도록 하는 것도 의무화할 수 있었다. 이 부근은 (조금 예가 낡지만) Ethenet의 Hub에 가깝다. 옛날의 Ethernet는 소위 Dumb Hub에서, 자신이 있는 포트에서 받은 패킷을 무조건으로 다른 패킷에 보낸다고 하는 구조이었다. 그런데 switchingHub이 등장하고, MAC어드레스를 보아서 원하는 포트만에 보내게 되었다. USB 3.0의 Hub의 동작은, 이 switchingHub에 가까운 동작이 된 셈이다.

　이러한 구조는, 동시에 성전력에도 연결되게 된다. 디바이스→호스트 방향 야(이야) 여하튼 호스트→디바이스는, 종래라고 모든 포트에 패킷을 보내고 있었던 셈이지만, USB 3.0에서는 원하는 포트에만 패킷을 보내는 형태에 바뀐 셈이어서, 쓸데 없는 전력을 소비하지 않는다라고 하는 관점에서 개선되게 된다.

　이러한 기능을 탑재하기 위해서는 USB 2.0까지로부터 프로토콜을 일신 할 필요가 있었지만, 그렇다고 PCIe의 프로토콜을 사용해버리면, (이미 PCIe의 IP을 가지고 있는 벤더에는 편하지만) 구현이 귀찮은 일,이라고 하는 문제가 있었다. PCIe의 프로토콜은, 최대 32래인(lane)에서의 전송에도 견디어낼 수 있게 설계되고 있어, 또 유연한 구성을 취하기 위해서 상당히 복잡한 것이 되고 있었다. 그 으뜸인 것이 플로우 제어다.

　PCIe에서는 「Credit Base Flow Control」이라고 불리는 것이 이용당하고 있다. 이것은 간단히 하면 「전송을 시작하기 전에, 얼마만큼 통합해서 전송을 실시할 수 있을지를 확인하고, 전송후는 그 몫을 さっぴく」이라고 하는 것으로, 이 관리에 사용되고 있는 것이 Credit라고 불리는 것이다. (꼭)정확히 현금카드의 신용관리 같은 것이라고 생각하면 좋다. 실제로 상품을 구입하기 전에, 크레디트 카드 회사에 크레딧 라인이 남아있을지의 확인이 행하여 지고, 구입후에는 크레딧 라인으로부터 그 몫이 줄여진다. 에서, 사용한 분을 지불하면, 크레딧 라인이 부활한다고 하는 것이다. 이것을 실현되기 위해서, PCIe에서는 트랜잭션층과 링크층의 양쪽에 걸치는 형태로 플로우 제어가 구현되었다.

　당초 USB 3.0은 이 구조를 있는 정도 가져오는 형태로 생각하고 있었던 것 같지만, 구현의 부하가 예상이상으로 대단하다고 판단된 것 같다. 이 결과 USB 3.0에서는 「buffer를 4개 탑재한다」라고 말하는 정해 치기의 플로우 제어가 채용되었다. 각 포트마다 반드시 4개의 수신 buffer가 마련되어져, 송신측은 4개까지는 단숨에 보내도 좋지만, 그 후는 buffer가 열린 것을 확인하고나서 송신하는,이라고 하는 구조가 구현되어 있다. 이것에 의해 플로우 제어는 트랜잭션층뿐으로 구현이 완결했다.

　그 몫 링크층은 부하가 줄어들었다고도 말할 수 있는 것이지만, 그 대신에 Link Training에 신기능이 추가되었다. PCIe의 경우, (이제 곧 Gen3도 등장하지만) 지금으로서는 Gen1/Gen2의 어느쪽인가에서 통신하는 패턴만을 생각하면 좋은 것에 대해, USB 3.0에서는 「상대가 USB 3.0에 대응하고 있는 것인가 아닌가 모른다」라고 할 가능성이 있다. 이것은 USB 3.0의 호스트에게 USB 2.0디바이스를 연결할 경우나, 반대로 USB 2.0호스트에게 USB 3.0디바이스를 연결할 경우에 들어 오는 이야기다.

　특히 후자의 경우, 상대가 종래의 USB 2.0호스트인채로 이기 때문에, 「우선 USB 3.0에서의 통신에 트라이하고, 안 되면 USB 2.0의 통신에 트라이한다」를 유장에 행하고 있다고, USB 2.0에서의 통신에조차 실패할 가능성이 있고, 잘못하면 전력이 늦을 가능성이 있다. USB 2.0의 호스트는 포트당 최대 500mA를 공급할 수 있을 것이지만, 버스 파워의 USB Hub에서는 100mA이하밖에 공급되지 않을 경우도 있다. 한편 USB 3.0에서는 포트당 최대 900mA가 가능하고, 현실문제로서 100mA정도에서는 USB 3.0의 물리층이 전력부족으로 오 동작할 가능성도 있다. 거기에서 USB 3.0의 신호 수준에서의 통신에 앞장서고, LFPS(Low Frequency Periodic Signaling)이라고 불리는 방법으로 handshake를 행하고, 여기에서 성공하면 USB 3.0에서의 통신을 시험한다고 하는 구조가 받아들여졌다. LFPS는 이름 대로 신호의 속도도 늦게, 성전력으로 동작가능하기 때문에, 100mA정도의 공급이 있으면 충분히 동작하는 라고 하는 것이다.

　이러한 여러 가지의 기능 추가나 변경이 행하여 진 결과, USB 3.0의 구현은, 「PCIe Gen2 x1래인(lane)의 물리층+USB 2.0의 논리층」이라고 하는 수준의 물건이 아니고, 「PCIe Gen2 x1래인(lane)의 물리층을 바탕으로 한 독자물리층+PCIe의 논리층을 본보기로 한 트랜스포트층+USB 2.0을 자주(잘) 닮은 인터페이스」라고 말하는 모양이 되었다. 이 부근을 자주(잘) 근거로 한 있는 벤더는 「확실히 당사는 PCIe의 물리층의 IP도 가지고 있고, USB 2.0의 controller나 디바이스의 IP도 가지고 있지만, USB 3.0은 전혀 다른 것이므로, 지금으로서는 손수 다룰 예정은 없다」라고 2008년경 함께 이야기 하고 있어, 실제로 이 벤더는 아직도 USB 3.0에 참여하지 않고 있다. 겉보기보다 난이도가 높은 것이 이 USB 3.0의 구현이라고 말할 수 있자.