Du point de vue du processeur:

• pour une lecture:
  • il présente une adresse,
  • il reçoit une donnée ou une instruction
  • il l’utilise
• pour une écriture:
  • il présente une adresse et la donnée à écrire
  • il attend que ça soit pris en compte.

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.

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:

• on ne sait pas garantir les performances (temps de propagation) quand le nombre d’éléments connectés change (la charge électrique change),
• on ne profite pas de l’augmentation de la densité d’intégration qui évolue beaucoup moins pour les connexions.

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

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.

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.

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.

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:

• Arteris entreprise spécialisé dans les interconnects avancés
• ARM CoreLink

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.

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.

• une partie de l’adresse permet d’identifier la région cible,
• le reste de l’adresse est transmis à cette cible.

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.

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.

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é.

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.

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.

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.

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

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.

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

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.

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

• une phase de requête, de l’initiateur vers la cible,
• une phase de réponse de la cible vers l’initiateur.

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.

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.

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.

• ASB: Advanced System Bus
  • Bus bidirectionnel
• APB: Advanced Peripheral Bus
  • pour les périphériques lents
• AHB: Advanced High Performance Bus
  • Mono-drectionnel
  • Burst multi requêtes
• AXI: Advanced eXtensible Interface
  • Burst mono requête
  • Séparation requêtes/Réponses en canaux
• ACE: AXI Coherency Extension
  • Gestion de la cohérence de cache CHI: Coherent Hub Interface
  • Évolution de la gestion de la cohérence de cache

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.

• Une partie haute performance (souvent un full-crossbar), utilisant le protocole AHB, dans laquelle on trouvera les cœurs de processeurs, les DMAs et les mémoires RAM, FLASH…
• Une seconde partie, utilisant le protocole APB, pour les périphériques lents comme les UARTS.

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.

• Le protocole AHB est un protocole pipeliné où on présente l’adresse puis la donnée, dans lequel la cible doit conserver l’adresse.
• Le protocole APB est un protocole synchrone où tous les transferts nécessitent 2 cycles durant lesquels l’adresse est maintenue.

• L’initiateur (Host) démarre une transaction de lecture ou d’écriture en mettant à 1 le signal read ou write
  • On ne peut pas faire de requêtes de lecture et d’écriture en même temps.
• La cible (Agent) peut faire dit qu’elle n’est pas prête en mettant le signal waitrequest à 1 et force l’initiateur à attendre (il n’a pas le droit d’annuler une transaction en cours)
• Le transfert est effectué au front d’horloge quand l’un des deux signaux read/write est actif et waitrequest est bas.

• Une cible (Agent) peut répondre à une requête de lecture plusieurs cycles après l’avoir acceptée,
• Le signal ‘readdatavalid’ indique alors que la donnée est disponible,
• L’initiateur (Host) doit savoir que ce mode est utilisé.

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.