network on chip

1. Network on chip
NOC
Presenté par :
BELARBI Naouel
Responsable de la matière :
Mme. BELHACHAT

2. Indice
Introduction
Définition des NOC
Communication dans une puce
Protocoles de communication sur puce
Le bus AVALON
Le bus Wishbone
Le protocole AXI
Exemple d'utilisation
1.
2.
3.
4.
5.
6.
7.
8.

3. INTRODUCTION
01
Les évolutions technologiques acquises dans le monde industriel actuel ont permis
l’intégration de plus en plus de fonctions sur le même circuit intégré numérique.
Aujourd’hui, on arrive à embarquer plusieurs microprocesseurs, des accélérateurs
matériels, des systèmes de communications divers et avec même des systèmes
d’exploitation. Ceci permet donc de réaliser toutes les fonctions nécessaires pour effectuer
des traitements informatiques complexes sur la même puce, d’où la naissance de la notion
des systèmes sur puce (SoC pour System on Chip), successeurs des circuits spécialisés
ASIC (Application Specific Integrated Circuit).Le choix du système de communication,
dans un système sur puce, reste un problème major. Ce choix dépend des composants
constituant le système et surtout le processeur utilisé. Les plateformes logicielles de
conception des SoCs, proposé par les fabricants des circuits FPGA, propose chacune un
type bien défini de système de communication [2]. Ces systèmes sont généralement des
bus standards modélisés en un langage de description de matériels comme le VHDL.
Récemment et dans le but d’améliorer la qualité et la rapidité de communication dans des
systèmes nouveaux, des réseauxsur puce (NoC: Network-On-Chip) ont été introduits.

4. Architecture de base des SOC

5. Définition des NOC :
02
NOC (Network-on-Chip) ou en français
réseau sur une puce est une technique
de conception du système de
communication entre les cœurs sur les
System on Chip (SoC).

6. Communication dans une puce
03
Les systèmes logiques sur puce sont souvent conçus de manière à être
dimensionnés pour une seule application particulière. Chaque application a sa
propre architecture, de ce fait l'extension ou la réutilisation de telle architecture est
difficile et nécessite un effort de réadaptation et pour cette raison plusieurs types
de communication sur puce ont été proposés. Un système de communication
permet d’établir des connexions entre tous les composants dans un SoC. Il se
présente sous forme de bus ou bien de réseau de communication. La plupart des
systèmes embarqués sont basés sur des architectures de bus . Quant aux réseaux,
on les retrouve dans certaines architectures complexes nécessitant une bande
passante considérable.

7. Protocoles de communication sur puce
Les connexions point-à-
point
Ce type de connexion
permet d’établir de liaisons
directes entre les
composants d’un SoC. Il
existe deux types de
connexions point à point
avec ou sans mémoire
partagée. Généralement
dans le domaine des SoC, on
utilise des FIFOs pour la
réalisation de ce type de
connexion, la profondeur de
la FIFO est déterminée par
l’utilisateur
ou bien par l’outil de
conception lors de la phase
d’exploration d’architecture.
Les bus de communication
Un bus représente un canal
unique de communication. Ce
canal supporte le transfert de
toutes les données entre les
différents composants du
SoC. Une architecture de bus
intègre deux principaux
éléments qui sont le canal et
l’arbitre. A l’heure actuelle, on
retrouve une grande variété
de bus standards, plus ou
moins performants, offerts par
les industriels. Il existe deux
types d’architectures de bus,
des architectures dites
partagées et des architectures
matricielles.
Les réseaux sur puce
Comme le problème majeur de la
communication revient toujours à la
limitation en bande passante du bus qui
reste plus ou moins insuffisante pour la
plupart des applications complexes, les
réseaux sur puce (NoC) ont été introduits
afin de remédier à cette limitation et
d’intégrer davantage de nouveaux
processeurs et de composants matériels. Un
réseau sur puce est constitué d’un
ensemble de composants et de routeurs.
Les routeurs sont reliés entre eux via des
canaux de communication. Cependant,
l’inconvénient majeur de ce type
d’architecture revient à l’existence de
blocages (deadlocks), dus à des accès
simultanés à des ressources partagées, et à
la difficulté d’analyser les performances
effectives du réseau (latence, deadlocks,
etc.)

8. Le bus Avalon peut être vu comme un ensemble de signaux prédéfinis
permettant de connecter un ou plusieurs IP. Ce bus comprend un
décodeur d’adresse, un multiplexeur de données, un générateur de
cycles d’attente et un contrôleur d’interruption (figure 2). Les
utilisateurs peuvent facilement intégrer leurs propres périphériques
avec le reste du système basé sur un processeur NIOS de Altera [9]. Le
bus Avalon permet la connexion entre des composants maîtres ou
esclaves. Il supporte plusieurs maîtres sur le bus. Un arbitrage est
nécessaire au partage d’une même ressource partagée par les circuits
maîtres. L’architecture multi-maître fournit la grande flexibilité dans
la conception des systèmes.
Le bus AVALON

