ちょっと間が空いてしまったが、今回はPCI Express(PCIe) Specificationの詳細について分かったことをまとめてレポートしてみたいと思う。ちなみに以下の話は、基本的にはテクニカルトラックでの話をまとめたものであるが、残念ながら写真撮影不可、プレゼンテーション入手不可ということになっており、写真などは無しとさせていただく。

●Revision 0.71

　まずはPCIe Gen3のRevision 0.7→0.71で何が変わったか、である。まず0.7の仕様のままだと、チャネルによるバラつきが多すぎて補正が追いつかない事が、いくつかのメンバー企業によりレポートされたそうだ。これを補正するために、DFEと呼ばれる補正メカニズムを受信側に追加したのがまず1点目である。また細かいパラメータとして

• 全てのパラメータにきちんと数字が設定された(0.7ではいくつかが未定義のまま残された)
• 送信側にはmax Tx boostを測定するためのパラメータと、Max boost ratioを定義するパラメータテーブルが追加され、またTxEQを測定するための手順が明確化された
• 受信側はRxEQのアルゴリズムが変更になった他、Eye height/widthとBERのパラメータが変更になった
• チャネル(配線)に関しては、送受信パッケージの振る舞いが定義されたほか、ジッターについて詳細が定義された。また一部のパラメータについて、時間経過に伴う振る舞いが定義された

といった事が挙げられている。最初の「全てのパラメータにきちんと数字が設定された」というのは、もちろんRevision 1.0では考えられないことではあるが、Revision 0.3とかだと細かい数字がごっそり抜け落ちている事が多い。これが0.5、0.7とRevisionを上げるごとに埋められてゆき、Revision 0.9だとほぼ全てが埋まるというパターンになる。だから今回も0.9まで待てば恐らく全ての数字は埋まったのだろうが、その前に数字を確定して、その数字にあわせての検証を行なわないと、8GT/secでの通信が可能になるかどうかはっきりしなかった、というあたりが、0.71が追加された最大の理由らしい。この0.71をベースに検証を行ない、問題がなければ0.9に持ち込まれるというわけだ。

　数字が変わった、というケースもある。たとえば受信側のBehavioral Equalizationについては表1のようなものが示されている。DFE(Decision Feedback Equalizer)に関しては、そもそもRevision 0.7では無かったから仕方ないとして、BER(Bit Error Rate) limitが10^-6から10^-12まで引き上げられているのが分かる。もっともこの数字が出されたプレゼンテーションには"Changes reflect measurement technique only, not actual Rx imprementation"という注意書きもあって、必ずしもこれが実際のRxのインプリメントには影響しない可能性はある。とはいえ、BERが10^-6オーダーとなる実装をして、測定装置のみBERが10^-12のオーダーに上げてもあまり意味は無いわけで、若干は影響すると考えるべきであろう。

表1
	Rx Stressed Eye Calibration			Channel Tolerancing Parameters
	Behavioral CTLE	Behavioral DFE	BER limit	Behavioral CTLE	Behavioral DFE	BER limit
Rev 0.7	1st order	なし	10^-6	1st order	なし	未定義
Rev 0.71	1st order	1 tap	10^-12	1st order	1 tap	10^-12

　次にDFE(Decision Feedback Equalizer)である。日本語では「非線形回路」あるいは「判定帰還型等化器」という呼び方をするが、FFE(Feed Forward Equalization)と並んで高速信号伝送ではよく利用されるものである。図1がFFE、図2がDFEの模式図である。図1の場合、入力信号に加えて、一定期間(⊿T)だけ遅らせた信号を適当な係数を掛けて足し合わせるという方式である。X0だけだと意味が無いが、X1、X2……とどんどん遅らせた信号を重ね合わせることで、波形の乱れを補正するという仕組みだ。ちなみにX1だけがあるのが1 Tap、X1とX2があれば2 Tap、というような呼び方をする。

【図1】Feed Forward Equalization模式図	【図2】Decision Feedback Equalizer模式図

