AliExpressでオーディオ用に電源ケーブルを買おうとし（て結局Amazonで買っ）た話

動機

　筆者は自宅オーディオシステムを構築にあたり機材を調達中なのだが、オーディオ用に電源ケーブルを買おうとしたところトラブルに見舞われてしまった。当初はAliExpressで発注したものの、結果としてAmazon.deで買うことになったので事の顛末を記録しておこうと思う（時間を浪費したが、貴重な経験をしたと思う…）。

　そもそもの前提として、筆者は転居（日本→英国・アイルランド→スイス）を繰り返したり、機材をドイツのショップから購入したりしているのだが、これら4カ国/地域のコンセントは物理的にそれぞれ別規格でいつも悩まされている。というのも、電源ケーブルを交換するわけだがごく普通の電源ケーブルでも正規ルートで有名メーカー品を買ったりすると概ね300～1000円/m程度と案外良い値段するためである。
　そこで、「どうせ電源ケーブル交換が必要なら、普通の電源ケーブルより心持ち高価な値段でオーディオ用の極太OFCケーブルを入手できるか？」という企画を考えた。ここでいう「心持ち高価」とは1000～2000円/m程度と考えて頂ければよく、内部の太い電線・シールド・外装といった部材や組立等に必要な追加コスト分だけ高価という意味である。

　ところで、「オーディオケーブルで音は変わるのか」という議題は、巷（ちまた）ではしばしばオカルトの一種として捉えられがちで、実際に恐らく大半はオカルトだと思うが、中には科学的に説明できる事象は存在する。
　この議題についての筆者のスタンスを語弊を恐れずに一言で言うなら「電気的・科学的に妥当な最低限のケーブルは必要」ということになる。正確には「音を良くするために良いケーブルが必要」なのではなく「音を劣化させないために一定以上の品質のケーブルが必要」「不要なトラブルを避けるためにも最低限のケーブルは必要」という意味であるが、ここで「電気的・科学的に妥当」とは、例えば純度の高い銅線にすると伝導率は高くなるし、太いケーブルは細いケーブルよりインピーダンス（抵抗値）が低くなるし、電線を撚り線構造にすることで磁界→ノイズの発生を防ぐことができる（LANケーブルなどでも採用されている）し…といった具合にケーブルの品質を向上させる物理学的・科学的に説明可能な条件は存在する（人間に知覚できるか否かはともかく）。
　ただし問題として、残念なことにHDMIケーブルやUSBケーブルとは異なりアナログケーブルには品質を保証する規格や数値が無いため具体的な基準を挙げることができない。ちなみに、（電源ケーブル以外で）筆者は「一定以上の品質のケーブル」の基準として「放送局で使用されているケーブル」と規定しており、Belden・Mogami・Canareを愛用している。

　今回、上述の前提で電源ケーブルについての筆者の要件は以下の通りである：

• EU/ドイツ規格プラグ（筆者はオーディオ周りをドイツ規格で統一している）
• OFCケーブル（無酸素・高純度の銅製で電気的特性に優れる）
• 太い（インピーダンスが低くなる）
• シールドされている（電気的・磁気的なノイズを遮断する）

AliExpressの電源ケーブル

　筆者はノーブランドで安価なコモディティ商品の購入にはAliExpressを利用することが多いのだが、興味深いことにAliExpressで購入可能な高品質電源ケーブルの過半は有名ブランドの偽物である（苦笑）。

　そもそもの話、我々が気にしないだけで日常生活はノーブランドのケーブルに溢れている。たとえSony製品やPanasonic製品（例えばテレビ）を買ってもSonyやPanasonicがわざわざ電源ケーブルやスピーカーケーブルを作るとは考え難く、恐らくは中国あたりのOEM/ODM線材メーカーから購入・テストして添付しているはずである。そういう意味ではノーブランドであっても十分に高品質なケーブルを供給するメーカーは存在するし、我々は日常的にそれらの製品に接しており、オーディオ用だろうが有名ブランドに拘る必要はない。

　ちなみにAliExpressでも、例えばヘッドフォン用ケーブル（例：4.4mm Balancedケーブル）はノーブランドながらも多様な選択肢の製品から優秀な製品を購入することは可能で、筆者もHiFiManヘッドフォン用に4.4mm Balanced→3.5mmのヘッドフォンケーブルを購入して愛用している（ヘッドフォンに添付されていたUnbalancedケーブルよりも音は良いと思う）。

