I²CとSPI.どちらも中〜低速デバイス間通信でよく使われるシリアル通信の方法です.これらは一般にマイコン(またはプロセッサ)と,その周辺のデバイスの間でのデータのやり取りに使われます.
どちらもコントローラとなるマイコンから,ターゲットとなるデバイス上のレジスタやメモリに対してのデータを読み書きします.同じような目的を達成するための手段がふたつ.それぞれに良いところと問題点があるのですが,その良い点だけを組み合わせて統一できないか? そのひとつの答えがI3Cバスです[図1].
図1:I3C = I²CとSPIの良い点を組み合わせて統一
I²Cの良いところは2線式のバスでマルチドロップに対応.少ない線数で多くのデバイスをさまざまな形(トポロジ)で接続できます.またそれぞれのデバイスに割り振られたアドレスを使って任意の指定したデバイスに対しての通信を行えます.またクロック速度や通信プロトコルも定義されているので,仕様に準拠したデバイス同士の互換性も確保されています.
しかしI²Cでは信号をオープンドレインで信号を駆動するため,信号の立ち上がりが鈍るため転送速度に制限を受けてしまいます.この立ち上がり時間を短くするには強めの(抵抗値が低めの)プルアップ抵抗を使うのですが,LOW出力時にはこの抵抗により多くの電流が流れて電力が消費されてしまいます.さらに1本のデータ線を「読み」と「書き」で切り替えて使う半二重通信で使うため,この点でもデータ転送レートが犠牲になります.
もう一方のSPI.このバスの良いところはデータ転送速度が速く.プッシュプル駆動の信号によって数十MHzのデータレートを実現できるのが利点です.またプッシュプル駆動は消費電力の点でも有利です.さらに「読み」と「書き」で独立したデータ信号を使うので,全二重通信が可能です.
SPIでの問題点は信号線数が多:コントローラとターゲット間で双方向通信を行う場合にはデータ線を2本(「読み」と「書き」でそれぞれ独立),これらに加えてクロックと,ターゲットデバイスを指定するためのチップセレクト信号が必要です.またクロックやチップセレクト信号は極性,さらにクロックはデータの出力制御/ラッチを行うエッジは,ターゲットごとに決められる仕様に合わせてやる必要があります.このため複数の種類のデバイスを同じバスに繋げて使うのが難しい場合があります.
またI²CにもSPIにも,バスそのもので割り込みを扱う仕組みがありません.そのためなんらかのイベントをコントローラに通知するには,コントローラからポーリングを行ったり,割り込みを別の信号線として用意する必要があります.
I²Cの使いやすさにSPIの速度と省電力性.さらに設計の簡素化を実現できるのがI3C (MIPI I3C)バスです[表1][表2].
表1:I3C,I²C と SPI.センサ接続例のブロック図での比較 (出典:MIPI I3C White paper: http://resources.mipi.org/MIPI I3C-sensor-whitepaper-from-mipi-alliance)
表2:I3C と I²C の比較
なおI3Cは「アイスリーシー」と読みます.I²Cではソフトウェアのコード内では「I2C」と書かれたり,これが理由で「アイツーシー」と呼ばれるなどの混乱もあるため,この後継となるインターフェース仕様ではあえて上付きではない「3」を用い,呼称も『アイスリーシー』としました.
I3Cは標準化団体MIPIアライアンス[英語サイト]によって2017年に標準化[英語サイト]されました(v1.0の発行年.最新版はv1.1.1).主にモバイル/IoT機器内でのセンサー用インターフェースとしての用途を中心に策定されました.
I3C仕様のフルバージョンはMIPIアライアンスのメンバー向けに公開されています.しかしこの他の開発者や他の標準化団体も利用できるよう,一般的に必要とされるI3Cの機能をまとめたI3C Basic版は誰でも入手できるようになっており,MIPI会員でなくてもロイヤリティフリーのライセンス下で実装可能です.
2021年からはDIMMメモリモジュールの規格として,DDR4までシステム・マネジメント・バス使われてきたI²Cに代わり,DDR5からはI3Cが使われることとなりました.
このようにI3Cは他の規格の中でも採用され,普及が進んでいます.
I3CはI²Cと下位互換性を持った仕様となっています.I3Cターゲット・デバイスはI²Cデバイスとしても動作するので,これまでのI²Cコントローラから操作することができます.またI3C信号はこれまでのI²Cターゲット・デバイスに対して影響を与えない仕様となっているので,I3Cバス上に旧来のI²Cデバイスを混在させて使うことも可能です.
I3C信号はクロックにHIGHの期間が45nsの細いパルスを使うようになっているため,I²Cデバイスではその回路に内蔵される50nsスパイク・フィルタによってこれが無視されます.このような特性を利用してI3CとI²Cデバイスの混在を可能にしています[図3].
図3:I3C信号の例
I3Cのクロック周波数は12.5MHzに設定されています.モード設定によりより高いデータレートを選択できるようになっており,信号の利用効率を変更によってより多くのデータを転送できるように切り替えます.
基本となるシングル・データ・レート(SDR)では12.5Mbps,実効レートは約10Mbpsとなります.このほかいくつかのハイ・データ・レート・モードが定義されており,これを使えば約30Mbps程度まで高速化できます.
先に示した[図1]はI²CとSPIを使用したシステム(現在のかたち)と,I3Cを使用した場合(理想のかたち)の比較です.このようにI3Cを使えば配線とSoCのピン数を大幅に削減できます.
I3Cには少線化を実現するためのいくつかの仕組みが用意されています.共通コマンドコードやタイムスタンプ機能などがその例です.
ここではその中のひとつ,インバンド割り込みについて見てみましょう.
I3Cには「インバンド割り込み(IBI:In-Band Interrupt)」と呼ばれる新しいプロトコルが規定されています.
これまでのI²CやSPIのデバイスでは,デバイスに発生したイベントをコントローラに通知するために,シリアル・バス信号の他に割り込み信号を設けることがありました.コントローラとターゲット間にもう一本の余分な線が必要になったわけです.これによりコントローラ側にはそのためのピンが必要になります.
デバイスの数が増えると割り込み信号も増えるので配線も増え,コントローラ側のピン数も多くなり,そのためパッケージも大きくなり,コストも上がってしまうという問題がありました.
これを解決するために考えられたのがIBIです.
I²Cではスタート・コンディションは必ずコントローラが発行します.これはコントローラが,「SCLがHIGHの期間にSDAをLOWに下げる」操作で行われます.IBIはSCLがHIGHの期間にターゲット側がSDAをLOWに下げることで,割り込み要求を通知します.コントローラは要求を受けるとSCLを下げてスタート・コンディションを作ります[図4].
ターゲットはIBI要求後にスタート・コンディションを検出すると,次に自身のアドレスを送出します.このときアドレス調停が実行されます.アドレス調停は複数のターゲット・デバイスが割り込み要求を出した場合を考えて設けられています.このアドレス調停が行われている期間はSDAはオープン・ドレインで駆動されます.アドレス調停は,より小さい値のアドレスを持ったデバイスが通信の権利を得るように動作します.
図4:IBI(インバンド割り込み),2本線で割り込みを実現する
I²Cと同様,I3Cではマルチ・コントローラもサポートしています.ただしI²Cのようなクロック同期をベースにした調停ではなく,IBIを基にした仕組みが用意されています.またこれに加えてホットジョインもサポートされていて,これもIBIの機能を使うように決められています.
「ホットジョイン」は活線挿抜をサポートする仕様です.これまでのI²Cでもブレードサーバのシステム管理バスに使われていました.このようなアプリケーションではバックプレーンへの活線挿抜をサポートが必要になります.しかしI²Cでは通信中のバスへのデバイスの追加をどのように行うかは規定されておらず,この機能の実現のためにはユーザ独自の仕様策定や,専用のバスバッファの使用が必要でした.I3Cではこのような使用例を念頭においた仕様が規定されています.
ここまでの説明では,I3CはI²CとSPIの問題を全て解決しているかのように見えます.しかし高速化のためにひとつ犠牲になっている仕様があります.
それはバス容量の制限です.400kHzまでのI²C (Fast mode) では最大400pFまでのバス容量が許容されていました(1MHzに対応するFast mode Plusでは550pFまで).しかしI3Cではそれが50pFまでに制限されています.
この仕様により,バスの配線長や接続できるデバイスの数が制限を受けます.I3C仕様のv1.1までは11個に制限されていたデバイスの数は撤廃されましたが,依然,このバス容量制限は残っており,既存のシリアルバスの置き換えが単純にできない一つの要因になっています.
I3Cコントローラやターゲットを搭載したマイコンやセンサが数多く登場.さらにI3Cに対応した電圧変換デバイスやマルチプレクサなどもリリースされ,そのエコシステムは拡大しています.
I3Cは組込機器ではまだこれからのインターフェース仕様ですが,今後はその利便性やコスト面でのメリットが評価され,しばらくの間はI²Cとの互換性も生かしながら,普及が進んでいくことでしょう.
日本語ウェビナー動画『【今知っておくべき】次世代インターフェース「I3C」の基礎』
https://www.nxp.jp/design/design-center/training/TIP-240723_I3C_Webinar_JP
MIPI I3C & I3C Basic 仕様 [英語]
https://www.mipi.org/specifications/i3c-sensor-specification
NXP システム・マネジメントI²C, I3C, SPIセレクタ・ガイド
https://www.nxp.com/docs/ja/product-selector-guide/I2CSELECTORBROC.pdf
NXPコミュニティ・ブログ:I3C動作サンプルコード:「i3c-temperature-sensor」の動かし方 (日本語ブログ)
https://community.nxp.com/t5/NXP-Tech-Blog/I3C%E5%8B%95%E4%BD%9C%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB...
NXPコミュニティ・ブログ:I²Cバスの概要 (日本語ブログ)
https://community.nxp.com/t5/NXP-Tech-Blog/I-C%E3%83%90%E3%82%B9%E3%81%AE%E6%A6%82%E8%A6%81/ba-p/203...
NXPコミュニティ・ブログ:SPIバスの概要 (日本語ブログ)
https://community.nxp.com/t5/NXP-Tech-Blog/SPI%E3%83%90%E3%82%B9%E3%81%AE%E6%A6%82%E8%A6%81/ba-p/203...
[初出:インターフェース 2024年3月号(CQ出版)「I3C:I2CとSPIの両方の良さを兼ね備える次世代規格」p78-81.当ブログ掲載にあたり加筆修正]
変更履歴:
2025-02-03:初版
2025-02-18:「5. 参考資料」の項にブログ記事「I3C動作サンプルコード:『i3c-temperature-sensor』の動かし方」を追加
2025-02-21:「I2C」の記述3箇所を「I²C」に修正
2025-02-25:日本語ウェビナー動画:『【今知っておくべき】次世代インターフェース「I3C」の基礎』のリンクを目次の前と「5. 参考資料」内に追加
=========================
本投稿の「Comment」欄にコメントをいただいても,現在返信に対応しておりません.
お手数をおかけしますが,お問い合わせの際には,NXP代理店,もしくはNXPまでお問い合わせください.
ここにコメントを追加するには、ご登録いただく必要があります。 ご登録済みの場合は、ログインしてください。 ご登録がまだの場合は、ご登録後にログインしてください。