6月11日のリリースの際の発表では技術的な詳細がほとんど明かされなかった「PCI Express 7.0(PCIe 7.0)」であるが、日本時間の7月16日にBrightTalkを利用してPCI-SIGより、少し詳しめの技術的な詳細が公開されたので、この内容をご紹介したいと思う。

PCI Express 7.0の設計目標

まずPCI Express 7.0の設計目標がこちら(Photo01)。

  • LatencyとBandwidth Inefficiencyに注目

    Photo01:LatencyとBandwidth Inefficiencyに注目

基本的にはPCI Express 6.0の倍の帯域で後方互換性を持つ、という事になっておりこれは問題ないのだが、PCI Express 5.0(つまりNRZ)と比べて2％未満だが帯域の効率悪化を認めている事と、10ns未満ではあるがレイテンシの増加を認めている事が挙げられる。

もっともこれ、半分くらいはFLITを実装する事に起因しているので、別にPCI Express 7.0だけの問題ではなくPCI Express 6.0でも結構共通な話ではある(レイテンシに関しては別の要因もあるが、これは後述)。

そのPCI Express 6.0ではPAM4 Encodeが導入されて、この結果Eye HightがNRZの1/3程になった(Photo02)訳だが、これはPCI Express 7.0も同じである。

  • 後でPCI Express 7.0のEyeが出てくる

    Photo02:後でPCI Express 7.0のEyeが出てくるが、かなり厳しい感じになっていて大丈夫か？　と思わざるを得ない

で、Photo01にも記されているが、PAM4を使う事でEye heightが大幅に減ったことでBERが悪化する。これをカバーするのにイーサネットで使われているような強力なFECはレイテンシを極端に悪化させる(～100ns)ので、代わりにFLITを利用してレイテンシのオーバーヘッドを最小に抑えながらBERを1FIT未満に抑える、という手法そのものもPCI Express 7.0でも変化はない(Photo03)。

  • PCI Express 6.0でのMetricsと比較

    Photo03:PCI Express 6.0でのMetricsと比較すると差が判る

Express 7.0では新たなMetricsが追加

ただしPCI Express 6.0ではMetricsがRetry Probability+FITだったのに対し、PCI Express 7.0ではRetry Probability+FIT+Latency+Bandwidth Overheadと新たなMetricsが追加になったのは注目する必要がある。要するにそこまでギリギリという話だ。

説明ではFLITモードの実装なども説明があったが、これは以前説明したPCI Express 6.0におけるFLITモードと完全に同じだったので割愛する。

ただRetry ProbabilityそのものがPCI Express 7.0では倍増している(Photo04)。

  • 見かけ上は倍の頻度でエラーが発生する

    Photo04:これは当たり前の話で、単位時間当たりのデータ量が倍増するから、データ量あたりのエラー率が同じでも見かけ上は倍の頻度でエラーが発生する事になる

それでもPCI Express 7.0におけるFITは4.6×10×10-10で、要求されている1FIT未満は十分にカバーできる、としている。

CI Express 6.1のFeatureとして追加されたUIO

次にUnordered IO(UIO)について。これは昨年10月、PCI Express 6.1のFeatureとして追加されたものである。もともとPCI ExpressはLoad-Store Accessの形で実装されている。あるいはProducer-Consumerというべきか。要するにあるデバイスがデータを生成したら、それを通知することで、別のデバイスがそのデータを使えるようになる。ここで言うデバイスにはPCI Expressのデバイスだけでなく、Root Complexの先にあるCPUも含まれる。これを担保するために、Posted/Non-Posted/CompletionというFlow Controlのクラスが実装されている(Photo05)。

  • この辺はPCI ExpressがあくまでもI/O Deviceであるという元々の思想が関係している気がする

    Photo05:この辺はPCI ExpressがあくまでもI/O Deviceである(から、ホスト側からの管理下にあるべきだ)という元々の思想が関係している気がする

これをCredit(Flow Controlを行うための管理用データ)に示す事でProducer-Consumer Orderingを担保している訳だ(Photo06)。

  • このOrdering Ruleは階層構造型を前提にしている

    Photo06:実はこのOrdering Ruleは階層構造型を前提にしているため、これはこれでまた問題が出て来ているのだが、そちらはFuture Workということで今回は非階層構造は議論に含めていない

ただこの結果として、複数の転送が同時に行われるような場合でも、順番を守ってトランザクションを順次処理して行かなければいけないという問題が出て来た(Photo07,08)。

  • PCI Express DeviceからCPUへの転送の注意点

    Photo07:PCI Express DeviceからCPUへの転送で、CPUからメモリへの書き込みはデータを書き込んだ「後で」Write flag fを書き込まないといけない。ところが実際にはCacheが間に入るので、順序が逆転してしまう場合があり得るのだが、これは違反になるという話

  • Completion TransactionはPCI Expressの順番に合わせる必要がある

    Photo08:同様にPCI Express DeviceからCPUへの転送で、CPUからメモリへの書き込みはOut-of-Orderで実行される場合があるから、必ずしもTransactionの順に処理されるとは限らない。が、そこでメモリへの書き込み順にCompletion Transactionを発行すると、元のPCI Expressの順番と異なる場合があるので、Completion TransactionはPCI Expressの順番に合わせる必要がある

一応Photo08にもちょっとあるがPCI Expressにはこのあたりの制限を多少緩めるRO(Relaxed Ordering)という機能が実装されている。ただROだけでは解決できないような状況が次第に増えてきているという話だ。

そこで新たに導入されたのがUnorderd I/O(UIO)である(Photo09)。

  • PCIのDelayed Transactionと似たイメージ

    Photo09:PCIのDelayed Transactionと似たイメージである。要するに複数のTransactionをOut-of-Order的に発行できるわけだ

