もう少し、資料に沿って説明してゆこう。最初に書いた通り、I3CはI2Cの後継として策定された規格である。その設計目標がこちらだ(Photo04)。
互換性はもちろんだが、省電力性と高速性の両方が設計目標になっている。I2Cは何しろ普通に使われているものでは転送速度が遅いから、絶対的な消費電力はそれほど問題にならないが、性能あたりの消費電力という観点では古い規格(標準化されたのは1992年だが、元は旧Philipsが自社製品の接続用に開発したもので、これが広く業界で使われていた、いわばデファクトスタンダートなものだ)だけに「何も配慮していない」。そのため仮に高速化を図る場合は、当然省電力性も改善しないと、高速だけど使いにくいインタフェースになってしまう。またスピードについても、2012年に追加策定されたI2CのUFm(Ultra Fast mode)では最大5Mbpsまでスピードを引き上げているが、こちらは5Mbpsを実現するために色々互換性を捨ててしまったこともあり、ほとんど普及していない。このUFmが普及しなかった、という実情に対する反省がI3Cに生かされている形だ。
さて、Photo05がベースとなるSDR(Single Data Rate)モードでの転送の様子だ。SCLはActive Push-Pullであるが、SDAはOpen-Drainが維持されている。SCLの方は純粋に高速化(特にHDRモードの利用)のためにPush-Pullが必要になるという理由だ。一方SDAの方がOpen-Drainを維持するのは、Interruptに関係する。これは次に説明する。
Photo05:当たり前の話だが、I3CデバイスとI2Cデバイスを混在させる場合、クロックの速度は一番遅いデバイスにあわせる必要がある。そのため、例えば遅いデバイスと速いデバイスが大量に混在するような場合は、この図で言うところのI3C Secondary Masterにハブ機能を持たせ、その先に別のI3C Busを用意して低速デバイスをまとめてつなぐような配慮が必要になるだろう |
次がアドレスとインタラプトの話だ(Photo06)。まずアドレスは原則として自働割り当てになる。アドレスそのものは7bitになったが、もともと10bitアドレスが追加設定された理由が、固定的にアドレスを割り振るデバイスが多くなりがちなので、重複を避けるために7bitより増やしたい、というやや消極的な理由であって、実際につなぐデバイスを考えると7bit=127 Slave(+1 Host)あれば十分ということだろう。またそもそも何で原則自働割り当てかと言えば、次に出てくるHot-Joinの対応を行うためには自働割り当てにしないと面倒、という話だ。
Photo06:その一方で、最小限のI2Cライブラリを使ってアプリケーションを構築していたMCUなどでは、この自働割り当てのためのソフトウェアのスキームがオーバーヘッドになりそうな感じである。この場合は、スタティック割り当てにするなどの実装になるのではないかという気がする |
またインタラプトであるが、ここにあるようにBus Availableステートの際に、STARTコマンドを送るのがそのまま割り込みという扱いになる。問題は当然この際に複数のデバイスが一斉に割り込みを掛ける可能性があることだが、そこでOpen-Draingが役に立つ。同時にSTARTコマンドを送った場合、続くアドレスの送信タイミングも重なることになる。すると、Open-Drainの原理で結局一番小さなアドレスだけがホストに伝わることになるので、これで優先順位が決められるという形だ。当然このやり方だと1回のBus Availableあたり1デバイスしか割り込みは送れないため、アドレス争いに負けたデバイスはインタラプトの再送を行うロジックを実装する必要がある。
若干、気になるのは、この再送のレイテンシである。確かに12.5MHzでI3C Busが駆動されていれば、この再送によるインタラプト伝播までのレイテンシは大した問題ではない。が、もし遅めのI2Cデバイスがバス上にある関係で速度を落としていると、このレイテンシが割と無視できない大きさになる可能性があることだ。ここだけは注意が必要かもしれない。