　そういった経緯で、筆者はノーブランド品を探すつもりでいたのだが…AliExpressで電源ケーブルを検索してみるとAccuphase・Furutec・McIntosh・Nordost・Krellなどを騙る偽物が並ぶ。恐らくMonosaudio（AliExpressページ）は本物（というか、中国のブランド）だが、それ以外のブランドはほぼすべて偽物と思われ、公式カタログに掲載がないほか一部は公式/代理店などが否定している。注意されたい。

筆者がAliExpressで購入に失敗した理由

　筆者は検討の結果、AliExpressにてブランド表示の無い4N OFC電源ケーブルを4本発注したのであるが、出品者との間で係争に発展してしまい、最終的に運営元＝AliExpressの介入で返金が実現した。

　ここで、係争で問題となったのは送料である。
　太いケーブルは金属の塊のため意外に重量が大きい≒送料が高くつく。筆者は電源ケーブル4本＋送料で約US$56を支払ったのだが（計7mなのでUS$8.00/m）、欧州への送料を含めると大幅に超過してしまったらしい。とはいえ、コストが予定を超過してしまうことはありえる話なので、出品者が事情説明してキャンセルしてくれれば何も問題にはならなかったのだが………なぜか出品者が勝手に購買契約の内容を変更したことにより係争に発展してしまった（苦笑）。
　上述の通り、購入者＝筆者は条件が見合ったノーブランドケーブルを1000～2000円/m程度で買いたかっただけで特定の商品に拘りがあったわけでもなく、大幅なコスト増（例えば7mでUS$18.00/m）を許容してまで購入する意欲は皆無でキャンセルしたかったのだが、出品者側は購買契約を強引に変更してでも送料を購入者に転嫁して無理矢理売りたかったようだった。運営元＝AliExpressは問題を購入者・出品者の対話による解決を推奨しているのだが、議論は平行線を辿り妥結せず、最終的にAliExpressの介入で返金が実現した。発注したのは6月18日・係争に決着がついたのは7月12日のことだった。

　もっとも、筆者と同様の事例が日本に住む日本人購入者がAliExpressで購入する場合にも発生するかは判らない。筆者の住む欧州は地理的にも遠いし物価も高いので、地理的に近い日本では送料は相対的に安価かもしれず問題とならないかもしれないし、そもそも出品者が変な人でなければ係争に発展することもないだろう。

Amazon.deにて発注

　上述の理由によりAliExpressでの発注は断念した。
　理屈上では別のAliExpressの出品者に発注することも可能だったかもしれないが、同じ太さ×長さ×本数のケーブルならば同じ重量になり、同じ国＝中国から購入すると同じ送料になることは明白で、類似のトラブルを招く恐れがあった。

　AliExpressで係争に発展したことは筆者にとって災難だったが、係争が決着したのがAmazon Prime Day期間中だったことは筆者にとって幸運で、大幅に割引された代替品をAmazon.deで購入することで解決した（ただし合計で7m・US$79≒US$11.30/mとなった）。ちなみに欧州製ではなく、おそらく中国製のノーブランド品のためAliExpressで購入しても品質に顕著な違いは無いと思われる。
　このケーブルの使い勝手については後日レビューしようと思う。

最近の興味深かった話題（2023年第27週）

Braveブラウザーがポートスキャンブロック機能を搭載する

Braveブラウザ、他のブラウザが未実装のセキュリティ機能を追加 - マイナビ
Brave browser will prevent websites from port scanning visitors - Malwarebytes

　マイナビの記事では記者が「他のWebブラウザがBraveのようにローカルホストのリソースをブロッキングする機能を追加するかどうかはまだ不明だが、導入されることが期待されている」と締めているが、個人的には色々と疑問だ。実装方法や挙動が不明のため評価待ちといったところではないだろうか。

　そもそもの話として、Braveの新機能をサイバーセキュリティー業界での一般語＝ポートスキャンとしてしまっていいのか怪しい。

