4.4 Routage spatio-temporel
4.4.3 Complexité de l’algorithme et heuristiques possibles
4.4.3.1 Complexité
Nous considérons les grandeurs suivantes : C : le nombre de communications
R : le nombre de routeurs
S : le nombre de slots de la table TDMA (c’est aussi la taille maximale d’un paquet en nombre de slots)
A : le nombre d’arcs partant d’un routeur
Cl : le nombre de cliques auxquelles peut appartenir une communication Ainsi, le nombre de nœuds du graphe spatio-temporel est R ∗ S La complexité de l’algorithme Dijkstra modifié est
O(S ∗ R ∗ A ∗ S ∗ C ∗ Cl)
La complexité de l’algorithme de routage est
O(C2∗ S∗(complexité de l’algorithme Dijkstra modifié)) = O(C3∗ S2∗ R ∗ A ∗ Cl) Le nombre d’arcs partant d’un routeur est faible, il vaut 5 au maximum dans une grille 2D (liens nord, sud, est, ouest et local).
En pratique, le nombre S se situe entre 4 et 128. En effet, pour que les communi-cations aient un temps d’attente court pour accéder aux slots qui leurs sont réservés, il faut que la table de TDMA ait un temps de rotation suffisamment court et donc une taille raisonnable.
Ce calcul de la complexité donne une estimation pessimiste. En effet, nous ne pou-vons pas avoir à la fois beaucoup de paquets dans une table de slots et ces paquets occupant tous les slots de la table. De plus, l’algorithme dispose de conditions d’échap-pement dans ses boucles, afin de ne pas poursuivre leurs exécutions lorsque cela est rendu inutile. Enfin, au fur et à mesure de l’exécution, le nombre de communications non allouées décroît, accélérant ainsi la vitesse d’exécution.
A titre indicatif, nous avons exécuté notre algorithme de recherche de chemin sur une machine équipée d’un processeur Intel Pentium III à 3GHz et de 1 Giga de RAM. Il trouve généralement la solution en quelques minutes, voir en quelques secondes. Dans un cas complexe tel que l’application du cas 6 de la section 7.6, qui utilise une topologie en grille 5x5 pour connecter 25 NIs, utilise les exclusions mutuelles, ainsi que le contrôle de flux de bout-en-bout (il implique ici 96 communications unidirectionnelles), une solution avec une table de 16 slots a été trouvée en un temps d’exécution de 8643 secondes soit 2h24. Ceci s’explique par la complexité de ce cas.
Cet algorithme est codé en java, langage qui ne tire pas partie de toute la vitesse de la machine. Notre algorithme n’a pas été prévu initialement pour être embarqué et exécuté pour trouver de nouvelles solutions durant le fonctionnement du système. Ce temps n’est donc pas préjudiciable.
4.4.3.2 Améliorations et heuristiques
Dans le cadre d’un système reconfigurable ou adaptatif, il peut s’avérer nécessaire d’exécuter en ligne l’algorithme de recherche de chemin pour qu’il trouve une nouvelle solution. Dans ce cas cette exécution doit être rapide.
4.4 routage spatio-temporel 71 Nous pouvons noter qu’il est possible de réduire le temps d’exécution de notre algorithme en faisant appel à quelques améliorations et heuristiques :
– Le nombre de chemins candidats retenu peut être limité. Les N premiers sont retenus, car en effet des centaines de chemins peuvent être trouvés avec la version actuelle.
– L’algorithme peut ne recalculer que les chemins candidats des communications dont tous les chemins candidats pré-réservés ont perdu un arc par la réservation du chemin faite par la communication qui vient d’être satisfaite.
Ces améliorations n’ont pas été introduites, mais s’intègrent dans des travaux en cours traitant notamment de la surveillance et du contrôle du NoC.
Enfin, seule l’allocation du trafic GT a été détaillée ici, puisque seul celui-ci doit bénéficier de garantie et fonctionner sur le principe du TDMA. Précisons que le trafic BE qui n’a pas été abordé ici, peut se voir affecter les chemins utilisant les liens qui ont été les plus délaissés par les réservations des communications GT, ceci afin, de souffrir au minimum des conflits avec le trafic GT qui a une priorité plus élevée. L’auteur dans [72] présente une approche dans ce sens. Pour le trafic BE, il faut en revanche veiller à utiliser des chemins qui empêcheront l’apparition d’un deadlock.
4.4.4 Conclusion
Nous avons présenté une technique de recherche de chemin pour les communications de type trafic garanti dans le contexte d’utilisation de tables de TDMA.
L’algorithme que nous proposons tire partie de la connaissance des potentielles ex-clusions mutuelles entre les communications. De plus, une technique de pré-réservation des chemins permet à l’algorithme d’obtenir des solutions avec des topologies et des tables de TDMA les plus petites possibles, ceci afin de réduire le coût en FIFO et donc en surface du NoC.
Chapitre 5
Technique de codage des
chemins pour la sécurité et la
reconfiguration
5.1 Introduction à la sécurité
Un SoC est constitué d’un ensemble d’éléments IP, tels que, processeurs, mémoires et matériels dédiés. Ainsi, le SoC sera amené à faire cohabiter un ensemble d’applications dont certaines pourront avoir des exigences en termes de sécurité.
Les NoCs fournissent aux concepteurs de SoCs un moyen flexible pour contrôler les communications entre un grand nombre de blocs IP, ainsi que des capacités de reconfiguration. Cependant, cette flexibilité introduit de nouveaux points faibles dans le système et offre des opportunités à de potentielles attaques.
De plus, la complexité des applications, l’hétérogénéité de l’architecture et les besoins en reconfiguration, qui peuvent justifier l’utilisation d’un NoC au sein d’un SoC augmentent la gravité de ces attaques potentielles. Il est donc nécessaire de prendre en compte la sécurité du NoC. Ce sujet a jusqu’à présent été négligé, mais deviendra certainement une préoccupation importante dans l’avenir compte tenu de l’importance grandissante que prend la sécurité dans les systèmes embarqués.
Enfin, nous verrons que la technique de codage que nous proposons offre des pro-priétés intéressantes pour d’autres aspects que la sécurité, notamment, la reconfigu-ration [73].