Introduction à la conception de systèmes sur puce

Interconnexion dans un système sur puce

Tarik Graba

2021-2022

Interconnexion dans un SoC

Communication dans une puce

SoC

Dans un SoC, nous avons:

Périphériques mappés

Pour un processeur les données et instructions ont une adresse en mémoire.

Processeur/mémoire

Du point de vue du processeur:


Dans un SoC moderne, les périphériques sont aussi mappés en mémoire.

Processeur/mémoire/périphériques

Les périphériques aussi peuvent être différenciés en fonction de l’adresse à laquelle ils se trouvent. On dit qu’ils sont mappés en mémoire.

Ceci simplifie la conception des processeurs, car il n’y a pas besoin de mécanismes différents (instructions/protocoles) pour accéder aux périphériques ou à la mémoire.

Le processeur peut initier des transactions (de lectures et d’écriture), les périphériques (et donc la mémoire aussi) sont des cibles qui ne peuvent que répondre à ces transactions.

Dans un système plus complexe, d’autres éléments peuvent aussi initier des transactions. Par exemple, un contrôleur DMA (direct Memory Access), un coprocesseur/accélérateur…

La question à laquelle nous allons essayer d’apporter une réponse ici, est comment connecter ces différents éléments dans une puce et quels protocoles mettre en œuvre pour les faire communiquer.

Bus partagé

En utilisant des buffers 3-états

tri-state bus

Les éléments sont connectés physiquement à un bus partagé en utilisant un buffer 3 états. L’initiateur et la cible sélectionnés sont connectés, les autres sont débranchés.

Dans le cas où plusieurs initiateurs existe, on a besoin d’un arbitre pour contrôler ces accès.

Problèmes:

Ce type de bus est, de nos jours réservé à des bus externes (par exemple le bus I2C).

Bus multiplexé

multiplexed bus

Ici, la sélection se fait à travers des multiplexeurs. Contrairement à un bus 3-états, nous avons des garanties sur la charge présente à la sortie de chaque élément.


multiplexed bus

Contrairement aux bus 3-états, la logique de multiplexage est mono directionnelle. Pour les communications bi-directionnelles, il faut prévoir de la logique de muliplexage pour le chemin de retour.


bidir multiplexed bus

Pour les communications bidirectionnelles, nous avons donc une structure de routage plus complexes.

Les initiateurs sont sélectionnés par un arbitre et les cibles grâce à l’adresse à laquelle l’initiateur voudra communiquer. Il faudra donc prévoir de la logique pour décoder ces adresses (savoir à qui on parle).

La structure d’interconnexion peut permettre ou non à chaque initiateur de communiquer avec chaque cible. On parlera de topologie d’interconnexion.

Dans le cas où tous les initiateurs peuvent communiquer avec toutes les cibles, on parlera de full crossbar.

Bus fabric

bus fabric

L’interconnect dans un SoC peut être une complexe. On peut le voir comme un bloc matériel en soit, un IP. On parle de Bus Fabric.

Pour les SoC complexe, il existe des IPs dédiées. Aux interfaces, un protocole de communication définit doit être utilisé. Le routage et le transport des données est géré en interne de ce bloc.

Il existe donc des outils qui permettent de générer ces interrconnects et les configurer. Certaines entreprises fournissent des IPs pour les SoC complexes:

Ces IPs supportent plusieurs protocoles aux interfaces et peuvent être configurées en fonction du nombre d’initiateurs et de cible. La topologie peut être adaptée pour prendre en compte l’activité et les affinités.

Pour les SoC plus simple, c’est plus simple.

Fonctionnalités de base d’un interconnect

Interconnect

Un initiateur démarre une requête (lecture ou écriture) vers une cible en présentant son adresse.

L’adresse passe par un décodeur d’adresse pour identifier la cible. Ce décodage d’adresse est généralement hiérarchique.

Par exemple, on sait qu’on veut écrire en mémoire, mais on n’a pas besoin de savoir quel mot de la mémoire on va modifier.

Ceci permet de simplifier le décodeur d’adresse et de permettre de positionner les cibles à des adresses différentes (vu par l’initiateur) sans changer la cible.


Interconnect

Quand plusieurs initiateurs existent, un arbitre va observer les requêtes et choisir lequel a accès aux ressources.

En fonction de la complexité de la topologie on peut avoir un seul arbitre en amont. Ce qui veut dire qu’un seul initiateur a accès au bus à un instant donné.

Il est possible aussi d’avoir un des arbitres au niveau de chaque cible et de dupliquer les ressources de routage pour permettre des accès concurrents.

Des topologies intermédiaires peuvent aussi exister en fonction de la nature de l’application et des performances recherchées.


Interconnect

Une topologie similaire pour le chemin de retour (de la cible vers l’initiateur) peut aussi exister.

L’établissement de chemin peut se faire de façon statique ou séquentielle ment dans le temps. Dans le premier cas, un chemin complet allant d’un initiateur vers une cible et retournant à la cible est sélectionnée pour la durée de la transaction. Dans le second cas, les deux chemin sont activés à des moments différents.

Nous verons que ceci dépend fortement du protocole utilisé.

Exemple d’interconnect

Wishbone Interconnect

Cet exemple est issu de la documentation de référence du protocole Wishbone.

On y voit l’arbitre, le décodeur d’adresses ainsi que les différentes structures de multiplexage.

Notez que cette structure n’est montrée qu’à titre indicatif.

Protocoles de communication sur puce

Standardisation des protocoles

Les protocoles sur puce doivent permettre d’ajouter des éléments dans un SoC sans perturber les performances des éléments déjà existants. Permettre de garantir que des paramètres de performance (comme la fréquence de fonctionnement) ne soient pas trop impactés par l’ajout d’éléments.