　まず、サイバーセキュリティー業界で一般論的なポートスキャンの話をする。
　ポートスキャンはサイバーセキュリティーにおいて、防衛側も攻撃側も行う「情報収集」、あるいは企業などのIT部門が行うインベントリーの構築手段の一部である。組織内のネットワーク上のどのアドレスにどのようなホストが存在するのか？そのホストではどのようなサービスやアプリケーションがインストールされ・動作しているのか？といった個々の情報を組織ネットワーク単位で収集し、ネットワーク上に存在するホスト/ソフトウェア資産をデータベース化する。これに手作業の入力など他の情報を一箇所に集約データベースがインベントリーである。
　その情報収集方法として、フィンガープリンティングなどと呼ばれるが、スキャン対象のホストのどのポートでどのようなサービスが動作しているか検出する。例えばWebサーバーがリスニングしているTCP 80ポートにHTTPリクエストを送信して「Server: Apache/2.4.41 (Unix)」などと返ってきたら「Apache HTTP ServerサービスがUNIX/Linuxサーバー上で動作しておりHTTPをリッスンしている」ということが判るわけだが、サイバーセキュリティー的には同時にHTTPサーバーがApache 2.4.41で脆弱性があるバージョンである可能性があることが判り、サイバーセキュリティーの防衛側であれば、自分たちがどういったホスト/ソフトウェア資産と脆弱性を持っているのか把握し対策を講じることになるだろうし、攻撃側であればその脆弱性を利用してホストを攻撃しようとするかもしれない。
　余談だが、このためセキュリティーポリシーの整備された組織ではポートスキャン自体を禁止されている場合もある（例：セキュリティーチームなど特定IT部門以外によるポートスキャンを検知→攻撃者の可能性）。

　このような理由で、一般論としてホストベースのファイヤーウォールなどでポートスキャンのブロックはセキュリティー機能として存在するが、Webブラウザーというかユーザー空間のアプリケーションでブロックすることは一般的でない。
　一般的にはLinuxであればnetfilterカーネルモジュールやWindowsであればWindows Defender Firewallなどがカーネルレベル（TCP/IPでいうトランスポート層とネットワーク層）で行う。というのも、例えばApache HTTP ServerやMicrosoft IISといったHTTPサーバーがTCP 80をリッスンする場合、OSのカーネルがインターネット層からトランスポート層（第2層～第4層）までの処理を行い、ユーザー空間（TCP/IPでいうアプリケーション層=第5層）のサービスの下で動作するスーパーサーバー（LinuxのsystemdやWindowsのsvchost）がカーネルとサービス/アプリケーションとの橋渡しを行うので、ユーザー空間で動作するサードパーティーアプリケーションにポートスキャンのブロックを実装しても他のサービスが使っているポートを監視することはできないからである（TCP/UDPポート毎に各サービス・アプリケーション宛に振り分けられた後のため）。
　また、そもそも仮にユーザー空間に実装するとしても、アプリケーションとしての実装ではOSの起動時から終了時まで防護されないことになるためサービスとして実装される必要がある。（従来のポートスキャンに対する従来のnetfilter型firewallであれば）

　Braveブラウザーの開発者も当然このことを承知しているはずで、ここでいう「ポートスキャン」は一般的な意味＝ネットワーク経由でマシンに対する（OSカーネルのTCP/IPスタックを経由した）TCP/UDPポートのスキャンとは異なるはずだが、では、なぜWebブラウザーでどういった「ポートスキャン」をブロックする必要があるのかMalwarebytesの記事に概要が説明されている。要点を大雑把に挙げると：

• 訪問者のマシンにポートスキャンを行うWebサイトが存在する
• Webブラウザーはローカルリソースへのアクセスに対し防御・制限していない場合が多い

筆者は寡聞にして、この「ポートスキャンを行うWebサイト」の挙動に詳しくないのだが、恐らくはWebコンテンツに埋め込んだJavaScriptを使ってWebブラウザーに実行させているのだろう。例えばGoogle Chromeの場合JavaScriptエンジン＝V8はNode.jsのようなもの（というかNode.jsがChromeのV8エンジンの流用）だから、ポートスキャナーをJavaScriptで実装しGoogle Chrome内蔵のV8エンジンで実行させることは難しくないだろう。
　そして、一般には、安全と見做されるマシン上の安全と見做されるアプリケーションから外部へのアクセスは、ローカルホストではブロックされないことが多いから、ネットワークセキュリティー（例：VLANを使ったアイソレーションなど）次第ではローカルネットワークに対するスキャンも可能だろう。

　この場合、Braveがブロックしようとしている「ポートスキャン」とは、サイバーセキュリティー業界での一般的なポートスキャン＝「ネットワーク経由でマシンに対する（OSカーネルのTCP/IPスタックを経由した）TCP/UDPポートのスキャン」とはフローが異なり、「Webブラウザーでローカル実行されるスクリプトから、ローカルホスト・ローカルネットワークに対するTCP/UDPポートのスキャン」という意味なのだろう（記事を読んだ筆者の理解）。
　そうすると、恐らくこの「ポートスキャン」のブロック機能とは、Webブラウザー上でサイト毎にサンドボックス実行した上で、サンドボックス内とサンドボックス外との通信をモニタリング・ブロックすることになるのだと思うのだが、サンドボックス外に対するHTTP GETがユーザー操作によるものか、JavaScriptのポートスキャン機能によるものか判別は困難そうに思われる。

