
Perspectives techniques
Why We Embedded a Full-Fledged Real-Time Oscilloscope Inside our SV6E-X Mid-Frequency Digital Test Module
4 min
Le protocole MIPI I3C® continue de trouver des applications dans un large éventail de domaines liés au contrôle numérique et à la détection. Dans cet article, nous nous intéressons à la manière dont le protocole I3C peut être utilisé comme couche physique pour mettre en œuvre le protocole MCTP (Management Component Transport Protocol), publié par l’organisme de normalisation DMTF. La spécification MCTP fait partie intégrante de nombreuses architectures informatiques et de serveurs, car elle définit la manière dont un contrôleur de gestion du système peut communiquer avec des périphériques gérés, tels que les cartes d’extension PCIe et les disques durs. Avec l’ajout récent d’un mécanisme de liaison à l’I3C, de nombreux ingénieurs étudient actuellement comment concevoir le MCTP sur I3C et comment le tester.
Le protocole MCTP est un système de messagerie aligné sur les octets qui s’appuie sur une couche physique et/ou un protocole de communication existant. C’est pourquoi on le qualifie de « couche de transport » : il définit uniquement les octets constituant un message (de gestion et de contrôle), sans préciser la manière dont ces octets sont transmis. Ce concept est illustré visuellement à la figure 1.

Dans la figure ci-dessus, les sections grises correspondent aux en-têtes et pieds de page typiques d’une couche physique sous-jacente telle que PCI Express (PCIe). Les sections orange et vertes correspondent aux octets de charge utile définis par le protocole MCTP. Pour la couche physique sous-jacente, les paquets MCTP ne sont que des octets de charge utile, et ils suivent les mêmes schémas de codage et de mappage que la couche physique.
Pour mieux comprendre ce principe, imaginez une carte mère équipée d’un disque SSD connecté via un emplacement PCIe. Ce disque est un périphérique géré dans le cadre du protocole MCTP. De plus, les messages de contrôle MCTP peuvent être transmis entre le processeur et le disque via le protocole PCIe lui-même. Ceci est illustré schématiquement à la figure 2.

Or, si vous avez déjà utilisé le PCIe, vous savez qu’il s’agit d’un bus très performant et très complexe ; il est donc préférable de l’utiliser pour effectuer des transferts critiques (comme la lecture de fichiers volumineux à partir d’un disque dur) à vitesse maximale, plutôt que pour la gestion du système. C’est pourquoi, dans de nombreuses implémentations pratiques, le protocole MCTP s’appuie souvent sur d’autres couches physiques plus simples, telles que le SMBus. Et désormais, grâce à la récente interface I3C, le protocole MCTP s’appuie sans problème sur une couche physique I3C! Voir la figure 3.

Dans cette section, nous décrivons comment les opérations d’écriture (d’un contrôleur de gestion vers un périphérique géré) et de lecture (à partir d’un périphérique géré) du protocole MCTP sont mises en œuvre via I3C.
Du point de vue de l’I3C, les écritures MCTP sont essentiellement des écritures privées. Le contrôleur crée simplement une condition de démarrage sur le bus I3C, puis spécifie l’adresse du périphérique cible I3C (qui est le périphérique géré par MCTP) ainsi qu’une commande d’écriture. Lorsque le périphérique cible reçoit l’adresse et que le bit RnW est mis à zéro, indiquant un message d’écriture, il accuse réception auprès du contrôleur (c’est-à-dire qu’il envoie une réponse ACK) pour signaler qu’il est prêt à recevoir les octets. Le contrôleur procède alors à l’envoi de ses octets. Ces octets contiennent une structure spécifique au MCTP, comme le montre la figure 1, mais pour le bus I3C, il s’agit simplement d’octets de charge utile.
La figure 4 illustre l’encapsulation des paquets MCTP sur I3C. Comme on peut le constater, le premier octet est toujours fixe (il contient des bits réservés et des informations de version). Le deuxième octet contient l’identifiant du point d’extrémité de destination (EID), et ainsi de suite. Les définitions de ces octets sont détaillées dans les spécifications du protocole MCTP ; elles ne seront donc pas reprises ici. Notez qu’une fois le paquet MCTP complet, le protocole I3C envoie un octet de code d’erreur de paquet (PEC), qui est simplement requis par le protocole MCTP pour garantir sa robustesse.

