le nouveau protocole I3C - effet d’annonce ou vrai progrès

Aucun protocole de bus n’a connu un succès aussi grand que l’I²C lancé dans les années 1980 par Philips Semiconductor. Cependant, les faiblesses de ce système de bus sont apparues ces dernières années. L’I3C, son successeur est en embuscade et cet article souhaite vous le présenter en détail.

Pour comprendre les possibilités et limites du bus I²C (Inter Integrated Circuits), il faut garder en mémoire qu’il est dans le domaine public depuis l’expiration des brevets détenus par Philips. Bien que NXP (successeur de la division semi-conducteurs de Philips) détienne les droits de propriété intellectuelle sur le logo et le nom, l’exploitation du protocole I2C est désormais libre.

Le débat I²C/TWI (Two Wire Interface = interface bifilaire) est maintenant pratiquement éteint, mais des commentaires intéressants sont encore en ligne, notamment : « L’idée derrière le droit de licence était de s’assurer que les entités qui souhaitaient fabriquer du silicium I²C (et le vendre en tant que tel) soutenaient la norme et contribuaient ainsi à son développement ».

Les résultats ainsi que l’expérience de l’auteur montrent que, pour Philips, l’objectif de cette redevance a toujours été d’encourager les détenteurs de licence à mettre la norme I²C intégralement en œuvre. Cette norme incluait explicitement le filtre antiparasite de 50 ns qui fut jadis une pomme de discorde fréquente entre Philips Semiconductor et les fabricants tiers. Ce filtre (nous y reviendrons plus tard) pourrait être l’une des raisons qui poussèrent Philips à percevoir des droits de licence. Toutefois, avec l’expiration des brevets de Philips tout est désormais ouvert.

Malheureusement, l’interopérabilité des dispositifs I²C dans un système de bus I3C n’apparaît que comme un procédé recommandable ou un vœu pieux. On ne peut pas se passer d’essais pratiques sur ces systèmes mixtes. Voyons d’abord qui ou quoi se cache derrière la norme I3C.

I3C et l’Alliance MIPI

L’Alliance MIPI (Mobile Industry Processor Interface Alliance) est un comité de normalisation proposant diverses normes d’électronique générale et la norme I3C. L’adhésion à l’Alliance est chère, comme le montre la liste des redevances (fig. 1).

**Figure 1.** L’adhésion à l’alliance MIPI est incontestablement coûteuse. (Source : www.mipi.org/join-mipi).

Pour stimuler une adoption maximale, l’Alliance MIPI offre une version de base entièrement gratuite de la spécification I3C. Les fonctions avancées (seuls les membres de l’Alliance y ont accès) sont listées ici. Vous pouvez y voir que l’abréviation I3C signifie Improved Inter Integrated Circuits (=I2C amélioré). Selon l’auteur, une exploitation commerciale d’I3C ne pose pas de « problème » à l’Alliance MIPI sauf si vous implémentez peu ou prou vous-même l’interface, par ex. dans un FPGA ou par bit-banging (c.-à-d. l’exécution d’un protocole série par logiciel). En revanche, si vous n’utilisez que des composants achetés (sans utiliser le logo ni le nom I3C dans votre publicité), vous ne devriez pas rencontrer de problèmes.

Adieu le drain ouvert

Dès le début, le bus I²C réserva des désagréments aux développeurs. Primo, il y a toujours la question de savoir où placer les résistances de polarisation (pull-up) pour décharger la capacité du bus. Secundo, généralement il n’est pas possible de déclencher des interruptions depuis un composant qui ne délivre pas le signal d’horloge. Avec l’I²C, pour qu’un circuit « de détection d’horloge » puisse déclencher des interruptions, il faut toujours une connexion en plus. S’il y a plusieurs capteurs sur le terrain, c’est au détriment de la capacité GPIO du circuit émetteur du signal d’horloge.

**Figure 2.** À l’instar des processeurs pour mobiles, la vitesse économise l’énergie. (Source : bit.ly/2gId6BL).