家庭用ルーターはRISC-Vに置き換わるのか？

MangoPi RISC-V router will support dual GbE, dual USB 2.0, CAN bus, RS485, and more - CNX Software

　CNX-SoftwareがRISC-VベースのSoCを利用したルーター型の開発ボード「MangoPi RISC-V」について報じているのだが、その中で「ルーターは主にMIPSベースのプロセッサーが使われてきて、そしてArmベースに置き換わったが、次はもしかしたらRISC-Vかもしれない」としているのが興味深い。
　家庭用ルーターがRISC-Vベースになるかは不明だが、個人的にはWiSoCと呼ばれるルーター用プロセッサー提供元の動向次第ではないかと思う。

　まず、ルーターでMIPSからArmに移行した経緯は、ちょうどIEEE 802.11nから802.11acに替わった時期に合致するのだが、振り返ってみるとMIPSからArmへの移行そのものは複合的な要因だったのではないかと思う。
　IEEE 802.11nから802.11acへの移行により、WiSoCの性能がMIPSでは限界が見えてきたというような理由もあるのだろうが、それだけならMIPSのままでもMIPS 24K→34K/1004K→InterAptiv/ProAptivなどの選択肢もあったはずである。恐らく、究極的な理由はMIPSの製品ロードマップや会社そのものの動向が不明瞭だったとか、WiSoCのメジャープレイヤーがAtheros・Broadcom（いずれもMIPSユーザー）・Freescale（PowerPCユーザー）からQualcomm・MediaTek・Realtek（いずれもArmユーザー）に交代したとかいう複数の理由が重なった結果ではないかと思う（FreescaleもBroadcomも別製品ではArmを扱っていたが）。
　また、802.11n・初期802.11acのメジャープレイヤーの3社がいずれも802.11nから802.11acへの転換期＝2008～2014年頃に買収されており、親会社の意向もあったのかもしれない。

年	買収した企業	買収された企業
2011	Qualcomm	Atheros Communications
2015	Avago Technologies	Broadcom
2015	NXP Semiconductor	Freescale Semiconductor

さらに、この時期はMIPSも新IPは発表しつつもゴタゴタが続いてロードマップが不明瞭になってきており、対するArmはスマートフォン用SoCで絶好調・毎年新IPを発表していたから、性能不足を理由にMIPSからArmに乗り換えるには良い時期だったのかもしれない。

　Qualcomm・MediaTek・Realtekといった企業からすれば、既存製品のノウハウをWiSoC開発に活かすことは理に適っている。
　組込用半導体は作って終わりではなく、10年間超に渡る供給保証・各種ドキュメント・BSP/SDKなどと呼ばれる開発キットがセットで提供される必要があり、そのサービスの質が評価される。
　例えばQualcommの場合、スマートフォン用SoC＝SnapdragonファミリーではCAF=Code Aurora Forumで既に実績があったから、同社のWiSoC=IPQファミリーでもCAFが使用されることは理に適っていたはずだ。MediaTekもスマートフォン用SoCで・RealtekもSTBやNAS用SoCでArmベースのSoC・各種ドキュメント・BSP/SDKで既にエコシステムが存在したからWiSoCでArmへの移行は既存製品を活かす意味でも効果的だったはずだ。

　これが、802.11nから802.11acの過渡期に発生したWiSoCにおけるMIPSからArmへの移行の経緯だが、ではArmからRISC-Vへ移行するのか？というと予想は難しい。
　ルーターはスマートフォンとは違い純粋な組込機器にため、CPUアーキテクチャーの違いによるアプリケーションの互換性は問題となり難いからArmからRISC-Vへ移行の技術的な難易度は低そうに見えるし、恐らくCNX記事中のMangoPiホビー用開発ボードようなニッチなマーケットには今後も登場することだろう。
　しかし、未だにクローズドな組込以外ではRISC-Vの採用は少ない（恐らくRISC-VのメジャープレイヤーはHDD/SSDのコントローラーに採用しているWestern Digital・Seagateと、GPU内のコントローラーに使用しているNVIDIAだろう）ことを考えると、Qualcomm/MediaTek/RealtekがArmで実現しているようなシナジーやエコシステムをRISC-Vで実現できそうには思えない。