10. (AMBA) définissent des communications d'un SoC standard à rendement
élevé. Trois bus distincts sont définis selon les spécifications d'AMBA : Le
bus AHB (Advanced High_performance Bus), Le bus système ASB (Advanced
System Bus) et Le bus périphérique APB (Advanced Peripheral Bus). Le bus
AHB est utilisé pour les modules à rendement élevé en utilisant une
fréquence de base. Il permet le raccordement efficace des processeurs, des
mémoires internes (sur puce) et même des mémoires et interfaces externes
(hors puce). Le bus ASB est utilisé aussi dans les modules à rendement élevé
pour la connexion des processeurs et des mémoires internes et externes. Le
bus APB est utilisé pour les périphériques de basse puissance. Il est optimisé
pour réduire la puissance consommée et la surface de silicium (dans les
circuits FPGA) lors de la connexion des périphériques. Le bus AMBA est
utilisé généralement dans un système à base de processeur softcore et
OpenSource de type LEON.
Le bus AMBA

11. Le bus Wishbone est un bus OpenSource (modélisé en HDL) très utilisé pour la
conception des systèmes sur puce à base de différents cœurs de processeurs dits
softcore. En effet, un très grand nombre d’IPs OpenSource (CPUs, périphériques
auxiliaires) ont été adaptés à l'interface Wishbone. Il a comme prétention d'être un
"bus logique", il ne spécifie donc pas d'information électrique ou de topologie de
bus. La spécification est écrite en termes de signaux, cycles d'horloge, et niveau
logiques hauts et bas. Wishbone est fait pour laisser les concepteurs combiner
plusieurs conceptions décrites en HDL. Il est défini pour être reconfiguré en 8, 16 ou
bien 32 bits. Tous les signaux sont synchrones à une horloge unique mais les
réponses des esclaves peuvent être générées de manière combinatoire pour un
maximum de performances. Les bus Wishbone s'adaptent facilement aux topologies
courantes comme le point-à-point, plusieurs-à-plusieurs, hiérarchique, où même
commutés. Pour des topologies moins courantes, Wishbone requiert un contrôleur
de bus ou arbitre, avec des composants gardant la même interface.
Le bus Wishbone

12. Spécialement pour des systèmes sur puce, IBM a proposé l'architecture CoreConnect
composée de trois bus permettent la connexion : de cœurs de processeur, de logique
dédiée, et différents autres accélérateurs matériels. Les trois bus de CoreConnect
sont :
Processor Local Bus (PLB) : Généralement, le PLB fournit un chemin de données
large bande. En effet il est utilisé pour connecter des composants tels que les
cœurs de processeurs, les interfaces avec les mémoires externes, et les
contrôleurs DMA (Direct Memory Acces).
On-chip Peripheral Bus (OPB) : L'OPB est utilisé pour réduire la charge du bus
PLB. Il est plus adapté aux composants d’entrée/sortie tels que les ports série,
les ports parallèles, UARTs et tous les composants à faible largeur de bande. Un
Maître sur le PLB peut accéder aux composants connectés à l'OPB via une macro
passerelle (Bridge). Cette passerelle est vue en tant que maître par l'OPB et en
tant qu'esclave par le PLB. Les registres d'état et de configuration de faible
performance sont généralement lus et écrits via le bus DCR.
Le Bus CoreConnect

13. Device Control Register (DCR) : Le DCR est principalement utilisé pour accéder
aux registres d'état et de contrôle au sein des différents bus PLB et OPB. Xilinx a
repris le comportement de tous les bus CoreConnect d'IBM et les a décrits en
VHDL, ce qui permet d'avoir des bus paramétrables . En effet, pour simplifier la
connexion d'un module logique utilisateur à un des bus CoreConnect, Xilinx a
ajouté une interface de bus préconçue paramétrable appelée IPIF (IP InterFace).
L'IPIF gère les signaux du bus, le protocole de communication et plus
généralement l'ensemble des caractéristiques du bus. L'IPIF intègre aussi une
interface de gestion, de la logique utilisateur, appelée IPIC (IP InterConnect).
Lorsque la logique utilisateur est conçue avec un IPIC, elle peut être portable et
facilement réutilisable sur d’autres bus en changeant seulement l'IPIF. Des
fichiers VHDL, qui instancient l'IPIF et fournissent le code nécessaire à
l'utilisateur pour ajouter ses modules, simplifient la tâche de connexion de la
logique utilisateur. Ces fichiers sont les User Core Reference Design.

14. le protocole AXI définit les interfaces du bus sans se prononcer sur la topologie
de celui-ci, qui peut prendre plusieurs formes selon les besoins du système.
Ainsi, si le besoin en matière de nombre de communications simultanées est
faible, on choisira une topologie de type bus pour économiser des fils, tandis que
si certains couples de composants communiquent fréquemment entre eux de
manière simultanée, on choisira une topologie crossbar pour éviter les files
d'attente. Ce type de bus est particulièrement adapté aux FPGA, pour lesquels la
topologie peut être changée en un clic, la mise en œuvre étant laissée au logiciel
réalisant la synthèse du circuit.
Le protocole AXI

16. Exemple d'utilisation