Les messages de lecture MCTP sont un peu plus complexes que les écritures, principalement parce que les périphériques gérés peuvent avoir besoin d’un certain temps pour répondre aux commandes de lecture émises par un contrôleur. C’est pourquoi les opérations de lecture s’appuient souvent sur la fonctionnalité d’interruption en bande (IBI) du protocole I3C. Il s’agit d’une fonctionnalité innovante qui permet à un périphérique (c’est-à-dire un périphérique géré) d’avertir le contrôleur lorsqu’ il souhaite envoyer des données.
Imaginons qu’un contrôleur effectue une découverte MCTP initiale et souhaite connaître la version MCTP du périphérique. Dans ce cas, le contrôleur enverrait un paquet de contrôle MCTP (c’est-à-dire que le champ « Message Type » de la figure 4 serait 0x00, ce qui correspond à un message de contrôle MCTP) contenant une commande appelée « GET MCTP Version Support ». Le périphérique préparerait les octets de réponse dans son tampon de transmission interne. Ensuite, à sa convenance et dès qu’il serait prêt à répondre, il émettrait une requête IBI à l’intention du contrôleur. Une fois la requête IBI reçue, le contrôleur lancerait un message de lecture privé afin de récupérer les octets de lecture provenant du périphérique, conformément au protocole I3C.
L’exemple ci-dessus est illustré graphiquement à la figure 5. Veuillez noter que la requête IBI comprend un octet de données obligatoire (MDB) dont la valeur est réservée aux paquets MCTP.

Si la fonction IBI n’est pas prise en charge par le périphérique cible, une autre méthode permettant de lire des données via le protocole MCTP consiste à utiliser l’interrogation. En termes simples, le contrôleur continue d’essayer de lire les données d’un périphérique (en envoyant, par exemple, une commande de lecture privée I3C) jusqu’à ce que ce dernier réponde par un ACK et transmette les données lues.
Quelle que soit la manière dont les opérations de lecture sont effectuées (via IBI ou par interrogation), l’encapsulation des messages MCTP repose toujours sur celle illustrée à la figure 1.
Le protocole MCTP sur I3C inclut d’autres fonctionnalités, telles que la prise en charge des concentrateurs et des périphériques « hot-plug ». Ces fonctionnalités dépassent le cadre du présent article, mais elles sont prises en charge de manière tout à fait transparente par le protocole I3C ! Par exemple, lorsqu’un périphérique « hot-plug » est inséré dans un système en fonctionnement, il peut émettre une interruption I3C « Hot-Join », et le contrôleur sera alors en mesure de le reconnaître et de lui attribuer une adresse dynamique.
Le module de test numérique à moyenne fréquence SV6E-X est la solution primée d’Introspect destinée au test et à la validation des interfaces I3C et de celles qui en découlent. Il prend bien entendu en charge le protocole MCTP sans aucune difficulté. Par exemple, pour utiliser le SV6E-X en tant que contrôleur et générer des messages MCTP à l’intention d’un périphérique géré soumis au test, il suffit d’utiliser une commande telle que :
controllerDevice.doPrivateWrite(peripheralAddress, mctpPacketBytes)
La variable `mctpPacketBytes` est une liste Python contenant une séquence d’octets. Ces octets sont construits selon le format présenté à la figure 4.
De même, le SV6E-X peut servir de périphérique pour tester des contrôleurs. Dans ce cas, le transfert de messages MCTP entre le périphérique et le contrôleur peut s’effectuer à l’aide de l’exemple de code suivant :
targetDevice.setReadResponseBufferData(mctpPeripheralPacketBytes) targetParams1.ibiMandatoryByte = 0xAE targetDevice.update() targetDevice.requestIBI()
Enfin, le SV6E-X peut être utilisé comme analyseur de protocole et comme oscilloscope en temps réel, et toutes ces fonctionnalités sont disponibles pour les tests MCTP.
Dans cet article, nous avons décrit le protocole MCTP et la manière dont il est encapsulé sur le protocole MIPI I3C. Nous avons illustré comment les octets des paquets MCTP peuvent être formatés pour créer des messages d’écriture d’un contrôleur vers un périphérique, et nous avons également montré comment un périphérique peut signaler au contrôleur qu’il est prêt à envoyer des données de lecture via des interruptions en bande, afin que le contrôleur puisse ensuite émettre des messages de lecture privés pour récupérer les données auprès du périphérique. Enfin, nous avons présenté le module de test numérique à moyenne fréquence SV6E-X et montré comment il prend naturellement en charge les tests MCTP sur I3C.
Vous avez des questions concernant les tests MCTP par rapport aux tests I3C ? Écrivez-nous à l’adresse info@introspect.ca.