最近の興味深かった話題（2023年第26週）

任天堂の次世代機

任天堂社長、次世代機への移行に言及　ニンテンドーアカウント活用へ - ITmedia

　任天堂社長が次世代機への移行に言及したそうで、各IT系メディアで取り上げられている。通常、任天堂・SIE・Microsoft各社はゲーミングコンソールを5～8年に1回程度の頻度で更新しているため、2017年に登場したNintendo Switchが2022～2025年のどこかで更新されることは自然なことだろう。
　誰もが予想する既定路線だと思うがニンテンドーアカウントというかSwitchのプラットフォームを使ったものになるようだ。むしろ疑問はアプリケーションプロセッサーの方である。

Generation	Nintendo	Sony	Microsoft
Gen 9	Nintendo Switch (2017)	PlayStation 5 (2020)	Xbox Series X|S (2020)
(Gen 8.5)		PlayStation 4 Pro (2016)	Xbox One X (2017)
Gen 8	Wii U (2012)	PlayStation 4 (2014)	Xbox One (2014)
(Gen 7.5)			Xbox 360 S (2010)
Gen 7	Wii (2006)	PlayStation 3 (2006)	Xbox 360 (2005)

　Nintendo Switchの成功は誰もが納得するところだろうから、ニンテンドーアカウントを「任天堂版Steam」とでも呼ぶべきプラットフォームと見做すならば、そのプラットフォームを活用し、次世代機でもアクセス可能とするのは当然に思える（もちろん、ここでの「任天堂版Steam」は他の任天堂ゲームコンソールから同じアカウントで所有するゲームタイトルにアクセス可能という意味であって、非任天堂マシンからアクセス可能とするという意味ではないが）。

　そうなると、次世代機もArm系アプリケーションプロセッサーの可能性が高い。一般にエミュレーションはオーバーヘッドが高い（最適化なしに普通にエミュレーションすると1/3程度の性能になるといわれる）ため、同じアーキテクチャーであればエミュレーションの必要なくNintendo Switchのゲームをそのまま動かせる可能性が高くなる。

　疑問はそのArm系アプリケーションプロセッサーをどこが供給するか？であるが、現行Nintendo Switchのアプリケーションプロセッサーの製造元＝NVIDIAは2015年頃を境にモバイルから車載へ転換しておりモバイル用アプリケーションプロセッサーを手掛けていない。
　NVIDIA Tegra系列の最新モデル＝Orinは圧倒的に高性能だが、その一方でコスト的にも消費電力的にもNintendo Switchサイズのゲーム機に収まるか怪しい。単純計算でも8倍以上の性能を持つがフルスペックでの消費電力は50Wに達する。もちろん、Orinを1/2程度にカットダウンした省コスト・省電力バージョンのハードウェアを作ることは技術的に難しくないだろうが、組込の世界はハードウェアを作って終わりではなくソフトウェアサポートも込みなので、果たしてNVIDIAがそこまでするか怪しい。

　筆者個人の勝手な予想としては、Qualcomm Snapdragon系アプリケーションプロセッサーという可能性もあるように思う。
　思うに、Nintendo Switchが登場した2017年以前の時点では任天堂としてもQualcomm Snapdragonは採用し難かったのではないか。Qualcomm Snapdragonのスマートフォンがターゲットだったし、そもそも任天堂のWii U・Nintendo Switchのライバルであるスマートフォンとの差別化が難しかったためである。しかし、現在のQualcommはSnapdragonをWindows on ArmやIoTに拡大しており、特にWindows on Arm用プロセッサーは魅力的ではないかと思える。
　下の表はWindows on Arm用Snapdragon（SC8xxx）と、同世代のスマートフォン用フラッグシップSnapdragon（SM8xxx）とを比較したものだが、Windows on Arm用Snapdragonはスマートフォン用Snapdragonと同技術をベースに拡大・高性能化した仕様であることが解る。

SoC	Date	CPU			GPU (FP32 performance)	Memory (Bandwidth)
		Prime	Performance	Efficiency
