ATAC [137] 215 mm2(2 µm) 330 µs
ELLF [139] 3200 CLB (Xilinx XC40250XV) 850 ns
CS2 [138] 4576 logic elements (Altera 20K200E) 10 µs
F-Timer [140] 866 logic elements (Altera EPF10k20) + 6144 bits de mémoire 100 µs
RTM [141] NC 2,2 µs
CHS [142] 0,24 mm2 (0,35 µm) ou 421 logic elements 20 µs
et 564 registres (Altera Quartus II EP20K)
Sierra [143] 532 slices (Xilinx XC2S100E-5) 2 µs (variable)
STRON [144] 40000 portes équivalentes (0,5 µm) 20 µs (variable)
Spring [157] 59,84 mm2(0,8 µm) NC
SystemWeaver [158] 100000 portes équivalentes - 0,4 mm2 (90 nm) 1 µs (variable)
RTU 94 [161] 250000 portes équivalentes NC
OSoC 2,3 mm2 (0,13 µm) 16 µs
Tab. 5.13 – Comparaison de la taille et de la réactivité de l’OSoC avec les autres accélérateurs matériels de noyau temps-réel
Tout d’abord, le choix de l’algorithme d’ordonnancement ne privilégie pas toujours une évolution dynamique des priorités. En fait, seules les solutions ELLF, Spring et OSoC intègrent des algorithmes d’ordonnancement qui nécessitent une forte accélération. Le nombre de tâches est limité dans presque toutes les solutions. L’utilisation de 32 tâches est la plus souvent privilégiée. Seules les solutions SystemWeaver et OSoC permettent l’exécution d’un nombre de tâches non limité avant l’exécution. Cependant, dans les deux cas les architectures doivent être modifiées si l’on souhaite augmenter le nombre de tâches actives simultanément.
Ensuite, la gestion des dépendances et des synchronisations se résume le plus souvent à la mise en œuvre de sémaphores qui peuvent être réservés ou libérés au cours de l’exécution. Aucune solution similaire à celle utilisée dans l’OSoC n’existe dans la littérature. Nous sommes les seuls à proposer une gestion aussi transparente des dépendances de contrôle et de données. Avant son exécution, une tâche n’a pas besoin d’empêcher les tâches suivantes de s’exécuter. La propagation des jetons impose l’ordre d’activation des tâches.
De même, les tâches non-périodiques sont bien souvent simplement des tâches qui se ré- veillent sur une interruption extérieure. On ne leur associe pas un ordonnancement particulier et ces tâches ne suivent pas les mêmes règles d’activation que les autres tâches temps-réel. Par ailleurs, les échéances d’exécution des différentes tâches ne sont pas du tout calculées en fonc- tion de l’échéance globale de l’application. Elles sont attribuées individuellement comme si les tâches n’avaient pas de relations entre elles. Ceci empêche les tâches suivantes de prendre en compte des retards d’activation ou des interruptions d’exécution subies par les tâches en cours. Toutes les solutions matérielles existantes sont donc très différentes de l’approche inventée pendant cette thèse.
D’autre part, les seules approches qui supportent de multiples ressources de calcul sont Spring, SystemWeaver, RTU 94 et l’OSoC. Toutes, excepté l’OSoC, utilisent un unique bus comme moyen de communication entre le contrôle et les ressources de calcul. Il ne peut donc pas y avoir de parallélisme de contrôle et la réactivité peut souffrir d’une bande passante insuffisante.
Enfin, l’OSoC est la seule solution qui prend en charge les ressources de mémorisation, la gestion de la consommation d’énergie, le contrôle dynamique des tâches et leur migration.
Ceci améliore l’occupation des ressources de calcul et permet de s’adapter en ligne aux besoins de l’utilisateur. L’OSoC offre donc de plus nombreux services et demeure la seule solution capable de contrôler des systèmes multiprocesseurs hétérogènes de manière autonome.
Cependant, comme le montre le tableau 5.13, ceci a un coût important et l’OSoC est la solution matérielle la plus complexe mise en œuvre. Nos performances sont donc a priori inférieures mais la comparaison n’a de sens que si la même application est exécutée avec chacune des solutions proposées. Ceci n’étant pas possible, nous pouvons malgré tout affirmer que, lors de l’exécution de l’encodeur MPEG4-AVC par exemple, n’importe quelle solution plus performante que l’OSoC offre un gain inférieur à 10 % puisque notre taux d’occupation des ressources de calcul est supérieur à 90 %. Par ailleurs, en un seul tick nous exécutons l’intégralité des services supportés par l’OSoC alors que bien souvent les temps d’exécution s’ajoutent avec les autres solutions.
5.5 Synthèse
Ce cinquième chapitre a permis de justifier l’intérêt de notre approche pour contrôler des systèmes multiprocesseurs hétérogènes. La première section a détaillé notre méthodologie de conception et de validation. Puis, elle a introduit nos résultats après synthèse logique et FPGA. Un OSoC capable d’exécuter 32 tâches en parallèle et de contrôler 16 ressources de calcul peut atteindre une résolution inférieure à 35 µs. La surface totale est de 4,2 mm2 pour une consommation d’énergie inférieure à 155 mW.
La section suivante a analysé l’impact de notre architecture de contrôle sur les performances globales du système. Pour cela, plusieurs applications différentes ont été implantées. L’étude des algorithmes ELLF et RSSR, ainsi que de l’influence de la configuration avant l’exécution, a mis en évidence l’intérêt des différents services mis en œuvre dans l’OSoC. Par ailleurs, l’exa- men du comportement de l’OSoC en fonction du parallélisme de l’application et du nombre de ressources de calcul, a montré un comportement particulièrement efficace pour les archi- tectures synthétisées. Avec l’encodeur MPEG4-AVC, le taux d’occupation des ressources de calcul est supérieur à 80 % quel que soit le parallélisme de l’application. Nous avons égale- ment pu mettre en évidence l’intérêt de séparer le contrôle et le calcul. Le parallélisme obtenu permet de limiter les pénalités induites par le contrôle et de réduire significativement les problèmes liés à l’asymétrie de l’architecture SCMP-LC.
Enfin, les deux précédentes sections ont démontré qu’il n’était pas possible d’envisager une approche logicielle pour réaliser l’OSoC et qu’aucune solution équivalente n’existe dans la littérature. Un OSoC logiciel capable d’exécuter 32 tâches en parallèle et de contrôler 16 ressources de calcul a une résolution égale à 6,26 ms. La surface totale est de 6,64 mm2 pour une consommation d’énergie de 102 mW. Les performances sont donc très inférieures puisqu’il y a un facteur égal à 180 entre les deux approches. De plus, l’approche logicielle occupe une surface silicium nettement plus importante.
Maintenant que nous avons validé notre approche et justifié son intérêt, nous pouvons étudier l’influence de son intégration dans une architecture multiprocesseur en reprenant les critères introduits dans le premier chapitre. Le tableau 5.5 compare, pour un nombre de transistors équivalent, l’architecture superscalaire Intel Pentium 4 Mobile cadencée à 2,2 GHz et deux plates-formes multiprocesseurs SCMP-LC.
Caractéristiques Intel Northwood Pentium 4 Mobile
SCMP-LC avec 10 Philips SCMP-LC avec
Trimedia TM-1100 32 MIPS 24KE
(32 mémoires de 8Ko) (32 mémoires de 8Ko)
Fréquence processeur 2,2 GHz 133 MHz 625 MHz
Nombre de transistors 55 millions ≈ 58 millions ≈ 50 millions
Puissance consommée 35 W ≈ 60 W ≈ 11,6 W
Mémoire embarquée 8 Ko(L1)+512 Ko(L2) 10 Ko(L1)+256 Ko 32 Ko(L1)+256 Ko
Surface totale 146 mm2 ≈ 175 mm2 ≈ 120 mm2
Surface pour le calcul 13 % ≈ 90 % ≈ 85 %
Technologie 0,13 µm 0,13 µm 0,13 µm
Performance crête 8,8 GOPs 53 GOPs 40 GOPs
Efficacité transistor 0,16 GOPs.MT−1 0,91 GOPs.MT−1 0,8 GOPs.MT−1
Efficacité énergétique 0,25 MOPs.mW−1 0,88 MOPs.mW−1 3,45 MOPs.mW−1
Tab. 5.14 –Caractéristiques de plates-formes SCMP-LC et comparaison avec le processeur Intel Pen-