Tertio, la vitesse reste relativement faible : selon Philips, le débit de données est de 3 Mbps avec une horloge à 3,4 MHz. La conséquence est que la faible réactivité du transmetteur entraîne une consommation élevée d’énergie, l’allongement de l’échange de données entre deux appareils retarde la mise en veille à faible consommation. Selon l’auteur, les histogrammes MIPI sont plausibles (fig. 2).

Quarto, les dispositifs I²C ont la capacité fatale de désactiver « pour toujours » d’autres dispositifs du bus. La figure 3 illustre ce fait tel qu’on peut l’observer dans un certain nombre de systèmes I²C.

**Figure 3.** Le transistor T3 « d’arrêt d’urgence » permet l’extinction définitive de tous les capteurs connectés au bus.

Saluons les améliorations de l’I3C

Le 1er changement d’I3C est le mode push-pull des broches SCL (toujours) et SDA (en général). La broche SDA passe en mode drain ouvert (open drain) sous certaines conditions. Pour éviter les problèmes de placement des résistances de pull-up, la norme spécifie qu’elles doivent être situées dans le circuit qui délivre le signal d’horloge.

Autre aspect important (laissant de côté des cas d’espèce) : la broche SCL est toujours et exclusivement commandée par le circuit générateur de signal d’horloge. Si le bus comporte plusieurs circuits susceptibles d’être générateurs du signal d’horloge, un seul est actif à un instant donné et responsable de la commutation de la broche SCL.

L’étirement de l’horloge par un dispositif esclave, possible sur un bus I²C classique, n’est pas pris en charge par la spécification I3C. Le fonctionnement de tels dispositifs n’est donc pas possible sur un bus mixte. Là encore, l’auteur ne connaît que très peu de cas où l’étirement de l’horloge se produit en pratique.

Cette simplification implique une simplification des broches d’E/S du MCU ou du circuit qui produit le signal d’horloge. À cause du filtre de 50 ns mentionné ci-dessus, l’I²C exige des broches GPIO spécialisées. La norme MIPI n’exige que des broches GPIO normales, supportant un courant de 4 mA. Elle indique aussi explicitement que les filtres de 50 ns, souvent problématiques avec l’I²C, ne sont pas nécessaires.

Les avantages de la vitesse

Examinons maintenant les formes d’onde de l’I3C. Le filtre antiparasite mentionné ci-dessus n’est significatif avec l’I3C que si le signal SCL n’a pas un rapport cyclique de 50 % (comme c’est en général le cas avec l’I²C). Avec l’I3C, la période haute est définie comme étant inférieure à 45 ns (fig. 4). Par conséquent, un dispositif I²C conforme à la norme ne pourra rien faire de la forme d’onde SCL.

**Figure 4.** Les composants I²C considèrent ce front d’horloge comme « bas ». (Source : présentation NXP)

Après réception de cette sorte de transaction SCL « invisible », le dispositif « de génération d’horloge » peut également commuter sa broche/ligne SDA en mode push-pull et augmenter la fréquence jusqu’à 12,5 MHz. Dans ce mode pleine vitesse, il est possible d’atteindre un débit de transmission allant jusqu’à 12,5 Mbps conformément à la norme MIPI I3C.

Des débits de transmission plus élevés peuvent être obtenus avec l’I3C dans l’un des trois modes HDR (High Data Rate), ils ne sont utilisables que dans deux cas. Le 1er cas est un système de bus appelé Pure I3C Bus, composé exclusivement de composants I3C, et le 2e est baptisé Mixed Fast Bus et peut inclure des composants I²C, mais seulement s’ils ont un filtre de 50 ns implémenté selon la spécification.

Les modes HDR sont lancés par une séquence spéciale d’impulsions SCL alors que la ligne SDA est au repos. Le mode le plus simple est le HDR-DDR (Double Data Rate), qui peut atteindre une vitesse de 25 Mbps. À cet effet, chaque front du signal SCL devient un déclencheur valide de réception de données. Le mode HDR-TSP (Ternary Symbol Pure) permet de dépasser une vitesse de 30 Mbps. Il utilise les lignes SCL et SDA en combinaison pour la transmission des données. Le mode HDR-TSL (Ternary Symbol Legacy-inclusive) est un mode qui rend le TSP plus accommodant pour les bus mixtes.