SM8150	2019Q1		Cortex-A76 x4	Cortex-A55 x4	Adreno 640 (954.7 GFLOPS)	LPDDR4X 4ch (34.13 GB/s)
SC8180X	2019Q3		Cortex-A76 x4	Cortex-A55 x4	Adreno 680 (1842.5 GFLOPS)	LPDDR4X 8ch (68.26 GB/s)
SM8350	2021Q1	Cortex-X1 x1	Cortex-A78 x3	Cortex-A55 x4	Adreno 660 (1720.3 GFLOPS)	LPDDR5 4ch (51.2 GiB/s)
SC8280	2022Q1	Cortex-X1 x4	Cortex-A78 x4		Adreno 690 (2100 GFLOPS)	LPDDR4X 8ch (68.26 GB/s)
(参) Nintendo Switch NVIDIA Tegra X	2015		Cortex-A57 x4	(Disabled)	NVIDIA Maxwell (393 GFLOPS)	LPDDR4 4ch (25.6 GB/s)

RISC-V 64コアCPU

64-core RISC-V motherboard and workstation - CNX Software
Milk-V Pioneer

　CNX SoftwareがRISC-V 64コアSoCを搭載したワークステーション/開発機について報じている。
　Armの高額なライセンスを毛嫌いしてRISC-Vという選択肢は理解できるものの、結果として間接的に中国やロシアのIT界の発展を支援していることになることが気になる。命令セットのノウハウやコンパイラーは西側のものを流用しているからだ。T-Head C920 CPU IPを開発したT-Head Semiconductorは中国Alibaba子会社で、この開発基板に搭載されているSG2042 SoCを開発したSophon/Sophgoも恐らくはAlibabaの関連企業と思われる。

　本ブログでも2020年に露Elbrusの開発ボードについての記事を取り上げたことがあるが、2020年当時の基準でも10～20年ほど時代遅れで西側の脅威となりそうになかった。それが、今回のSophon SG2042 SoCや搭載されているT-Head C920を見る限りは差は確実に縮まっているように思われる。

　政治的な話を置いておいて技術的な話をしたいところだが、SG2042の詳細なブロック図などが無いため性能は判断が難しい。
　リンク先のTRM=Technical Reference ManualによるとC920コアが4コア単位でクラスターになっており、16 CPUクラスター・4チャンネルのDDR4メモリーコントローラー・PCIe Gen 4/CCIXコントローラー32レーンがメッシュネットワークで接続されているようだ。
　恐らく性能はあまり高くなく、ダイサイズは巨大（300～400 mm2程度？）ながらメモリーやPCIeなどのスペックから推測するに初代Epyc Embedded（2017年）や初代AWS Graviton（2018年）と同等ではないかと見える。Epyc Embeddedは最大でZen 16コア・DDR4 4ch・PCIe Gen 3 64-lane、GravitonはArm Cortex-A72 16コア・DDR4 4ch・PCIe Gen 3 32-laneを搭載したSoCだったが、仮に同等の製造技術で64コアを搭載しようとするとArm Cortex-A55～Cortex-A72程度ではないかと想像する（想像の域を出ないが）。
　C920 64コアの総合的な性能がGraviton（Cortex-A72 16コア）～Epyc Embedded（Zen 16コア）と同等と判断する理由はDDR4メモリーの帯域が同じだからで、より高速ならばメモリー帯域に対する要求も高くなるはずだからである。

　個人的に興味深いのはElbrus-8CBにせよSophon SG2042にせよ、コンパニオンとなるチップセットが存在しないSoCでありながらPCIeやUSBといったI/Oの扱いが重視されていない点である。
　チップセットは事実上PCIeハブやSATA/USB等のI/Oコントローラーを集積され、CPU側で持てないI/Oコントローラーの不足を補う役割がある。上述のEpyc Embeddedなどはチップセットを持たないSoCのため代わりにPCIe 64レーン・SATA・10GBASE-KR x2といった多様なI/Oを内蔵している。
　これに対しElbrus-8CBやSophon SG2042はチップセットの無いSoCでありながら僅かなPCIeしか持たない（Elbrus-8CBは20レーン・Sophon SG2042は32レーン）。記事のSophon SG2042の開発基板の場合、PCIe x16が3ポート見えるが電気的にはPCIe x8で、VIA Labs製USBコントローラーやJMicron製SATAコントローラーはASMedia ASM2824 PCIeスイッチでホストのPCIe 8レーンから32レーンを分配している。
　AWS GravitonもPCIe 32レーンしか持たないが恐らくクラウド専用のワークロードが前提なのでUSB機器等の各種I/Oを接続するとは考えられず不要と判断されたのだろう。Elbrus-8CBやSophon SG2042の想定されているワークロードがよく分からないため判断の難しいところである。