USB 3.0の研究(23)

• U3(Photo01)

U3はDeviceがSuspend stateに入る時に利用されるStateとなる。この状態では、U2と比べても一層の省電力化が可能になる一方、復帰までの時間は更に長くなる。Photo01に示す通り、U3もまたSubstateを持たない。

とはいえ、完全にLink Downには至らないのがU3である。VBUSの供給が経たれる(＝配線が抜かれる)場合にはSS.Disabledに遷移するし、DSP側の先のDeviceの状態に変化があればRx.Detectに遷移するが、LFPSのプロトコルだけはちゃんとハンドリングすることが求められている。ただしU3 Stateにおいては、LFPSのWakeupのためのTransmitter Timingが最小80μs、最大10msと長めにとってある。実際Linkの片方がWakeup Handshakeを始めて、相手側がそれに応じるまでの時間は、U2の場合2msなのに対しU3では合計20ms以内という事になっている。ここまで待機時間を長く取れば、例えばLFPSのハンドリングのみを8bitのMCUにやらせるなんて事も出来るだろうし、ハードワイヤードロジックならば相当動作周波数を落とす事も出来る。

ちなみにLFPS Wakeup HandshakeがTimeoutした場合、U3では100msのディレイを入れた後に再びWakeup Handshakeに入る事になっている。Linkの両側がWakeup Handshakeに入れば、そのままRecoveryに遷移する形になる。

• Recovery(Photo02)

U0～U3において、LFPSのWakeup Handshakeが成立した場合に遷移する先がこのRecoveryとなる。RecoveryはいくつかのSubstateを持つが、戻らない(一方通行)という意味ではPollingなどに近い構造である。

RecoveryではまずRecovery.Activeに入る。ここでは12msのタイマーをStartした上で、TS1の送信とTS1/TS2の受信に入る。このあたりの仕組みは、294回目で説明したPolling.Activeと同じである。ここで問題なくTS1の送受信が出来ればRecovery.Configurationに遷移するし、ここで失敗すればSS.Inactiveに、相手側がLink Downに入ればSS.Disableに遷移することになる。

次がRecovery.Configurationで、ここもやっている事はPolling.Configurationに同じだ。今度はTS2を使ってお互いに設定を交換することになる。ここで正常にすればRecovery.Idleに遷移するし、それ以外のケースであれば条件によってSS.InactiveやSS.Disabledに遷移する。

最後がRecovery.Idleで、これもPolling.Idleと同じである。必要ならHot ResetやLoopbackに移行できることも全く同じである。

こうして見るとRecoveryの大半の処理はPollingと等しい。異なるのは、Polling.LFPSとかPolling.RxEQがない事で、これはRecoveryがU0～U3から遷移してくることに関係する。これらのStateでは、最低でもLFPSのHandshakeが確立しているから、改めてPolling.LFPSやPolling.RxEQを行う必要が無い。このあたり、例えばPollingをPolling.LFPSとPolling.RxEQだけにして、これが正常終了したらRecoveryに推移するというインプリメントにしなかった理由が知りたいところだが、案外に「SS.Inactive→Rx.Detect→Pollingという流れはあくまでもLinkの開始であって再開(Recovery)ではない」という単純な理由だけかもしれない。

• Loopback(Photo03)

正常モードでの動作は以上で終わりだが、あといくつかStateが残っているのでちょっと説明しておく。まずはLoopbackで、これは名前の通りLoopback Testを行うためのモードである。Linkのどちらか(特にUSP/DSPの区別は無い)のポートがLoopback Testが必要だと判断したら、そのポートがLoopback masterとなり、相手側ポートにLoopback Requestを送る。これを受け取った側はLoopback slaveとなり、Master側に受け取ったRequestをそのまま送り返してLoopback Stateに入る事になる。

LoopbackではまずLoopback.Activeに入り、ここでMasterはSlaveに対しSKPを含むデータ列を送り、Slaveはこれを変更する事なく送り返すという処理が行われる。ここでSlave側はBERT(Bit Error Rate Test)と呼ばれる処理を行う。これはData Scrambleの代わりに実施されるもので、Master側は送信データと(SlaveがBERTを実行して送り出した)受信データを比較する事で、Master-Slave間のBit Error Rateを測定できるという仕組みだ。このLoopback.ActiveはMaster側がLoopbackを終了するまで続く(か、Link Downなどが発生してRx.DetectもしくはSS.Disabledに移行する)。Loopbackが正常終了すると、Loopback.Exitに入る。ここでは必要に応じてLaneの極性をひっくり返したり、クロック補正を行ったあと(これをするかどうかは、Loopback.Activeにおける結果を元に実装側が判断する部分だ)、ここで再びLFPS Handshakeが始まる。この場合の条件はU2に同じ(元々LFPSにおいてはU2/Loopbackがまとめて定義されていた)であり、これがうまくいけばRx.Detectに遷移するし、失敗すればSS.Inactive、Link Downの場合はSS.Disabledに遷移する形だ。

ちょっと気になるのは、仮にMaster側に問題があった場合に、このLoopback Testでどこまでそれを判断できるか、である。もっともそこまでは考えていないのかもしれない。

(続く)