Aussi, pour permettre de réutiliser des IPs d’origines différentes, les spécifications doivent être claires et sans ambigüité pour permettre de les valider de façon indépendante.

Protocoles synchrones

Pour avoir des garanties de performances, il faut un protocole synchrone.

Protocole synchrone

Ceci permet de valider séparément les initiateurs et les cibles. Nous avons aussi la garantie qu’il n’y a pas de chemins combinatoires qui partent de l’initiateur, traversent l’interconnect puis la cible, évitant ainsi d’avoir trop d’impact sur la fréquence de fonctionnement.

Signalisation

Protocole synchrone-signalisation

L’initiateur peut signaler les cycles pour lesquels un transfert est valide.

Rendez-vous

La cible peut mettre en attente l’initiateur (back-pressure).

Le transfert a lieu quand il est validé par l’initiateur et que la cible est prête à l’accepter.

On parle de rendez-vous (handshake).

Rendez-vous

Il est important que les signaux de rendez-vous valid et ready ne dépendent pas combinatoirement l’un de l’autre. Sinon, l’isolation apportée par le protocole synchrone n’est plus garantie.

Note: Le protocole Wishbone ne respecte pas cette règle. Il est en effet possible de répondre combinatoirement ce qui peut produire une boucle combinatoire.


Rendez-vous

La cible peut faire attendre l’initiateur.


Rendez-vous

La cible peut être prête à l’avance.


Rendez-vous

La cible et l’iniiateur peuvent être prêts dans le même cycle.

Ici le passage à 1 de ready ne doit pas être une conséquence (combinatoire) du passage à 1 de valid, juste une coïncidence.

Transactions bloquantes

Transaction bloquante

Certains protocoles sont bloquants. Quand une requête est initiée et tant qu’elle n’est pas finalisme, les autres initiateurs n’ont plus accès à la ressource partagée.

Ceci est d’autant plus pénalisant que les cibles ont une latence importante.

Note:

Typiquement, l’accès à une mémoire dynamique synchrone (SDRAM) a une latence systématique de plusieurs cycles.

Séparation des requêtes/réponses

Transaction décomposée

Pour remédier à ce problème, on peut décomposer une transaction et plusieurs phases.

Ceci permet de libérer la ressource partagée durant la préparation de la réponse de la cible. Ainsi, un autre initiateur peut avoir accès au bus et le taux d’utilisation du bus partagé est amélioré.

Pour cela, on a augmenté la complexité de notre protocole et les ressource nécessaire. Il nous faut deux rendez-vous distincts.


Transaction décomposée

Accès multiples (bursts)

Transactions multiples

Dans cet exemple, l’initiateur I veut écrire 5 données consécutives, puis en lire 5 autres. On voit les 5 requêtes d’écriture suivies des 5 requêtes de lecture.

Le protocole exige de répéter les requêtes pour chaque transaction (MRMD: Multiple Requests for Multiple Data transfers).

Le canal de requêtes est donc occupé durant 10 cycles alors qu’on sait vouloir des données consécutives.

L’avantage de cette stratégie est que la logique de la cible et de l’initiateur n’a pas besoin d’être différente pour des accès multiples.


Transactions uniques

Ici l’initiateur ne fait qu’une requête en indiquant le nombre d’éléments à transférer (SRMD: Single Request for Multiple Data transfers)

Cette stratégie permet de réduire le taux d’occupation du canal de requêtes, mais oblige à ajouter de la logique pour compter les éléments transférés du côté de la cible.

Comparatifs de différents protocoles

Quelques protocoles communs:

rdv. synch Req/Resp SRMD
ARM AXI + + +
ARM AXI-Lite + + -
OpenCore OCP + + +
ARM AHB/APB + - +
Whishbone + - -
Altera Avalon + pipeline burst ext.

Le protocole AXI

AXI: Advanced eXtensible Interface

Historique AMBA

Note:

Le protocole AXI a été conçu pour répondre aux besoins des SoC haute performance modernes. Mais en parallèle les protocoles AHB/APB existe toujours et sont encore utilisés dans les microcontrôleurs par exemple.

Dans ce type de systèmes, l’architecture de l’interconnect est séparé en deux parties.

Les deux sous-parties sont reliées par un pont (bridge) qui fait passer d’un domaine à l’autre. Ce bridge permet de limiter la complexité du crossbar (AHB) en faisant transiter toutes les requêtes vers les périphériques lents par le même chemin. Il permet aussi de hiérarchiser le décodage d’adresse.

AXI: Caractéristiques

La spécification est publiquement disponible [lien].

AXI: Exemple de lecture

Extrait de AMBA AXI Protocol v2.0 (2010)

AXI: Exemple d’écriture

Extrait de AMBA AXI Protocol v2.0 (2010)

Le protocole Avalon

Avalon: Caractéristiques

La spécification est publiquement disponible [lien].

Avalon: les transactions simples

Simple transactions

Avalon, Exemple

Les signaux de contrôle ne sont pas tous obligatoires.

Par exemple, pour un simple registre:

Ceci est un Agent Avalon (Cible) valide

Avalon, lecture piplinée (extension)

Pipelined Read transactions

Il n’est pas prévu d’interopérabilité directe dans le cas où un des participants (Initiateur/Cible) utilise une extension alors que l’autre non.

Par contre, il est prévu dans les outils d’intégration d’Altera, d’insérer des adaptateurs quand nécessaire.

Avalon, bursts (extension)

Burst Read transactions

Retour au sommaire du cours