　一方DFEの方は、出力結果から判断してフィードバックを掛ける仕組みだ。まず入力信号はそのまま判断器に掛けられ、ここで波形を判断した上で、必要に応じて一部をフィードバックの形で入力に戻す。ここでもやはり⊿Tの遅れを持たせた上で、適当な係数をかけてあわせることで、波形の乱れを防ぐというものだ。こちらもまたX1だけなら1 Tap、X1とX2があれば2 Tap、というような呼び方をする。

　⊿Tをどの位にするか、とか係数はどの程度か、何Tap必要か、そもそもFFEとDFEのどちらを使うべきか、といったパラメータは、実際のデータによって最適値が変わってくるため、一概にはいえないが、PCIe Gen3の場合は検討の結果として1 TapのDFEを受信側に入れる事で、チャネル長が長い場合でも通信に支障が無い事を確認できたそうである。

　と書くと簡単そうだが、実際にはこの検討が色々あったようだ。こちらの詳細は会員限定セッションでのみ解説されたので直接講演を聴けたわけではないのだが、たとえばDFEのアーキテクチャだけでもCenter DFE/Edge DFE/Edge & Data DFEの3種類が検討されており、基本的にはどの方式でも利用できる。しかし、補正できる範囲に限りがある(Center DFEはEye Heightを、Edge DFEはEye Widthをそれぞれ最適化できる。Edge & Data DFEはEye Height/Widthを独立に最適化できるが、一番実装コストが掛かる)とか、DFE Adaptationの方法(つまりフィードバックを掛けるかどうかの判断)もOn chip eye monitor/SS-LMSアルゴリズム/SS-LMSアルゴリズム+パターンフィルタリングの3種類が検討されており、On chip eye monitorが一番確実だが遅く、SS-LMSは高速ながらノイズも多く、TAP数が発散しやすい。SS-LMS+パターンフィルタリングが両者の中間程度の特徴だそうで、このあたりを勘案しながら実装方法を決めるといった形になるようだ。最終的にこのあたりは、いくつかの方法を実装例として示すような形でまとまるのでは無いか、とのことだった。

　ちなみに0.7→0.71で専ら問題になったのはこうした電気的特性に関係する部分で、その上位である、たとえば128b/130bのエンコーディングやスクランブリングなどはほぼそのままであった。強いて言えば初日のプレスカンファレンスでTS1/TS2の変更が必要になった話が出ていたが、その程度であった。

●PCIe 2.1とECN

　以前に短期連載の方で、「追加仕様(Supplemental Specification)」が出てくる見込み」と説明したが、これがPCIe Gen3を待たずに2009年3月4日にPCI Express Base Specification Revision 2.1としてリリースされた。短期連載の掲載中にこの新仕様がリリースされた事になるが、そのことをPCI-SIGから知らされたのは2009年6月の事。「なんでまた急に2.1にUpdateしてしまったのか?」とYanes氏に聞いたところ「いくつかのメンバー企業から、非常に強く要望されたから」との返事が返ってきた(さすがにどの企業? とは聞かなかったが、まぁ聞くまでもないだろう)。

　ということで、表2に現在Base Specification 2.0以降に発行されたECNのリストをまとめてみた。CEM(Card Electromechanical)関係まで含めると20ものECNが発行されており、うち薄緑で示した11がBase Specification 2.1に取り込まれている。ちなみにGeneseoと関係ある、もしくはGeneseoが元になって規定されたと思われるものは一番右に○をつけた7つのECNである。Geneseoの殆どがBase Specification 2.1で包括されていることがお分かりいただけよう。