要するにこの辺の制限を取っ払い、順番が違っていてもTransactionを成立させるための仕組みである。これを利用する事で、例えば2 Socketシステムにおける転送効率が改善する事になる(Photo10)。

  • UIO未サポートだと10個の処理を行う必要があるのが、UIOを利用すると4つで済む

    Photo10:この例ではCPU 0の先のPCIe Device AからCPU 1にデータを送る訳だが、UIO未サポートだと10個の処理を行う必要があるのが、UIOを利用すると4つで済むことになる

PCI-SIGによればこのUIOのメリットとして、大規模なシステムでもスケールアップさせやすいこと(Photo11)の他、色々挙げられている(Photo12)。

  • シンプルなケースと同程度のオーバーヘッドで利用できる

    Photo11:下側のCPU×2+複数のPCIe Device+PCIe Switchの様なケースになっても、アクセスのオーバーヘッドが劇的に減るので、上側のシンプルなケース(CPU×2+PCIe Device)と同程度のオーバーヘッドで利用できる、とする

  • non-Tree topologiesに関しては将来的にサポートという位置づけ

    Photo12:先も書いたがnon-Tree topologiesに関しては将来的にサポートという位置づけである

ちなみにこのUIOはFLITモードでのみ利用可能であり、FLITを利用しないケースではサポートされない。また現状UIOはオプション扱いであり、またアイドル時のレイテンシが増えるとか、まだプログラミング環境が整っていない、あるいはUIOに対応したアトミック命令などが定義されていないという問題がある。なので、今すぐに使えるというよりは、将来はこのUIOに段々シフトしてゆくかもしれないが、当初のPCI Express 7.0コントローラ/デバイスでUIOをサポートするかどうかはちょっと怪しい感じである。

PCI Express 7.0の物理層

次に物理層の話について。PCI Express 7.0にあわせてOptical Aware Retimer ECNが発行された話は前回のレポートでも説明したが、ReDriverの方は現在仕様策定中との事で、2025年末までにECNを発行予定という話であった(Photo13)。

  • OCIに統合できるRetimerという意味なのかもしれない

    Photo13:この図を見る限り、Optical Aware Retimerというのは要するにOCIに統合できるRetimerという意味なのかもしれない

またCopperLinkに関しては、2026年末までにCable Specificationをリリース予定とのことであった(Photo14)。

  • PCIe 7.0 CopperLink cable solution demonstrated

    Photo14:ここにある“PCIe 7.0 CopperLink cable solution demonstrated”はPCI-SIG DevCon 2025のショーケースで行われたものと思われる

その次が電気層であるが、まとめたものがこちら(Photo15)。

  • 1FIT未満を実現

    Photo15:BERが1×10-6以下なのは、これにFLITを組み合わせて1FIT未満を実現するから

PCB Lossが32GHzで1dB/inch以下というのも結構厳しい気がするが、RX側がFFE+DFE構成になったのは「ああやっぱり」という感じだ。信号の周波数が倍になった関係で、すべてのLossが増えてしまっているのは仕方がないが、帳尻を合わせるためにPCB lossを抑えるためには、それこそガラス基板が必要なのでは？　という感じに見える(Photo16)。

  • チャネルの長さそのものは実はPCI Express 6.0と同じ

    Photo16:チャネルの長さそのものは実はPCI Express 6.0と同じである。何も考えずに同じ材料でチャネルを構成すると損失が増えるので、PCB側でこれを抑えろという方針に転換した訳だ

加えて様々なコンポーネントも厳しくなる。Reference ClockのJitterは0.067psに抑えないといけなくなった(Photo17)し、Data Eyeは2nd Pre-cursorを使わないとかなり厳しいものになる(Photo18)。

  • 厳しいとは言っても不可能な数字ではない

    Photo17:といっても、例えばRenesas Electronicsは一番高精度なものだとJitterが55fsとかのPLLをラインナップしてるので、厳しいとは言っても不可能な数字ではない

  • いかにPCI Express 7.0では厳しいかが判る

    Photo18:Photo02と比較してもらうと、いかにPCI Express 7.0では厳しいかが判る

送信側のパラメータがこちら(Photo19)、受信側のパラメータがこちら(Photo20)である。

  • 全体的に結構厳しい

    Photo19:この数字を見ても全体的に結構厳しいのが判る。Tx Equalizationを4-Tapのまま据え置いたのは、Rx側で何とかする方向に切り替えたためだろう

  • Eye Heightが6mV→10mVになっている

    Photo20:Eye Heightが6mV→10mVになっているが、これはPhoto18に示すようにTX 2nd Pre-cursorを利用した場合を前提にしているのだろう。TX 2nd Pre-cursorなしだと10mVとれているかどうか、ちょっと怪しい様に思える

Compliance Eye Widthがわずか1.5625psというのも凄いが、PCI Express 6.0では16-tapのDFEだけで済んでいたのが29-tap FFE+1-tap DFEに強化されているのもなかなか壮絶である。先に最大10ns程度のレイテンシ増加があると説明したが、その大半がこの強化されたFFE+DFEに起因するのではないかと思う。

ということで現時点で公開されたPCI Express 7.0周りの情報をご紹介した。なんというかもう電気信号の限界に近いところまで来ている感が否めないのだが、先の記事でも説明したように市場投入は2028～2029年頃になるだろう。その頃にはこの程度の規格だと問題なく実装できるところまでコンポーネントの品質が向上しているのか、それともやっぱりギリギリのままなのか、ちょっと筆者にも判断がつかない。