- Timestamp:
- Dec 4, 2007, 2:33:31 PM (17 years ago)
- Location:
- trunk/IPs/systemC/processor/Morpheo
- Files:
-
- 3 added
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/IPs/systemC/processor/Morpheo/Common/include/BitManipulation.h
r2 r63 15 15 namespace morpheo { 16 16 17 // gen_mask ..................................... 18 17 // gen_mask .................................................................. 18 19 19 template <typename T> 20 20 T gen_mask (uint32_t size) … … 29 29 }; 30 30 31 // shift_left_logic, shift_right_logic .......... 31 // mask, mask_not ............................................................ 32 template <typename T> 33 T mask (uint32_t data, uint32_t index_max, uint32_t index_min) 34 { 35 return (gen_mask<T>(index_max-index_min+1)<<index_min) & data; 36 } 37 38 template <typename T> 39 T mask_not (uint32_t data, uint32_t index_max, uint32_t index_min) 40 { 41 return (~(gen_mask<T>(index_max-index_min+1)<<index_min)) & data; 42 } 43 44 // shift_left_logic, shift_right_logic ....................................... 32 45 template <typename T> 33 46 T shift_logic_left (uint32_t size, uint32_t data, uint32_t value) … … 46 59 } 47 60 48 // shift_logic .................................. 61 // shift_logic ............................................................... 49 62 template <typename T> 50 63 T shift_logic (uint32_t size, uint32_t data, uint32_t value, bool is_direction_left) … … 56 69 } 57 70 58 // shift_left_arithmetic, shift_right_arithmetic 71 // shift_left_arithmetic, shift_right_arithmetic ............................. 59 72 template <typename T> 60 73 T shift_arithmetic_left (uint32_t size, uint32_t data, uint32_t value) … … 92 105 } 93 106 94 // shift_arithmetic ............................. 107 // shift_arithmetic .......................................................... 95 108 template <typename T> 96 109 T shift_arithmetic (uint32_t size, uint32_t data, uint32_t value, bool is_direction_left) … … 102 115 } 103 116 104 // shift ........................................ 117 // shift ..................................................................... 105 118 template <typename T> 106 119 T shift (uint32_t size, uint32_t data, uint32_t value, bool is_direction_left, bool is_shift_arithmetic) … … 112 125 } 113 126 114 // rotate_left, rotate_right .................... 127 // rotate_left, rotate_right ................................................. 115 128 116 129 template <typename T> … … 132 145 } 133 146 134 // rotate ....................................... 147 // rotate .................................................................... 135 148 template <typename T> 136 149 T rotate (uint32_t size, uint32_t data, uint32_t value, bool is_direction_left) … … 142 155 } 143 156 144 // range ........................................ 157 // range ..................................................................... 145 158 template <typename T> 146 T range (uint32_t size, uint32_tdata, uint32_t index_max, uint32_t index_min)159 T range (uint32_t data, uint32_t index_max, uint32_t index_min) 147 160 { 148 return gen_mask<T>(index_max-index_min+1) & shift_logic_left<T> (size, data,index_min);161 return gen_mask<T>(index_max-index_min+1) & (data << index_min); 149 162 } 150 163 151 164 template <typename T> 152 T range (uint32_t size, uint32_tdata, uint32_t nb_bits)165 T range (uint32_t data, uint32_t nb_bits) 153 166 { 154 167 return gen_mask<T>(nb_bits) & data; 155 168 } 156 157 158 169 }; // end namespace morpheo 159 170 -
trunk/IPs/systemC/processor/Morpheo/Common/include/ChangeCase.h
r43 r63 16 16 namespace morpheo { 17 17 18 void UpperCase(string& S)18 inline void UpperCase(string& S) 19 19 { 20 20 uint32_t n = S.size(); … … 27 27 } 28 28 29 void LowerCase(string& S)29 inline void LowerCase(string& S) 30 30 { 31 31 uint32_t n = S.size(); -
trunk/IPs/systemC/processor/Morpheo/Common/include/Debug.h
r44 r63 28 28 #ifdef DEBUG 29 29 //Debug 30 31 30 # define log_printf(level, component, func, str... ) \ 32 31 do \ 33 32 { \ 34 if ( (DEBUG == DEBUG_ALL) or \ 33 if ( (DEBUG == DEBUG_ALL ) or \ 34 (DEBUG_ ## level == DEBUG_NONE) or \ 35 35 (( DEBUG_ ## level <= DEBUG) and \ 36 36 ( DEBUG_ ## component == true )) ) \ -
trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/article-07sympa/fr/root.tex
r59 r63 1 TODO : begin reformuler 2 L'augmentation de la finesse de gravure des transistors a pour conséquence une augmentation du nombre de transistors par unité de surface. Donc pour une même surface, un composant matériel peut être de plus en plus complexe. 3 TODO : end reformuler 1 % objectif 2 % * utilisation de l'outil 3 % -> exploration architecturale 4 % -> sur 2 composants, parler du compromit performance/surface. 4 5 5 Concevoir des System On Chip (SOC) devient de plus en plus complexe. Le concepteur doit utiliser des librairies de composants existants et les inter-connectés entre eux. Ces composants sont des boîtes noires et les concepteurs n'ont aucune garantie d'absence de chevaux de troie. 6 \begin{abstract} 7 \end{abstract} 6 8 7 De plus ce sont des composants pour la plupart commerciaux, et il n'y a pas de garantie d'approvisionnement ou de maintient de protocole de communication. 9 %=================================================================================== 10 \Section{Introduction} 8 11 9 TODO : begin reformuler 10 Pour cela utiliser des composants ouverts permet de s'abstraire de ces problèmes. 11 TODO : end reformuler 12 L'approche actuelle pour dévelloper des systèmes embarquées est fondée sur le secret. Les composants matériels et/ou logicielle sont fermés. Les concepteurs utilisant ces Intellectual Proprity (IP) ne sont pas assuré d'absence de chevaux de troie, de la pérénité de ce composant (arrêt de la production ou changement de protocole de communication). 12 13 13 Le nombre de processeurs ouverts sont assez restreint : l'OpenRISC 1200, le LEON, l'OpenSPARC, \dots. De plus, aucun n'exploite l'Instruction Level Paralellism (ILP). 14 La nouvelle approche se base sur l'utilisation de composant ouvert. Ceci engendre la disponibilité du code source et rendre plus facile l'intégration sur FPGA. Ceci permet d'avoir des systèmes sur puces (SOC). 15 16 De telle systèmes ont des contraintes varié en terme de la performance nécessaire à l'application et à la surface disponible pour la plate-forme matérielle. 17 18 Pour cela, le processeur doit exploiter tout les formes de parallélisme disponible. 19 20 Une implémentation superscalaire permet d'exploiter le parallélisme des instructions en lançant 21 et exécutant plusieurs instructions indépendantes simultanément. 22 Pour cela, il faut que le processeur puisse charger depuis la mémoire plusieurs instructions, 23 les décoder simultanément, détecter les dépendances (de données et de ressources) et les lancer 24 vers les unités d'exécutions disponibles. 25 Les ressources matérielles internes de ce type d'architecture sont complexes (\cite{1997_palacharla}). 26 27 Cette complexité rend difficile l'implantation sur FPGA ({\it Field-Programmable Gate Array}) d'un processeur 28 sueprscalaire. 29 Sur un tel support technologique, le processeur va être placé dans les ressources prédéterminées du FPGA. 30 Les ressources mémoires sont limitées par leur nombre et par leur accès, de même pour les blocs logiques 31 qui sont limités par le nombre d'entrées pour les fonctions booléennes implémentées. 32 33 La difficulté pour un concepteur de système intégré est de bien dimensionner 34 sa plateforme matérielle pour les applications logicielles. 35 36 Pour les applications qui ont besoin de performance, le concepteur ne peut pas 37 sélectionner un softcore libre. Ces derniers n'exploitent pas le parallélisme 38 d'instruction (Instruction Level Parallelism (ILP)). 39 40 \TODO{citer OPENRISC, LEON, OPENSPARC ...} 41 42 Le concepteur devra choisir entre une solution multiprocesseurs et paralléliser 43 les applications, par exemple l'architecture Piranha (\cite{2000_barroso}) 44 qui consiste en 8 processeurs alpha scalaire in-order, ou encore l'architecture de 45 l'Hydra (\cite{2000_hammond}) qui instancie 4 processeurs de type mips scalaire. 46 Une autre solution pour le concepteur est d'utiliser des processeurs exploitant l'ILP 47 mais dont le composant est fermé. 48 49 Disposer d'un processeur exploitant l'ILP et synthétisable sur FPGA permet 50 d'augmenter le nombre de solutions disponibles pour le concepteur de systèmes intégrés. 51 52 L'exploration architecturale va indiquer au concepteur le nombre de processeurs, 53 le déploiement de l'application et les ressources internes nécessaires pour satisfaire 54 les contraintes de performances du système. 55 De plus, durant la phase exploratoire, le concepteur va définir ces impératifs de 56 performance en suivant les contraintes de surface. 57 58 Dans cette article nous allons montrer une partie du processeur MORPHEO. Ce composant 59 à pour vocation de fournir un modèle haut niveau (systemC CABA) et bas niveau (VHDL RTL) 60 d'un processeur haute performance. La partie examinée est la boucle d'exécution. Dans 61 la section suivante, nous expliquons ce qu'est la boucle d'exécution et des difficultés 62 pour l'implémenter sur FPGA. Dans la section \ref{section_3}, nous allons analyser 63 la complexité de 3 blocs fonctionnelles : le banc de registres, l'unité mémoire et 64 la station de réservation. Ensuite dans la section \ref{section_4}, nous allons poser 65 nos hypothèses de simulations, les résultats seront discuter dans la section suivante. 66 Enfin nous finirons par une conclusion et quelques perspectives. 67 68 %=================================================================================== 69 \Section{Boucle d'exécution}\label{section_2} 70 71 Un processeur à exécution désordonnée peut être décomposé en 3 parties logiques : 72 \begin{description} 73 \item [Front end : ] Cette première partie consiste à charger depuis la mémoire des paquets d'instructions. Une unité de prédiction va calculer l'adresse du prochain paquet. Ensuite chaque instruction du paquet va être décodé et placer dans une file d'attente. 74 \item [Out Of Order Engine : ] Cette unité s'occupe de dés-ordonnancer et de réordonnancer les instructions. Pour cela les registres vont être renommés et les instructions vont être stockées dans une file de ré-ordonnancement. Le numéro d'entrée de cette file permettra d'accéder à la bonne case une fois que l'instruction aura été exécutée. Les instructions sont enlevées de cette file dans l'ordre du programme. C'est ce composant qui vérifie les exceptions ou les erreurs de spéculations. 75 \item [Execution Loop : ] La boucle d'exécution s'occuper de lire les opérandes cibles, exécuter l'opération et écrire le résultats dans le bancs de registres. C'est également dans cette partie que les accès à la mémoire de données vont être effectués. Si l'instruction n'a pas toute ces opérandes sources, alors elle les attendra dans la station de réservation. 76 \end{description} 77 78 Dans ce document, nous nous centrons sur la boucle d'exécution. Celle-ci contient des structures associatives : les stations de réservation, des bancs de registres multi ports et de la logique de routage : entre les stations de réservations et les unités d'exécutions. 79 Ces types de structures se retrouvent dans les autres parties du processeur : structure associative pour le buffer de reordonnancement, les bancs de registres multi-ports pour le renommage de registres (en particulier le Register Address Translation (RAT)). 80 81 \printgraph{MORPHEO_micro_architecture-execute_loop}{0.5}{MORPHEO : Execution loop} 82 83 \TODO{refaire le graphe avec un schéma plus explicite} 84 85 Comme le montre le graphe \cite{MORPHEO_micro_architecture-execute_loop}, notre modèle de la boucle d'exécution est décomposé en 4 parties : l'unité de lecture, l'unité d'exécution, l'unité d'écriture et enfin le banc de registres. 86 87 \TODO{parler maintenant des implémentations de la boucle d'execution ou alors dans chaque partie séparée ?} 88 89 %=================================================================================== 90 \Section{Complexité}\label{section_3} 91 92 %----------------------------------------------------------------------------------- 93 \subSection{Banc de registres} 94 A chaque cycle plusieurs instructions doivent accèder au banc de registres afin de soit lire leurs opérandes, soit écrire leurs résultats. Le banc de registres doit être multi-accès. 95 Dans le mips R10000 (\cite{1996_yeager}), le banc de registres entier possède 7 ports de lectures et 3 ports d'écritures. Alors que l'itanium 2 (\cite{2003_mcnairy} possède un banc de registres à 12 ports de lectures et 8 ports d'écritures. 96 97 Si tout les ports de lecture et d'écriture peuvent accèder à tous registres, alors le banc de registre à une implémentation monolithique. La surface et le temps d'accès aux registres augmentent avec le nombre ports. 98 99 Pour diminuer le nombre de ports, le banc de registres peut être composer de plusieurs bancs ayant localement moins de ports que nécessaire. Dans l'alpha 21264 (\cite{1999_kessler}), les unités entières sont placées dans l'un des deux clusters, et dans chaque cluster il y a une copie de banc de registres. 100 101 Une autre méthode consiste à réaliser un cache de banc de registres : le cache de niveau 1 contient peu de registres et avec beaucoup de registres alors que le niveau 2 contient peu de port (voir être mono port) et contient une copie de tout les registres. Cette méthode est décrite dans \cite{2000_cruz}. 102 103 104 ................. 105 106 107 %----------------------------------------------------------------------------------- 108 \subSection{Unité mémoire} 109 L'unité mémoire a pour but de réaliser les accès mémoires. Cette unité doit aussi ordonner les accès mémoires suivant le modèle de consistance mémoires. Dans un modèle relâché, les lectures peuvent être lancées dans n'importe quel ordre. Toutefois, l'unité mémoire doit garder la mémoire cohérente. C'est à dire que les écritures mémoire ne peuvent être exécuter que quand celle-ci ne sont plus spéculative et que toute instructions précèdent ne font pas d'exception. Un accès mémoire arrivant en tête du buffer de ré ordonnancement satisfait ces contraintes. 110 111 Afin d'accélérer les accès en lecture, l'unité peut faire de la spéculation : faire des accès en lecture à la mémoire instruction et écrire la donnée lut dans le banc de registres avant même d'avoir vérifier que cette lecture n'a pas une dépendance d'adresse avec une écriture antérieure. Dans \cite{1998_chrysos}, Chrysos et Emer ajoute de la spéculation pour détecter les accès en écriture qui sont susceptible d'avoir des dépendances avec des accès en lecture ``proche''. 112 113 L'implémentation de l'unité mémoire ce fait par l'intermédiaire de deux files circulaires : la store\_queue contient tout les écritures en attentes ainsi que la load\_queue contenant quant à elle les lectures en attente d'accès au cache et en attente d'arrivé de la réponse. 114 115 Les pointeurs d'écritures de ces deux files sont gérés dans l'étage de renommage. C'est dans ce même étage que les instructions sont placées dans le buffer de réordonnancement. Si les files sont pleines alors le pipeline est arrété. 116 117 118 119 %----------------------------------------------------------------------------------- 120 \subSection{Station de réservation} 121 La station de réservation est une structure associative (CAM). Après que les instructions ont accédées au banc de registres, elles sont placées dans les stations de réservations. Une instruction doit avoir la totalité de ces opérandes pour pouvoir être éxecutée. Toute destination d'une instruction peut être la source d'autres instructions. Pour cela toute les écritures dans le banc de registres doit être propagées vers chaque opérande de chaque entrée de chaque station de réservations. 122 123 124 125 %=================================================================================== 126 \Section{Simulations}\label{section_4} 127 128 Les simulations sont réalisée avec les benchmarks SPECINT 2000. 129 130 %=================================================================================== 131 \Section{Résultats}\label{section_5} 132 133 %=================================================================================== 134 \Section{Conclusion}\label{section_6} 135 136 \bibliography{\dircommon/bibliographie} -
trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Include/doc-style.sty
r45 r63 84 84 \end{figure} 85 85 } 86 87 \newcommand{\TODO}[1] 88 {\begin{center} 89 {\bf TODO :}\newline 90 {\it {\large #1}} 91 \end{center} 92 } 93 86 94 87 95 \def\@maketitle -
trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Info/article-07sympa.sty
r59 r63 1 \def\review{ YYYY/MM/DD}1 \def\review{} 2 2 %\def\review{\number\day/\number\month/\number\year\xspace} 3 3 4 \title{ MORPHEO}4 \title{Trouver un titre sexy} 5 5 6 \author{Mathieu Rosière \and Nathalie Drach -Temam}6 \author{Mathieu Rosière \and Nathalie Drach \and Franck Wajsbürt \and Jean-Lou Desbarbieux} 7 7 8 8 \affiliation{Equipe SOC - Laboratoire d'information de Paris VI - France} 9 9 10 \email{\{mathieu.rosiere, nathalie.drach -temam\}@lip6.fr}10 \email{\{mathieu.rosiere, nathalie.drach, franck.wajsburt, jean-lou.desbarbieux\}@lip6.fr} 11 11 12 12 \date{\review} -
trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Makefile
r57 r63 108 108 $(ECHO) "Génération du fichier $*.dvi"; \ 109 109 $(LATEX_WITH_ENV) $<; \ 110 if $(TEST) $ ? -eq 0; then \110 if $(TEST) $$? -eq 0; then \ 111 111 $(LATEX_WITH_ENV) $< > /dev/null; \ 112 112 citation=`$(GREP) "citation" $*.aux`; \ … … 117 117 $(LATEX_WITH_ENV) $< > /dev/null; \ 118 118 fi; 119 119 120 120 121 #--------------------------------------------------------------------------------
Note: See TracChangeset
for help on using the changeset viewer.