表2
項目	日付	提案社	対象	Geneseo
Protocol Multiplexing	2010/06/07	AMD, HP	Gen3 Rev 0.9
End-End TLP Prefix Changes for RCs	2010/05/26	Intel, HP, AMD	Gen2 Rev 2.1/3.0
Optimized Buffer Flush/Fill	2009/04/30	Intel	Gen2 Rev 2.1	○
ASPM Optionality	2009/08/20	HP, Intel, Microsoft	Gen2 Rev 2.1
TLP Prefix	2008/12/15	Intel, AMD, HP, NextIO	Gen2 Rev 2.0
TLP Processing Hints	2008/09/11	IBM, Intel, AMD, HP	Gen2 Rev 2.0	○
Extended Tag Enable Default	2008/09/05	Intel	Gen2 Rev 2.0	○
Latency Tolerance Reporting	2008/08/14	Intel	Gen2 Rev 2.0	○
ID-Based Ordering	2008/05/29	Intel, AMD, HP, IBM	Gen2 Rev 2.0	○
Dynamic Power Allocation	2004/05/24	Intel, HP, IBM	Gen2 Rev 2.0	○
Multicast	2008/05/08	HP, IDT, PLX, NextIO, Tundra	Gen2 Rev 2.0
Internal Error Reporting	2008/04/24	IDT, HP, Sun, Intel, PLX, NextIO	Gen2 Rev 2.0
Atomic Operations	2008/04/17	HP, Intel, AMD, IBM	Gen2 Rev 2.0	○
Resizable BAR	2008/04/24	HP, AMD	Gen2 Rev 2.0
Alternative Routing-ID Interpretation	2007/06/07	HP	Gen2 Rev 2.0
CEM Support Power	2009/09/08	HP	CEM 2.0
UICC Inter-Chip USB Interface	2008/10/21	Qualcomm	Mini-CEM 1.2
Display-Mini Card (DMC) Definition	2009/04/02	Dell	Mini-CEM 1.2
Mini-Card PCIe 2.0 Update	2009/05/17	HP	Mini-CEM 1.2
System Board Eye Height	2008/05/19	NVIDIA	CEM 2.0

■はPCIe Gen2 Revision 2.1でカバー済

　さて、では逆にGeneseoで定義された主要な拡張がどのECNとしてインプリメントされたか、を見てみることにする。Geneseoとして示された拡張には大きく8つの項目がある(写真01)。

【写真01】Geneseo拡張。これはIDF Fall 2007のテクニカルセッションで示されたもの

　これを順に対応させてゆく。

●Latency Reduction

・Data Re-use Hints → TLP Processing Hints ECN

短期連載の第3回で説明したTLP Processing Hintsの事。

・Ordering → ID-Based Ordering ECN

　もともとのOrderingのアイデアは、トランザクションベースで優先的に処理するものとそうでないものを区別する、というもので一種のQoS的な処理である。同様のことはVC(Virtual Channel)を使っても可能だが、VCの場合は帯域そのものを調整する(優先的に処理すべきデータが流れるVCの帯域を太く、そうでないものの帯域を細くする)ことはできても、トランザクションパケットレベルでの優先処理は行なえなかった。そこでトランザクションパケットにAttributeなりHintなりを設け、これが設定されたトランザクションパケットを優先的に処理させる、というものである。といっても、PCIeでは具体的に新たなPacket Orderingのメカニズムそのものを定義したわけではない。元々PCIeでは

・Default Ordering：通常のOrdering
・Relaxed Ordering：PCI-Xが混在するシステムでのOrdering

の2種類が定義されていたが、これに加えて

・ID-Based Ordering：今回追加された、Requester/Completer IDを使ってのOrdering
・Relaxed Ordering plus ID-Based Ordering：Relaxed OrderingとID-Based Orderingの2つのLogical ORを取る方式

の2つが追加された。ID-Based Orderingについてはインプリメントはベンダー依存とされている。つまり独自のOrderingメカニズムを利用したい場合は、Orderingの設定にID-Based Orderingを指定し、あとは自身でインプリメントを行なう、という形になっている。

・Pause/Resume → なし

●Increased Throughput

・Signaling/Encoding Scheme → Base specification 3.0

