Les systèmes multicœurs hétérogènes utilisent généralement une communication basée sur la mémoire partagée, car les cœurs doivent interagir et échanger des données lorsqu'ils exécutent différentes fonctions et systèmes d'exploitation.
Il existe plusieurs implémentations personnalisées de cette pile de mémoire partagée, qui peuvent limiter l'interconnectivité. Nous allons donc examiner l'architecture en couches standard de partage de mémoire pour systèmes AMP hétérogènes basé sur des composants existants, tels que RPMsg et VirtIO. Voici comment cela fonctionne.
Pile de communication
Cette pile de communication peut être divisée en trois couches de protocole OSI : les couches physique, Media Access (MAC) et de transport.
Chacune de ces couches peut être implémentée séparément pour permettre à plusieurs implémentations d'une couche, telles que RPMsg dans la couche transport, de partager une implémentation de la couche MAC (VirtIO).
Couche physique
Cette couche abrite le matériel réel nécessaire à cette pile de communication, qui comprend la mémoire partagée accessible par les deux cœurs et les interruptions inter-cœurs. Ces interruptions sont définies selon une configuration spécifique, la configuration minimale nécessitant une seule ligne d'interruption par cœur, soit deux au total au moins.
L'espace SoC RockChip RK3588 La série s'appuie sur une telle configuration dans sa couche physique car elle utilise un module matériel de boîte aux lettres pour la communication inter-cœurs. Cette boîte aux lettres transmet des signaux d'interruption entre les différents cœurs, ce qui est presque similaire au passage de sémaphores de synchronisation dans d'autres systèmes. Mais il présente quelques différences, que nous examinerons plus tard.
Certaines puces, comme celles de la famille NXP, s'appuient sur des sémaphores pour la synchronisation inter-cœurs, tandis que d'autres s'appuient sur des éléments matériels tels que des files d'attente inter-cœurs et des mutex inter-cœurs.
Cette synchronisation n'est pas nécessaire lors de l'utilisation de virtqueue dans la couche Media Access.
Couche d'accès aux médias (VirtIO/Virtqueue)
Cette couche élimine le besoin de synchronisation inter-cœurs car elle introduit virtqueue, une structure de données de mise en mémoire tampon circulaire à écrivain unique et à lecteur unique. Cette structure de données permet à plusieurs cœurs asynchrones d'échanger des données à l'aide de Vrings.
Virtqueue fait partie de l'architecture VirtIO et aide les pilotes et les périphériques à effectuer des opérations Vring. D'un autre côté, Vring est la disposition actuelle de la mémoire d'une implémentation de virtqueue.
Dans les distributions Linux, les virtqueues sont implémentées sous forme de Vrings, qui sont des structures de tampon en anneau. Chacun se compose d’une table de descripteurs (pool de descripteurs de tampon), d’un anneau disponible et d’un anneau utilisé.
La structure Vring dans la mémoire partagée
Ces trois éléments sont physiquement stockés dans la mémoire partagée.
Descripteur de tampon
Le descripteur de tampon possède une adresse de tampon de 64 bits qui stocke l'adresse du tampon conservé dans la mémoire partagée. Chaque descripteur possède également une longueur de tampon variable de 32 bits, un champ d'indicateur de 16 bits et un lien de 16 bits qui pointe vers le descripteur de tampon suivant.
Tampon annulaire disponible
Ce tampon en anneau d'entrée a son champ d'indicateur séparé de 16 bits, mais seul le 0ème bit de ce secteur est utilisé. Par défaut, ce bit n'est pas défini. Mais s'il est défini, le côté écrivain ne devrait pas recevoir de notification lorsque le côté lecture consomme un tampon de ce tampon en anneau d'entrée/disponible.
Si le bit est laissé dans son état par défaut (non défini), cette notification est reçue sous la forme de l'interruption que nous avons examinée dans la couche physique.
L'autre champ de saisie dans ce tampon disponible est l'index de tête. Une fois qu'un index tampon contenant un nouveau message est écrit dans le champ ring[x], l'écrivain met à jour cet index principal.
Tampon annulaire utilisé
Le dernier composant Vring est le tampon en anneau libre/utilisé, et il comporte des champs d'indicateur et d'index de tête, tout comme le tampon en anneau disponible. Les indicateurs informent principalement les rédacteurs s'ils doivent interrompre l'autre noyau lors de la mise à jour de l'index principal. Par conséquent, seul le 0ème bit de ce secteur est utilisé. Et s'il est défini, le noyau d'écriture ne recevra pas de notification (interruption) lorsque le lecteur mettra à jour l'index principal. Il fonctionne de la même manière que le champ d'indicateur de tampon en anneau disponible.
Cependant, le tampon présente certaines différences par rapport au tampon en anneau disponible, et l'une d'entre elles stocke la longueur du tampon pour chaque entrée.
Mais il est important de noter que cette technique Vring ne fonctionne que sur des systèmes multicœurs hétérogènes avec des configurations cœur à cœur, et non cœur à multicœur. Dans les systèmes cœur à multicœur, la configuration aura plusieurs enregistreurs sur le tampon en anneau disponible, ce qui nécessiterait un élément de synchronisation, tel qu'un sémaphore.
Couche de transport (RPMsg)
Le protocole RPMsg constitue la couche transport dans cette pile de communication. Chaque message RPMsg est contenu dans un tampon de la mémoire partagée. Ce tampon est pointé par le champ d'adresse du descripteur de tampon dans le pool Vring que nous avons examiné dans la couche Media Access.
Dans ce tampon, les 16 premiers bits sont utilisés en interne par la couche transport, vous ne les trouverez donc pas dans la mise en page.
L'adresse source de 32 bits contient l'adresse de l'expéditeur ou le point de terminaison source, tandis que l'adresse de destination contient le point de terminaison source. Ensuite dans la disposition RPMsg se trouve le champ réservé de 32 bits, qui assure l'alignement. Puisqu'il ne transporte aucune donnée, il peut être utilisé par la couche transport pour implémenter RPMsg (16 bits), laissant 16 bits pour l'alignement.
Les deux dernières sections de l'en-tête RPMsg sont le champ de longueur de charge utile (16 bits) et le champ flags, également de 16 bits.
Il est rare d'avoir un alignement supérieur à 16 bits dans un système multicœur hétérogène à mémoire partagée, mais une attention particulière doit être accordée s'il dépasse cette capacité si vous avez alloué une partie de l'espace à la couche de transport pour implémenter RPMsg.
Recommandé Système multicœur hétérogène sur module
Les systèmes multicœurs hétérogènes sont devenus très populaires dans les applications informatiques embarquées hautes performances, telles que l’IA, car ils offrent un puissant mélange de performances et d’efficacité énergétique.
Je recommande le Système sur module DSOM-040R RK3588 pour de telles tâches car il est développé sur le SoC RK3588, ce qui signifie qu'il possède quatre cœurs A76 et A55. Comme indiqué précédemment, ces cœurs utilisent le module matériel Mailbox pour la communication inter-cœurs.
Bien que cette communication soit en quelque sorte similaire aux sémaphores, elle repose plutôt sur des interruptions. Les interruptions peuvent augmenter l'efficacité du processeur, réduire le temps d'attente et permettre aux cœurs de mieux gérer le multitâche.
Il est également important de noter que le buffer RPMsg est situé par défaut dans la SDRAM DDR dans ces systèmes multicœurs hétérogènes asymétriques.
Dans la série SoM RK3588, la SRAM interne est désignée pour le module MPP. Si le système n'utilise pas le MPP, vous pouvez allouer cette SRAM au tampon RPMsg pour améliorer les performances.
Outre les cerveaux 64 bits à 8 cœurs, ce module comprend un GPU quadricœur ARM Mali-G610 MC4 qui offre 450 GFLOPS et un NPU hautes performances qui offre jusqu'à 6 TOPS. Il dispose également d'une unité de microcontrôleur pour un contrôle à faible consommation.
Conclusion
En un mot, le processus par lequel plusieurs cœurs tentent d’accéder à la mémoire partagée dans un système hétérogène s’apparente à celui de différents utilisateurs essayant d’accéder aux données d’une base de données partagée. Par conséquent, il doit exister une manière définie d’accéder à la mémoire avec des processus optimisés pour maximiser l’efficacité.
La pile de communication expliquée ci-dessus est une architecture standardisée et efficace qui s'appuie sur le protocole RPMsg, VirtIO et les interruptions principales pour utiliser la mémoire partagée dans un système AMP hétérogène. Et le système DSOM-3588R sur module basé sur RK040 s'appuie sur cette pile, ce qui en fait une architecture système AMP efficace, idéale pour gérer les besoins de calcul de haute puissance tout en étant rapide et efficace.
C'est tout pour cet article, et j'espère qu'il a été instructif. Veuillez l'aimer et le partager avec vos collègues développeurs embarqués et IoT, et commenter ci-dessous si vous avez besoin de précisions supplémentaires.
Pour d'autres services de développement personnalisés et des applications de cas d'utilisation, bienvenue sur contactez Dusun IoT. Nous nous engageons à fournir des services professionnels pour assurer le lancement réussi de votre produit sur le marché et favoriser ensemble un avenir prospère !