Attribution automatique des adresses

Un autre inconvénient de l’I²C est l’attribution physique quasi obligatoire d’une adresse à chaque composant. Pour de nombreux composants (par ex. le HDC2010 illustré à la figure 5), cela implique que l’espace d’adressage prévu par la norme ne peut pas être pleinement utilisé.

**Figure 5.** Le HDC2010 n’a qu’une broche d’adresse, donc impossible d’en mettre plus de deux sur un bus I²C. (Source : www.ti.com/lit/gpn/hdc2010).

Au lieu d’un adressage sur 10 bits possible avec l’I²C, l’I3C permet une autoconfiguration dynamique. En outre, la fonction I3C Hot Join permet (comme l’USB) le branchement à chaud de dispositifs I3C sur le bus.

En arrière-plan, il existe aussi une procédure dite d’arbitrage d’adresse qui s’occupe d’attribuer des adresses aux dispositifs esclaves. À cette fin, chaque périphérique I3C se voit doté de trois paramètres : deux champs de huit bits d’information d’état, et un identifiant unique de 48 bits (UID). La spécification implique que chaque UID (appelé Provisional ID) est unique sur le bus.

Au démarrage du bus I3C, le dispositif de génération d’horloge doit scruter tous les dispositifs du bus et leur attribuer des adresses dynamiques. À cet effet, il utilise une méthode similaire au processus d’arbitrage I²C : une adresse dynamique est d’abord attribuée au composant I3C ayant la valeur UID la plus faible. Le dispositif de génération d’horloge exécute autant de cycles d’affectation que nécessaire pour que chaque dispositif reçoive un ID temporaire.

Manufacturer Adoption of the Standard

La liste des membres de l’Alliance MIPI est un who's who des fondeurs, de GigaDevice à Solomon Systech en passant par ST. La quasi-totalité des entreprises concernées y figure. Cependant, en pratique si vous cherchez des composants disponibles, le choix est très limité. Chez Mouser par ex., on ne trouve actuellement que des composants tels que le PI3CSW12 de Dialog. Il s’agit en général de circuits intégrés de multiplexage et de conditionnement de signaux, voir la figure 6.

Figure 6 - I3C.jpg — **Figure 6.** Le matériel I3C disponible à ce jour se limite avant tout au conditionnement de signal. (Source : www.diodes.com/assets/Datasheets/PI3CSW12.pdf).

Renesas a, du moins pour l’instant, adopté une approche similaire avec des CI tels que l’IMX3102. En outre, la déclaration suivante est incluse dans l’annonce : « Les vitesses de 12,5 MHz de l’I3C dépassent considérablement les solutions actuelles et anciennes, comme l’I²C à 1 MHz et les commutateurs passifs analogiques rapides ».

Si vous cherchez des MCU avec prise en charge de l’I3C, la liste est très courte : le i.MX RT685 de NXP est le seul disponible. Il existe une note d’application (AN12797) qui fournit un exemple de logiciel. NXP propose un noyau logiciel (gratuit dans certains cas) et une licence spéciale pour les utilisateurs non-membres de l’alliance MIPI. Si vous êtes prêt à payer pour la propriété intellectuelle (PI) du noyau logiciel, des fournisseurs comme Silvaco ou Arasan Chip Systems proposent des modules VHDL I3C clés en main.

Ne cherchez pas d’écrans avec support I3C (cas d’utilisation souvent mentionné dans la norme), il n’y en a pas encore. Les seuls CI actuellement disponibles sont des accéléromètres (BMI263 de Bosch et LSM6DSO de ST) et le capteur de pression LPS22HH de Bosch.

Pour le logiciel, c’est plus encourageant : une description relativement détaillée du pilote d’interface mis en œuvre dans le noyau Linux est disponible.

Combien de temps encore ?

Le débit plus élevé et les interruptions sans recours à des entrées GPIO spécifiques conduiront peut-être à l’adoption de l’I3C par l’ensemble des fondeurs, mais combien de temps faudra-t-il ? Comme, à ce jour presque aucun MCU n’est disponible avec les périphériques I3C appropriés, l’auteur pense que cela pourrait prendre du temps.

Des questions, des commentaires ?