13 min
En début de semaine, nous avons passé deux jours à un événement « plugfest » I3C confidentiel organisé par l’Alliance MIPI à Taipei, à Taïwan. Cet événement a permis aux fabricants de périphériques, aux concepteurs de propriété intellectuelle et aux fabricants d’équipements de test de vérifier l’interopérabilité entre leurs différentes implémentations de la spécification MIPI I3C. Dans cet article, nous vous présentons les principaux enseignements que nous avons tirés de cet événement ! Mais tout d’abord, voyons pourquoi un tel événement existe et partageons quelques-unes de nos observations à ce sujet.
Les spécifications des interfaces électroniques actuelles sont dictées par des exigences extrêmement variées, ce qui est particulièrement vrai pour des interfaces telles que le protocole MIPI I3C®. Par exemple, selon le site web de la MIPI Alliance, le protocole I3C est une « interface de bus à vitesse moyenne, destinée aux fonctions utilitaires et de contrôle, permettant de connecter des périphériques à un processeur d’application dans toute une gamme d’applications mobiles, IoT et automobiles ».Ce large éventail d’applications implique que le protocole I3C doit répondre à des besoins très diversifiés, et c’est là que la normalisation industrielle s’avère utile. Concrètement, la normalisation industrielle signifie que des entreprises issues de divers horizons peuvent collaborer pour définir le fonctionnement des interfaces, et ce processus de normalisation est devenu une nécessité dans l’industrie des semi-conducteurs. Sans normalisation, même les entreprises les plus riches au monde ne seraient pas en mesure de fournir des solutions électroniques dans le respect de contraintes réalistes en matière de coûts et/ou de délais.
La normalisation implique également que les spécifications des protocoles deviennent de plus en plus complexes, car elles tendent à regrouper les contributions de plusieurs entreprises ayant des priorités différentes en matière de fonctionnalités. Il n’est pas exagéré de dire qu’un seul protocole, comme l’I3C, peut être décrit à travers plusieurs documents comptant chacun des centaines de pages. Ce nombre de pages correspond simplement à ce qui est nécessaire pour décrire le protocole de communication de manière à garantir son fonctionnement fiable. Face à un ensemble de documentation aussi volumineux, les ingénieurs concepteurs sont confrontés au défi d’« interpréter » l’intention des documents sur lesquels ils s’appuient pour concevoir leurs solutions. Si un ingénieur de conception interprète une spécification de manière erronée, le coût pour son entreprise peut s’avérer prohibitif ! Et c’est là que les « plugfests » s’avèrent utiles. Les « plugfests » sont des événements au cours desquels les ingénieurs peuvent travailler ensemble et tester leurs interprétations des spécifications. Il s’agit d’événements hautement collaboratifs, qui témoignent de la maturité de l’industrie des semi-conducteurs face aux défis posés par les progrès technologiques rapides.
Figure 1 : On voit le SV6E-X en train de tester un nouvel appareil lors du Plugfest I3C.
Le module de test numérique à moyenne fréquence SV6E-X d’Introspect est un incontournable du « plugfest » MIPI I3C depuis 2018, et nos ingénieurs ont eu l’occasion de travailler directement avec des développeurs issus de nombreuses entreprises membres du MIPI. Alors que notre module de test numérique à moyenne fréquence SV6E-X fait le tour des stands, voici quelques observations sur le dernier « plugfest ».
On constate clairement que le protocole I3C arrive à maturité, et ce « plugfest » en a été la meilleure illustration ! Nous avons pu observer que de nombreuses implémentations interagissaient avec succès les unes avec les autres et qu’elles prenaient également en charge plusieurs fonctionnalités optionnelles du protocole.
Alors que nous étions installés dans notre coin lors de la première journée du « plugfest », nous avons été sollicités par deux entreprises membres qui ne parvenaient pas à assurer une interopérabilité fiable entre elles – l’une d’elles jouait le rôle de contrôleur et l’autre celui de cible. Le SV6E-X a été connecté dans une configuration de « sondage » (voir figure 2), et nous avons utilisé à la fois notre analyseur de protocole et notre analyseur PurVue – doté d’un oscilloscope temps réel intégré à 2 canaux et 1 Gsps – pour aider les deux entreprises à identifier la source du problème. En quelques minutes, le SV6E-X a pu identifier la cause première du problème d’interopérabilité, et les entreprises chargées du contrôleur et de la cible ont pu poursuivre leurs tests fonctionnels. La fonction d’oscilloscope en temps réel du SV6E-X s’est avérée cruciale, car elle a permis de mener le processus de débogage de manière fluide tout en rendant superflu l’utilisation d’un oscilloscope de table traditionnel. C’est vraiment remarquable.
Figure 2 : On voit ici le SV6E-X tester la liaison entre un dispositif de contrôle et un dispositif cible. Contrairement à ce que montre cette image, il est assez rare que l’appareil de test soit plus petit que le format de l’appareil mesuré.
Depuis notre premier événement « plugfest » en 2018, nous n’avons cessé d’améliorer les capacités du produit SV6E-X afin de le rendre aussi flexible que possible. Cette semaine, nous avons été ravis de constater que l’outil était capable de s’adapter à tous les scénarios qui lui ont été présentés. C’est important car, malgré la normalisation, l’économie de marché libre exige toujours une différenciation entre les entreprises. Ainsi, l’appareil de chaque membre (doté d’une interface I3C) possédera toujours des fonctionnalités uniques reflétant sa propre innovation et sa propre contribution au secteur. Tout outil tel que le SV6E-X doit être flexible afin de permettre à nos entreprises d’innover !
Bon, c’est parti.
Lors de chaque « plugfest » I3C auquel nous avons participé, nous avons remarqué que les ingénieurs perdent souvent beaucoup de temps simplement parce qu’ils utilisent les mauvais câbles ou qu’ils ne les utilisent pas correctement ! Et à chaque « plugfest », c’est l’oscilloscope temps réel intégré à l’analyseur PurVue du SV6E-X qui s’est avéré être l’outil permettant de résoudre ces problèmes de câblage ! Plus que jamais lors de ce « plugfest », l’analyseur PurVue d’Introspect a été utilisé comme outil pédagogique pour aider les ingénieurs à prendre conscience de l’importance de choisir les câbles adaptés et/ou de les raccorder correctement.
En effet, ayant une expérience de l’I2C et partant du principe que l’I3C est un bus « à basse fréquence », de nombreux ingénieurs opteraient pour une connexion des fils SDA/SCL telle qu’illustrée à la figure 3.
Figure 3 : Câbles généralement utilisés pour relier les signaux SCL et SDA de l’I3C. Pouvez-vous repérer ce qui ne va pas avec ces câbles ?
Le problème est que les signaux I3C sont transmis en mode push-pull, ce qui signifie que leurs vitesses de front sont extrêmement élevées, même si la fréquence SCL est relativement faible. Ainsi, lorsque les signaux SDA et SCL se propagent ensemble à si peu de distance l’un de l’autre le long des fils, comme illustré à la figure 3, le couplage capacitif entre eux est trop important, ce qui provoque une diaphonie. La diaphonie signifie qu’à chaque fois que la ligne SCL change d’état, la ligne SDA subit une impulsion de tension importante ou un glitch. Ceci est illustré à la figure 4.
Figure 4 : On observe une interférence croisée très importante sur la ligne SDA à chaque changement d’état de la ligne SCL.
La figure 4 présente un extrait de la forme d’onde où la ligne SDA transmet des bits bas tandis que la ligne SCL change d’état. Comme on peut le constater, une perturbation pouvant atteindre 1,45 V apparaît sur SDA à chaque fois que le signal SCL change de niveau, ce qui est considérable. Lorsque l’on examine une partie de la forme d’onde présentant des transitions actives sur SDA, la situation peut s’aggraver encore davantage, comme l’illustre la figure 5. Sur cette figure, nous présentons une phase « open-drain » de SDA fonctionnant à 4 MHz. Bien que le temps de montée sur SDA semble conforme, la perturbation qui s’y produit est si importante qu’elle peut facilement être mal interprétée par le récepteur.
Figure 5 : La diaphonie affecte le SDA même lorsque celui-ci est élevé. Un tel niveau de diaphonie peut avoir des conséquences catastrophiques sur le protocole.
N’oubliez pas que la forme d’onde ci-dessus correspond à une situation réelle observée lors du Plugfest I3C à Taipei : il ne s’agit ni d’une simulation ni d’un montage artificiel. Les perturbations sur la ligne SDA étaient si importantes qu’elles ont provoqué de fausses erreurs de protocole. Plus précisément, en vous référant à la figure 6 ci-dessous, nous vous présentons une trace d’analyseur de protocole obtenue à l’aide du SV6E-X ; cette trace met en évidence une transition d’erreur surlignée en rouge. En examinant la forme d’onde analogique, on constate que cette transition d’erreur a été provoquée par une perturbation due à la diaphonie !
Figure 6 : Superposition d’une courbe d’analyseur de protocole et d’une courbe d’oscilloscope en temps réel illustrant comment une perturbation SDA a été interprétée à tort comme une transition de protocole.
N’oubliez pas que les formes d’onde ci-dessus ont toutes été enregistrées à l’aide de la fonction d’oscilloscope intégrée du SV6E-X, sans aucun matériel externe.
Comparons maintenant les résultats ci-dessus à ceux obtenus en modifiant simplement le câblage sur la même plateforme. La figure 7 présente la même transition SDA que celle de la figure 5, mais on n’y observe pratiquement plus aucune perturbation.
Figure 7 : La même courbe d’oscilloscope en temps réel intégrée que celle de la figure 5 ne présente désormais pratiquement plus aucune diaphonie. La seule différence entre les deux graphiques réside dans les câbles utilisés pour relier les lignes SDA et SCL.
Et en les comparant côte à côte, on constate la différence flagrante entre les deux enregistrements. Rappelez-vous que la seule différence résidait dans le fait que nous avions changé les câbles. Pour le reste, c’était bien le même SV6E-X, équipé de son oscilloscope en temps réel intégré, qui effectuait les mesures dans les deux cas.
Figure 8 : Comparez les deux captures, toutes deux réalisées à l’aide du PurVue Analyzer, mais avec deux types de câbles différents.
Pour plus de certitude encore, prenons un peu de recul afin d’observer l’intégralité de la transmission de trames, avec à la fois les câbles défectueux et les câbles en bon état. La figure 9 présente les deux traces. Comme on peut le constater sur le côté gauche de la figure, les sections mises en évidence montrent qu’il n’y a pas d’espace entre les zones « VIL » et « VIH » sur la ligne SDA, ce qui explique pourquoi le risque de transitions de protocole erronées est élevé. Sur la partie droite, on observe une très nette séparation entre les zones VIL et VIH du signal SDA. C’est pourquoi les captures de protocole n’ont révélé aucune erreur.
Figure 9 : La comparaison de la transmission de la trame complète montre à quel point la diaphonie peut être importante. À gauche, on constate qu’il n’y a pratiquement aucune séparation entre les régions VIH et VIL sur le signal SDA.
Cela étant dit, nous vous présentons dans cette section le type de câble le plus adapté aux tests d’interopérabilité I3C. La figure 10 illustre les câbles I3C standard fournis avec le module numérique à moyenne fréquence SV6E-X ; il s’agit de la méthode recommandée pour réaliser les tests I3C. La caractéristique principale de cette figure est que chacun des fils SDA et SCL est entièrement blindé par un blindage relié à la terre. En réalité, ces fils sont de véritables câbles coaxiaux de 50 ohms, bien qu’il ne soit pas nécessairement indispensable de disposer d’une impédance contrôlée sur les câbles I3C. Ce qui importe, c’est la gaine de blindage reliée à la masse. Celle-ci garantit l’absence de diaphonie entre les lignes SDA et SCL. De plus, elle minimise les chemins de retour à la masse pour tous les signaux circulant dans les deux sens le long des câbles.
Figure 10 : Photographie des câbles coaxiaux blindés fournis avec chaque module de test SV6E-X.
Lors du Plugfest I3C, notre principale conclusion a été l’importance des câbles utilisés pour les tests d’interopérabilité. Grâce à l’oscilloscope temps réel intégré du SV6E-X, nous avons démontré comment des câbles inadaptés peuvent provoquer des erreurs de protocole dues à une diaphonie excessive ou à d’autres artefacts de signal. L’utilisation de câbles correctement blindés permet d’éliminer la plupart des problèmes d’intégrité du signal !
Développez-vous des produits I3C ? Évitez de passer des heures à déboguer faute d’outils adaptés et n’hésitez pas à contacter notre équipe à l’adresse info@introspect.ca pour obtenir des conseils.