　これは要するに8b/10bエンコーディングをやめる、ということでPCIe Gen3では128b/130bエンコーディングが使われているのは既に説明した通りである。

・Packet header overhead improvements → Extended Tag Enable Default ECN(?)

　これは筆者もちょっと確証がないのだが、おそらくこちらが該当するものと思われる。トランザクション層で利用されるTransaction Descriptorというデータ構造があるのだが、PCIe Gen2の場合ここが16bitのRequester IDと8bitのTag、3bitのAttributesと3bitのTraffic Classで構成されている。このうちRequester IDとTagをあわせた24bitがTransaction IDとして利用される。

　さて問題はこのTagで、Base Specification 2.0ではフィールドこそ8bitながら、うち3bitは0でパッディングされ、実質5bit=32種類のTagしか利用できなかった。このECNではこれを8bitフルに使うように拡張され、最大256種類のTagが利用できるようになる、というものだ

●Software Model Improvements

・Atomic Read-Modify-Write → Atomic Operations ECN

　短期連載の第4回で説明したAtomic Read-Modify-Writeのこと。

・Shared memory support via I/O MMU → 不明

●Power Management

・Dynamic Power Allocation → Dynamic Power Allocation ECN 及び Latency Tolerance Reporting ECN

　これは短期連載の第3回で説明した電力管理の1つ目であるDPAと、2つ目のLatency Tolerance Reportingのことである。

　といった状態になっている。言ってみれば割り込み優先度を導入するという話だが、こうしたメカニズムは確かにある種の優先して行なうべき処理のレスポンスを早くできるものの、逆にシステム全体としてはむしろオーバーヘッドが増えるため、レスポンスが若干落ちるという副作用もある。このあたりを勘案して、アイデアは出たものの提案は行なわなかったようだ。またI/O MMU経由の共有メモリに関しては、たとえばATS(Address Translation Services)にもそうした機能は今のところ見当たらないし、特にECNにもそれらしいものは見当たらない。これもまた難しい話で、I/O MMUが「どこの」メモリを共有にするかでシステム性能に大きなインパクトを与えてしまいそうだ。これもまた、提案には含まれなかった模様だ。

　ちなみにその他のECNをざっと説明すると

・Protocol Multiplexing：複数のPCIeトラフィックを混在させる拡張。

・End-End TLP Prefix Changes for RCs：下に出てくるTLP Prefix ECNをさらに拡張したもの。やはり仮想化環境での利用が前提。

・Optimized Buffer Flush/Fill：これは、さらに電力管理効率を上げるための拡張である。このECNでは、ホスト側のコントローラが各デバイスに対し、現状のホスト側の電源状態をヒントの形で示す。デバイスはそのヒントを見ながら、たとえばホスト側が待機モードに入る場合は割り込み頻度を減らすとか、データバッファリングをデバイス側で行なうことでトラフィックを減らすといった、よりきめ細やかな電力管理が可能になるというもの。

・ASPM Optionality：これも電力管理に関係する。基本的にはASPM(Active State Power Management)のうち、L0s StateがBase Specification 2.1までは要件扱いになっていたが、これをオプション扱いに変更するというもの。

・TLP Prefix：これは仮想化(IO-SRV/IO-MRV)の環境で使う際の効率を上げるため、新たにLocal TLP PrefixとEnd-End TLP Prefixという2つのTLP Prefixを定義したもの。

・Multicast：これは全てのデバイスに同時にトランザクションを送るという拡張。

・Internal Error Reporting：よりきめ細かなエラーレポートやエラーロギングのメカニズムを提供する拡張。

・Resizable BAR：実際に転送を行なう際に必要となるBAR(Base Address Register)のサイズは、実際にはホスト側のメモリ構成によって提供されるサイズがまちまちになるため、ソフトウェア側でBARのサイズをハンドリングできるようにするための拡張。

・Alternative Routing-ID Interpretation：デバイスあたりのファンクション数を増やすための拡張。これを使う事で、従来とは異なった方法でより多数のFunctionを扱えるようになる。

