source: trunk/IPs/systemC/processor/Morpheo/Documentation/Source/Documents/document-morpheo-methodology/fr/root.tex @ 2

\section{Méthodologie}
Dans cette section, nous allons voir la méthodologie générale de dévelloppement du modèle Morpheo.

Pour la conception du modèle de processeur nous avons suivit trois grandes étapes. Comme le processeur à pour vocation d'être un modèle de processeur généraliste, nous avons réalisé l'état de l'art sur les processeurs commerciaux superscalaire et/ou multi-core / multi-threaded. Pour cela, nous nous sommes principalement inspirés du Mips R10000, de l'intel Pentium 4, et de l'IBM Power 5.
De cette étude préliminaire, nous avons réalisé un découpage grossier du processeur en 7 étages logiques. Les communications entres étages sont définit cette étape, mais la composition exact de ces interface ne sont pas déterminer aux signals près.

La deuxième étape consiste à réaliser un découpage structurelle en macro bloc. C'est à dire que chaque étage logique est sous divisé en macro bloc réalisant une fonction. Un exemple significatif étant l'étage de renommage où nous pouvons identifier 4 macro blocs : la table de RAT (Register Address Translation), la Free-list (contenant les registres pouvant être utilisé dans le processus de renommage), un bloc combinatoire détectant les dépendances RAW (Read-after-Write) proche et enfin l'Issue Queue (file d'attente des instructions).

Lors de cette deuxième étapes, nous avons dévellopés un modèle haut niveau (écrit pour le simulateur SystemC) CABA (Cycle accurate bit Accurate). Cependant certaines fonctionnalités reste encore non précis au cycle comme par exemple l'étape d'initialisation du processeur lors de l'activation de l'entrée de Reset.

Les Macro-bloc offrent la possibilité d'être relativement simple à transformé en VHDL synthétisable. C'est l'objectif de la troisème phase. Chacun de ces Macro-blocs sont décomposés en micro-blocs. Les premiers étant précis à l'interface, l'interconnection des macro-blocs traduit en micro bloc ne poseras que peut de problème.
Or nous pouvons remarquer que notre modèle haut niveau CABA s'éloigneras de la représentation en VHDL synthétisable. Dans un souçit de cohérence forte entre ces deux niveaux de représentation, nous avons décidé de décrire un modèle systemC au niveau micro bloc. Celui-ci deviendra notre modèle final.


Qu'offre un modèle d'un micro bloc?

Chaque modèle écrit en systemC (donc en C++) offre divers services : 
\begin{itemize}
\item Une classe pour paramétrer le micro-bloc et vérifier ainsi la cohérence des paramètre. La vérification de fait en 3 points : la vérification fonctionnel (interaction des paramètres entre eux. Par exemple toujours dans le Rat, il est inutiles de renommer plus d'instruction que de case dans l'Issue Queue ou que de Registre Physique supplémentaire). La seconde est une vérification de cohérence (entier soit positif, soit naturel. Voir même obligation d'être une puissance de 2 (comme par exemple toute les tailles de files.)
\item Le modèle systemC/CABA du composant.
\item Avec le modèle systemC, nous fournissons un petit jeux de test afin de vérifier le bon fonctionnement du modèle dans des conditions d'utilisations courantes.
\item La possibilité de générer un modèle VHDL synthétisable à partir des paramètres du modèles.
\item Lors de la simulation, nous pouvons générer un fichier de statistiques afin de vérifier l'influence des paramètres actuelles sur ce bloc.
\item Et enfin, à l'instar d'un test du modèle systemC, nous pouvons générer un fichier de bench pour le modèle vhdl en sauvegardant les transactions au interface du modèle systemC en cours de simulations. Ceci nous permettra alors de garantir la stricte compatibilité entre le modèle systemC CABA et le modèle Vhdl Synthétisable.
\end{itemize}