　といった項目が並んでいる。このあたりは、まとめてBase Specification 2.2として出てくるのか、あるいはBase Specification 3.0まで取り込まれないのか、今のところ不明なままである。

●ということで

　3本に渡ってPCI-SIG DevCon 2010のレポートをお届けした。2年前のロードマップ(写真02)と今回のそれ(写真03)を見比べていただければ、きっちり1年遅れている感じだが、それほどに8GT/secのPHYを作るのに難航したという事だ。

【写真02】2008年のロードマップ。ちなみに2009年は電話会議の形で参加したのだが、プレゼンテーションをくれなかったのでお見せできないのが残念である。2009年の時点では約半年遅れだった	【写真03】PCI-SIG DevCon 2010で示されたもの

　もっともこれもまた語弊のある言い方かもしれない。実のところ標準化をしないで良ければ、8GT/secはおろか10GT/secは既に実用の範囲内である。たとえばXilinxとかAlteraの高速トランシーバはとっくに10GT/secを超えるスピードを実現しているし、ほかにも同種のものはたくさんある。ただしこれらは各社が持つアナログ技術のノウハウをフルに叩き込んだものであり、逆に言えば各社が持つ特許に引っかからない形で標準化を行なおうとすると、ここまで苦労することになる、とも言えるわけだ。それでも今回のDevConではいくつものメーカーが既に動作する製品をリリースしてきており、やっと形になり始めた事を伺わせる。おそらくはこの後はそれほど大きな障害もなく仕様は確定し、ほぼロードマップ通りに進行すると思われる。

　ところで今回のセッションやショーケースを眺めていて思うのは、Gen3に関してはサーバーやスイッチ、通信といった「もう少しでもいいから早く」というベンダーの意欲が非常に高く、PCは半ば置いてけぼりになっている感じだ。実のところPC向けとしては、グラフィックスとCPU⇔チップセットの内部接続以外ニーズがないし、グラフィックスにしても、ではGen2→Gen3にして、どこまで性能が上がるのか、筆者はやや懐疑的だ。というのは、たとえばNVIDIAのSLIにせよATIのCrossFireにせよ、x16+x16の構成とx8+x8の構成で大きく性能が変わらないのが実情で、たとえばGen2→Gen3になったからといって、そこで大きく性能が向上するとは思えないからだ。もちろんCUDAやATI Streamのようにアクセラレータとして使う場合はまた話が変わるだろうが、グラフィックスに関して言えばGen2/Gen3で差が出るのはテクスチャの転送程度で、肝心の描画性能は当然オンボードのグラフィックメモリを相手にしているから、そこでの差は無い。Gen1→Gen2でも、性能差は数%(これも波があり、上がるものは数十%上がったが、変わらなかったり落ちたりしたものまであった)であり、Gen2→Gen3もこれに倣うのではないか? と推察する。

　むしろ需要がありそうなのは、CPUと周辺機器を繋ぐ内部接続だろう。SATAが6Gbps、USBが3.0で5Gbpsまでスピードが上がっているから、従来と同じくこれらがチップセットの先にぶら下がっている場合、内部接続を太くしないと性能が出ないことになる。ただ、IntelにせよAMDにせよ、最近はCPUにさまざまなI/Oを集約したSoCの方向に向かっている事を考えると、これもどこまでニーズがあるのかちょっと疑わしい。端的に言えば、CPUからUSB 3.0とSATA 6Gbpsのポートを出してしまえば、後はPCIe Gen1かGen2のレーンを数本出しておけば足りてしまうからだ。そう考えると、PCIe Gen3はそろそろPCの性能向上にはあまり貢献しなくなりつつあるのかもしれない、と思わせるものがある。このあたりはGen4の議論でも当然検討されることになると思うが、それがスタートするのは早くて2010年末、まともに議論が始まるのは2011年だろう。PCIeがこの先どんな方向に向かうのか、ちょっと気になるところだ。